Az Egységesített Eljárás módszertan
|
|
- Éva Magyar
- 8 évvel ezelőtt
- Látták:
Átírás
1 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 (2002 óta az IBM része) fejlesztett ki a 90-es évek közepétől. A RUP nem egy szokásos, egyszerű eljárás, hanem inkább egy feladatokra adaptálható keretrendszer, amelyből minden feladattípushoz az ahhoz illeszkedő módszereket, eszközöket alkalmazhatjuk. Ugyanakkor a RUP maga is egy szoftvertermék, amely leírásokat, ismeretbázist és példákat is tartalmaz különböző megoldásokra. Rövid történet A RUP gyökerei a 80-as és 90-es évek módszertani kísérleteiig nyúlnak vissza (spirális, evolúciós stb. modellek és a rájuk épülő eljárások) a Rational Approach kidolgozásáig ben a Rational megvette a svéd Objectory Systems céget, amely szintén módszertani kérdésekkel foglalkozott (Ivar Jacobson munkássága). A két cég összeolvadásának, és kutatásaik egységesítésének (Rational Approach és Objectory Process) lett az eredménye a Rational Objectory Process és a Rational Rose modellező szoftver. A Rational Unified Process első publikált változata 1998-ban jelent meg, az utolsó pedig már az IBM égisze alatt, 2005-ben. Az elgondolás A RUP tervezői a szoftverfejlesztési problémákra koncentrálva, azok megoldására keresték a választ. Szoftverkrízis A 80-as évekre a szoftvergyártásban olyan helyzet alakult ki, amelyet ma szoftverkrízisnek nevezünk. Lényegében arról volt szó, hogy az addigi szoftverfejlesztési módszerek és eszközök egyre kevésbé feleltek meg a világ változó igényeinek; egyre több fejlesztés jutott zsákutcába (kb. 75%!!!). Kezdetben úgy tűnt, hogy a programkészítési eszközökben és módszerekben kell a problémák gyökerét keresni a 80-as évek végétől emiatt gyorsult fel pl. az objektumorientált programozási módszer elterjedése és a WYSIWIG jellegű integrált programfejlesztő eszközök készítése mindezek célja pedig a gyors, komponensalapú alkalmazásfejlesztés támogatása volt. A 90-es évekre a programozási módszerek és eszközök palettája szinte teljesen megújult de érdekes módon (a felmérések szerint), ez csak igen rövid ideig tartó és átmeneti hatást gyakorolt a fejlesztések eredményességére. Ekkor a kutatások más irányba, a komplex fejlesztés modelljeinek és módszertanainak irányába fordult. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 1
2 A különböző kutatások, felmérések a kudarcok okait keresve az alábbi fő tényezőket szűrték ki: esetleges, következetlen követelményfeltárás és elemzés; félreérthető, pontatlan kommunikáció; túl bonyolult megoldások; következetlenségek a követelmények-tervek-implementációk között; elégtelen tesztelés; a fejlesztési projektek állapotának szubjektív értékelése; kockázatelemzési hiányosságok, hibák; a változások kezelésének hiányosságai. A fejlesztési projektek problémáit általában néhány jellemző tünet mutatja bár maguk a bukások mindig egyedi módon következnek be. Az esetek tanulmányozásának eredményeképpen született meg az a legjobb megoldások (best practices) gyűjtemény, melyből a RUP kinőtt. A fejlesztési folyamat életciklusa A RUP szemléletében egy fejlesztés életciklusa a munka megkezdésétől a késztermék egy üzemszerű működésre szánt változatának átadásáig tart. 1. ábra A fejlesztés életciklusa Kezdet, előkészítés A fejlesztés kezdeti szakaszában a munka elhatározása, a feltételek és erőforrások meghatározása történik. Ez a szakasz gyakorlatilag egybeesik a projektfolyamatok első szakaszával, melyben célmeghatározások, felmérések, különféle erőforrásbecslések, projektváltozatok és az ezekhez kapcsolódó megvalósíthatósági tanulmányok és egyéb elemzések készülnek. Ezek alapján megtörténik a fejlesztés indítására vonatkozó döntés. A kezdeti szakaszban választ kell adni az alábbi kérdésekre: Kik a fejlesztés által érintett, illetve a fejlesztést leginkább befolyásoló kulcsfigurák (emberek, más rendszerek és igényeik, érdekeik)? Melyek az alapvető, meghatározó követelmények (a rendszer határainak meghúzása)? Az idő- és (vagy) költség-előirányzatok, prioritások, kockázati tényezők és a fejlesztési folyamat részeinek pontosítása, véglegesítése. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 2
3 Architekturális kérdések tisztázása. (A RUP megfogalmazása szerint az architektúrának mindaz része, ami lényegében meghatározza a rendszer jellegzetességeit.) Kidolgozás A kidolgozási fázisban kezd testet ölteni a fejlesztési projekt. A fő cél a követelményrendszer és az általános megoldási elképzelések felállítása az üzleti modellezés, szakterületi modellezés, kulcsfigurák igényei alapján. Ezekre támaszkodva meg kell alkotni a szoftver végleges architektúráját (a tervezett rendszer fő alkotóelemei és azok fontossági sorrendje, kapcsolatrendszere). Elkezdődik a rendszer tényleges tervezése, és a részeredmények prototípus-programokban való tesztelése. Építés Az építési szakaszban a rendszer komponenseinek véglegesítése és kivitelezése történik. Elkészül az első, kiadható programkód. Átadás Az átadási szakaszban kerül a szoftver a fejlesztőtől a felhasználóhoz. A szakasz jellemző tevékenységei: a felhasználók oktatása, a felhasználói tesztek elvégzése. Az alábbi ábra a RUP folyamatát és a folyamathoz kapcsolódó tevékenységeket szemlélteti. 2. ábra A RUP buckás" ábrája Fázisok és iterációk A folyamat a spirál modell egy megvalósításának tekinthető. Az ábra a fejlesztés egy ciklusát, egy termékverzió előállítását mutatja. A fejlesztési ciklus négy fázisból áll (előkészítés, kidolgozás, építés, átmenet), egy-egy fázis elkészítése során több munkafolyamatot (függőleges tengely) érint. Az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás-igényűek. Másik megközelítésben a fázisok iterációkra bonthatók. Minden egyes iteráció egy-egy mini projekt, melynek Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 3
4 során a rendszer egy inkrementuma (a célokat, követelményeket valamilyen kidolgozottsági szinten teljesítő megoldás) áll elő. Tehát az ábra vízszintes dimenziója az időbeliséget, függőleges dimenziója a különböző tevékenységeket szimbolizálja. Időben a fejlesztés fázisokra, a fázisokon belül iterációkra bomlik, az egyes fázisok végén ún. mérföldkövek vannak. Minden egyes iteráció egy-egy fejlesztési mini projekt, melyben kicsiben megvan minden, ami egy fejlesztési projekt szerves része. Kezdődik az üzleti modellezéssel, követelményelemzéssel, folytatódik elemzéssel, tervezéssel, implementálással, teszteléssel, és befejeződik a telepítéssel. Az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. A fejlesztés különböző fázisaiban az iterációk lényegesen különbözőek lehetnek. Míg a fejlesztés kezdeti szakaszában az üzleti modellezés és a követelményelemzés a hangsúlyosabb, s a tesztelés, telepítés lehet, hogy ki is marad, addig a középső szakaszban az implementálás, a legvégső szakaszban a telepítés, a tesztelés a domináns. A fejlesztés bizonyos szakaszaiban egyes munkafolyamatok erőforrásigénye szinte nullára is csökkenhet. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. Hasonlóan az iterációkhoz, a fázisok is a projekt időbeli lefolyását tagolják, számuk és nevük azonban kötött. A fázisok a hasonló iterációk összessége. A fázisokhoz jellegzetes mérföldkövek, azaz elérendő célok tartoznak. A fázis végén, a mérföldkő elérésekor lehet és kell dönteni a projekt további sorsáról. Természetesen a fázisokat lezáró nagy mérföldkövekhez hasonlóan minden egyes iteráció végén is számba kell venni, hogy sikeresek-e az erőfeszítéseink; ezeket a technikai jellegű célokat nevezi a RUP terminológiája kis mérföldkőnek. Munkafolyamatok, tevékenységek A módszertan tevékenységtípusok szerinti tagozódását mutatja a buckás ábra függőleges dimenziója. Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. A tevékenység jellegének megfelelően megkülönböztetünk mérnöki, illetve támogató folyamatokat. A mérnöki folyamatok hozzák létre a szoftverterméket, míg a támogató munkafolyamatok a fejlesztés irányításával, a környezet biztosításával, a változáskövetéssel, azaz a menedzsment feladataival foglalkoznak. Az ábra harmadik dimenziója amit a sávok magassága jelent, az egyes tevékenységek intenzitását, erőforrásigényét szimbolizálja. Mérnöki munkafolyamatok Üzleti modellezés (Business Modelling) Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben működni fog. A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg. Más néven szakterületi (domain) modellezés. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére. Követelménytervezés (Requirements) A rendszernek kívülről, a felhasználó szempontjából való leírását adja meg. Feladata a funkcionális és a nem funkcionális követelmények összegyűjtése. A funkcionális követelményeket jellemzően használati esetekként gyűjtjük össze. A Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 4
5 rendszer működőképességét lényegesen befolyásolhatják a nem funkcionális követelmények (üzleti környezet, hardver- és szoftverkörnyezet, egyéb követelmények: pl.: válaszidők, technológia, megbízhatóság stb.) is. Elemzés és tervezés (Analyzis & Design) o Elemzés A rendszer képét belülről, a fejlesztő szempontjából írja le. Az architektúrára koncentrál, koncepcionális szintű osztályokat és együttműködéseket határoz meg. o Tervezés Feladata az implementálható pontosságú tervek elkészítése. Hasonlóan az elemzés munkafolyamatához, a rendszert belülről, a fejlesztő szempontjából írja le, azonban a leírás lényegesen részletesebb. A RUP összevonja az elemzés és a tervezés munkafolyamatát. Kódolás (Implementation) Feladata a rendszer tényleges elkészítése, a kódolás. Az implementációs szintű tervek tekintettel vannak a konkrét környezetre, a forráskód pedig erősen kötődik a hardver- és (vagy) szoftverkörnyezethez. Tesztelés (Test) Feladata a rendszer helyességének ellenőrzése. Magában foglalja a tesztelés tervezését, a teszteléshez szükséges adatok, eszközök elkészítését, a tesztek tényleges lebonyolítását illetve az esetleges hibák, hiányosságok visszajelzését. Telepítés (Deployment) Telepítéssel, üzemeltetéssel kapcsolatos tevékenységek. Támogató munkafolyamatok Projektvezetés (management) A fejlesztési projekt működését, menetét irányító projektmenedzsmenttevékenység. Változáskövetés (change and configuration management) A fejlesztés során különféle változások következhetnek be a feltételekben (pl. követelmények változásai). E változások folyamatos figyelése és érvényesítése a tervezésben-kivitelezésben döntő fontosságú. Környezet biztosítása (environment) A fejlesztési folyamatok felülvizsgálata, tervezést és kódolást segítő eszközök biztosítása. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 5
6 A RUP termékei A módszertan különböző termékeket definiál, amelyeket a fejlesztési folyamatban elő kell állítani. A fejlesztés eredménye mindig több, mint a kód: tervek, dokumentációk, modellek. Egyetlen fejlesztési cikluson belül is állandóan használjuk a megelőző tevékenységek dokumentációit, s amennyiben az előállított terméket használják, úgy szinte biztos, hogy előbb-utóbb lesznek módosítási, továbbfejlesztési, bővítési, hibajavítási igények is. Ebben az esetben szintén újra felhasználjuk a már elkészített dokumentációkat. A RUP termékei két, egymástól független dimenzió szerint csoportosíthatóak. Beszélünk nézetekről, illetve beszélünk modellekről. Nézetek A különböző nézetek ugyanazon rendszernek lényegében ugyanannyira részletes leírásai, de a rendszer különböző oldalait mutatják. A különböző nézetek lényegében egyenrangúak, illetve az alkalmazás jellege dönti el, hogy melyik nézet mennyire határozza meg az architektúrát. A 4+1 nézet A RUP megfogalmazása szerint a teljes rendszert 4+1 nézetből lehet leírni. A különböző nézetek ugyanazt a rendszert különböző szemszögből láttatják. Például, ha szemügyre vesszük a számítógépes egeret, milyen szempontok szerint modellezhetjük? Többek között nézhetjük belső szerkezetét és az egyes elemek egymáshoz való viszonyát ekkor statikus nézetről beszélünk, és felvázoljuk az egér lényeges alkatrészeit és kapcsolódásukat egymáshoz. 3. ábra Az egér szerkezeti elemei Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 6
7 Ha az egér működését szeretnénk megérteni/bemutatni, akkor dinamizáljuk a modellt (dinamikus nézet): 1: Az egér mozgatása elforgatja a golyót. 2: Az irányérzékelő görgők tartják a golyót, és továbbítják a mozgást. 3: Fényáteresztő résekkel rendelkező tárcsák. 4: Az infravörös LED átvilágít a korongok résein. 5: A szenzorok (optikai kapuk) érzékelik a fényimpulzusokat. 4. ábra Az egér belső működését bemutató modell Mindkét esetben ugyanazt a rendszert vizsgáltuk csak más szemszögből, más nézetben. 5. ábra A RUP nézetei Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 7
8 Tervezési nézet ( Design view) A rendszerben szereplő dolgokat fogalmakat, tárgyakat, kapcsolatokat és együttműködéseket mutatja. Implementációs nézet, avagy Komponens nézet A rendszerben lévő szoftverkomponenseket (exe fájlok, dll-ek, adatbázis-táblák stb.) mutatja. Dinamikus, avagy folyamat nézet A rendszerben lévő zajló folyamatokat, műveleteket, a párhuzamos működést, a processzeket, taskokat, szálakat mutatja. Telepítési nézet A tényleges fizikai telepítést, a hálózati csomópontokat mutatja. Követelmény nézet A rendszer felhasználóit (aktorok/actor), a funkcionalitást (használati eseteket, use case) mutatja. Az egész szoftverfejlesztési folyamatot a követelmények (elsősorban a felhasználó által elvárt szolgáltatások használati esetek) vezérlik, mivel azt és úgy kell megvalósítanunk, amire és ahogyan a felhasználónak szüksége van. Modellek A különböző modellek a rendszer logikailag különböző absztrakciós szintjeit mutatják be. A modellekre jellemző, hogy minden modellt meghatároz a logikailag nála magasabb szinten lévő modell. Az egyes modellek kidolgozása viszonylag szorosan köthető egyrészt a nézetekhez, másrészt a fejlesztés munkafázisaihoz: pl. a követelményelemzés jellegzetes terméke a használati eset modell, az implementáció terméke az implementációs modell, s az implementációs modell értelemszerűen függ a használati eset modelltől. A fejlesztés során a különböző modellek eltérő sebességgel növekednek, a fejlesztésnek már a korai szakaszában viszonylag jól kidolgozott a használati eset modell, míg az implementációs, avagy a teszt modell eleinte alig növekszik. A modelleket diagramokon ábrázoljuk, a diagramokat és az azokon alkalmazható szimbólumokat, definíciókat és az alkalmazási szabályokat az UML (Unified Modeling Language, Egységes Modellező Nyelv) írja le. Korábban (a 4. ábrán) az egér mechanikus és optikai elemeinek együttműködését mutattuk be valósághű ábrázolásban. Ha teljesen szabadon, minden fizikai megkötéstől mentesen akarunk gondolkodni, elvonatkoztathatunk ezektől, és modellezhetjük az egér működését a célnak megfelelő (jelen esetben épp együttműködési) UMLdiagram segítségével. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 8
9 támasztó görgő infra led 3: Támaszt 2: Forgat +fény +átereszt/visszaver golyó 1: Fordul irányérzékelő 1.1: Fordul görgő fényáteresztő tárcsa 1.2: [ha átereszt]:fényimpulzus optikai kapu 6. ábra Az egér működésének absztrakt modellje Az alábbi ábrákon további példákat láthatunk modellekre, illetve az ezeket bemutató diagramokra. Beállítás Bejelentkezés «extend» Diák Bemutatás «extend» Fileválasztás «extend» Feltöltés Tanár 7. ábra Egy oktatási demonstrációs alkalmazás felhasználók szerinti funkciómegoszlását mutató használati eset diagram Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 9
10 Égitest név: Karakter pozíció: Koordináta sugár: Egész szín: Szín kering körülötte * MozgóÉgitest maxtáv: Egész mintáv: Egész keringésiidő: Egész Csillag Sugároz() : void Mozog() : void Hold Bolygó Üstökös Csóvál() : void 8. ábra A Naprendszer objektumait és azok kapcsolatrendszerét bemutató logikai modell diagramja Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 10
11 +Kapcsolat a játékossal, játékelemek megjelenítése Megjelenítő játékfelület «manifest» «program-m... felület +Parancsok értelmezése játékvezérlő Vezérlő Lufik «manifest» «program-m... vezérlő +Lufik létrehozása, rendelkezésre bocsájtása, megszüntetése +Találatvizsgálat +Lövedékek indítása, rendelkezésre bocsájtása, megszüntetése; Ágyú működtetése Lufik lufi Löv és lövedék lufigép ágyú «manifest» «manifest» «program-m... lufik «program-m... lövés 9. ábra Egy játékprogram komponensmodellje iskola + Beoszt() : void + Felvesz() : void 2: Tanít() tanár + Tanít() : void - Felkészül() : void - Előad() : void - Feleltet() : void 2.1: Felkészül() 2.2: Előad() 2.3: Feleltet() 3: Tanul() 4: Felel() 1: Beiratkozik() diák + Tanul() : void + Felel() : void + Beiratkozik() : void 10. ábra Iskola Tanár Diák együttműködést ábrázoló diagram Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 11
12 Vevő Egy internetes árurendelés folyamata Belépés a weboldalra «datastore» Készlet Termék kiválasztása Összetett lépés Van kiválasztott termék? [igen] [nem] Vége Bankkártya megadása Rendelés elküldése Szállító Raktárkészlet ellenőrzése Bankkártya ellenőrzése Rendben? [nem] Rendben? [igen] [igen] [nem] Rendelés megszakítása Összetett lépés Kifizetés Termék küldése «datastore» Készlet Vége 11. ábra Folyamatot ábrázoló diagram Termékek A RUP termékei a legfőképpen modellekben megtestesülő dokumentumok, és természetesen maga a szoftver. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 12
13 Az RUP jellemzői Az eddigiek alapján összefoglalhatjuk a RUP jellemzőit, amit az alábbi háromlábú székkel szoktak illusztrálni. 12. ábra A RUP háromlábú széke" Követelményvezérelt jelleg A korábban említett, a fejlesztési projektek kudarcait elemző felmérések, vizsgálatok szerint a problémák egyik fő oka a követelmények nem megfelelő kezelése. A módszertan ezért az egyik fő szempontként emeli ki a követelménymenedzsment fontosságát és érvényesíti is mind a nézethierarchiában, mind a fejlesztési munkafolyamatokban. A követelménymenedzsment folyamatos tevékenység, amely végigkíséri a fejlesztés teljes folyamatát. Célja a követelmények feltárása, rendszerezése, dokumentálása. További fontos feladata a követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra. A módszertan elvárja, hogy a befoglaló projektirányítás megoldja és alkalmazza a követelmények menedzselését mind módszerben, mind szervezésben, mind dokumentációs megoldásaiban. Architektúra központúság Architektúra alatt egy rendszer meghatározó összetevőit és ezek kapcsolatait értjük. Az architektúra célja: átláthatóvá teszi a fejlesztést; könnyebben felismerhetők az újrafelhasználható elemek; átlátható projektmenedzsment; kockázatok csökkentése; lehetővé válik a párhuzamos fejlesztés. Architekturálisan fontos nézetek Az alkalmazás jellegének megfelelően a 4+1 nézet közül némelyek jelentősen befolyásolják az architektúrát, míg mások alig hatnak rá. Például egy erősen osztott alkalmazás esetében jelentős, meghatározó szerepe lesz a telepítési nézetnek, míg egy párhuzamos feldolgozásokra kitalált alkalmazás esetében a dinamikus nézet architektúra lesz meghatározó. Az alkalmazás jellegétől függetlenül a követelmény (használati eset) nézetnek mindig kitüntetett szerepe van (erről szól a háromlábú szék első lába). Ugyanígy nagyon sokszor architektúrát meghatározó a tervezési nézet. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 13
14 Az architektúra az alkalmazás jellege alapján Egy alkalmazás funkcionális elemeinek (objektumok) csoportosítására, az alkalmazás alapvető jellegének meghatározására az MVC koordinátarendszert, illetve a sztereotípus fogalmát használjuk. E megfogalmazás szerint minden objektum elhelyezhető a model view control koordináta-rendszerben, s minden jól tervezett objektum jellegzetesen e három koordináta valamelyike felé húz. Így beszélhetünk egyed, határ illetve vezérlő jellegű (sztereotípiájú) objektumokról. 13. ábra Objektumok kategóriái Az egyed jellegű objektumok jellemző feladata az adatok tárolása. A határobjektumok a külvilággal tartják a kapcsolatot (pl. felhasználói felület, ablakok), a vezérlő objektumok pedig a szakterületi feladatokat, műveleteket ismerik, látják el, illetve koordinálják a működést. E gondolatmenet általánosítható az alkalmazásokra is, hiszen egy-egy alkalmazás nem más, mint egy meglehetősen nagy, összetett objektum. Az alkalmazás jellege (egyed, vezérlő, vagy határ dominanciájú alkalmazás) befolyásolja, hogy a tervezési modell mely sztereotípusai lesznek architekturálisan meghatározóak. Egyed 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 szakterületi modell, illetve a hosszú távú tárolás az esetek többségében ez adatbázis-táblákat jelent. Ezeknél az alkalmazásoknál érdekes feladat a relációs szemléletű adatbázis-logika illetve az objektumos szemléletű kezelői felület (és alkalmazáslogika) összekapcsolása. Felület dominanciájú alkalmazások Jellegzetes desktop alkalmazások, szövegszerkesztők, képmanipulá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 diagramjai a mérvadóak, valamint a felhasználói felület prototípusa. Algoritmus dominanciájú alkalmazások A tudományos illetve műszaki számításokat végző alkalmazások jellegzetes csoportja. Az architektúrát a megvalósítandó algoritmusok döntően befolyásolják. A rendszer leírása szempontjából az aktivitás- illetve az állapotdiagramok döntő jelentőségűek. Ilyen alkalmazások meglehetősen ritkán fordulnak elő a napi fejlesztői gyakorlatban. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 14
15 Rétegzett architektúra Az alkalmazást rétegekkel és a réteg által biztosított interfészekkel modellezik. Az egyes rétegeknek jellegzetesen különböző feladatkörük van, mint például felhasználói felület, vezérlés, adattárolás. Az elvileg ideális esetben minden egyes réteg csak és kizárólag a vele szomszédos rétegekkel tart kapcsolatot. A rétegzett architektúrának jellegzetes példája a hálózati protokollok OSI referenciamodellje, avagy az elterjedt háromrétegű modell, ami kezelői felületet, alkalmazáslogikát és adatkezelési logikát definiál. Az alkalmazások rétegzett felépítésével a szoftver összetevőiről szóló fejezetben már részletesebben foglalkoztunk. Példa speciális architektúrájú alkalmazásra: a kliens-szerver architektúra Hálózati együttműködést lehetővé tevő megoldásminta, melynek legfontosabb elemei: 14. ábra Kliens-szerver architektúra Független szerverek halmaza A szerverek a rendszer többi eleme számára valamilyen szolgáltatást nyújtanak, mint például az állományszerverek, amik állományok osztott elérését biztosítják, adatbázis, nyomtató- vagy videoszerverek, amik szintén speciális szolgáltatásokat ajánlanak fel. Kliensek halmaza A kliensek hozzáférhetnek a szerverek által biztosított szolgáltatásokhoz. A kliensek jellemzően önálló létjogosultsággal rendelkező alrendszereket valósítanak meg. Ismerik és használják a szervereket és a szerverek által megvalósított szolgáltatásokat. A kliensalkalmazásból jellemzően számos példány futhat egyidejűleg. Hálózat Biztosítja a kliensek és szerverek közötti kommunikációt. Elvileg elhagyható elem, amennyiben fizikailag ugyanazon a gépen fut mind a szerver-, mind a kliensalkalmazás. A kliens-szerver architektúra legfőbb előnye az osztott architektúrája. Hatékony sok egymástól független feldolgozás esetében. Meglehetősen széles határok között könnyen bővíthető, mind újabb kliensek, mind újabb szerverek viszonylag könnyen csatlakoztathatóak a rendszerhez. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 15
16 Példa a vezérlési architektúrára: az eseményszórásos modell A vezérlési architektúrák az alkalmazás dinamikus viselkedését, a vezérlési folyamatot írják le. Az eseményvezérelt alkalmazások (pl. maga a Windows és a Windowsalkalmazások) elterjedt megvalósítása az eseményszórásos modell. 15. ábra Eseményszórásos modell összetevői Az eseményszórásos modellben megkülönböztetünk eseményforrást, eseményobjektumot és eseménykezelőt, avagy -nyelőt. Az esemény- illetve üzenetkezelő alrendszer a keletkezett eseményobjektumot elvileg minden alrendszer számára eljuttatja, s az alrendszer az eseményobjektum, illetve a saját állapota alapján eldönti, kíván-e reagálni az eseményre. Hatékonysági megfontolásokból általában a potenciális kezelőobjektumnak be kell jelentenie az érdeklődést bizonyos helyen keletkezett, avagy bizonyos típusú eseményekre, s ebben az esetben a keletkező eseményobjektumok csak az őt hallgató, figyelő objektumokhoz jutnak el. A hallgató objektum eldöntheti, reagál-e az eseményre, s ha igen, akkor hogyan. Iteratív és inkrementális jelleg A módszertan által preferált és a korábban bemutatott fejlesztési folyamat fázisiterációk-mérföldkövek felépítése előírja ezt a fajta megközelítést. 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 megrendelő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. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 16
17 16. ábra A kockázat mértékének alakulása a fejlesztés ideje alatt 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 szoftververzió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ására, 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ésszerű 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. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 17
18 17. ábra A rendszer megfelelése a végső követelményeknek a fejlesztés ideje alatt Iteratív fejlesztés esetén folyamatos az integráció. A folyamatos integráció révén az 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 rendszeres 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 nemcsak 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. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 18
19 Az egyes szakterületek, munkafolyamatok technológiafü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ó szoftverkomponenseket is. Az iteratív fejlesztés tervszerű 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 a RUP iterációi 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 tervezi a RUP. Összefoglalás A RUP módszertan létrehozásának célja az volt, hogy kiküszöbölje a fejlesztési folyamatban felmerülő, a projekt sikerét megakadályozó problémákat. A fejlesztési projektek sikerességét három tényező alapján mérjük: 1. költségkeret betartása, 2. határidő betartása, 3. a követelményeknek való megfelelés. A három tényező nyilvánvalóan összefüggésben áll egymással (pl. határidőcsúszás következményeként felléphet költségtúllépés; a követelményváltozások miatti újratervezés/újrakódolás szintén költségemelkedéssel és valószínűleg határidőcsúszással jár; a határidők betartásának céljából végrehajtott pótlólagos erőforrásbevonás úgyszintén növeli a költségeket stb.) A 80-as és 90-es évek kutatásai a problémák okaként elsősorban nem technológiai, hanem módszertani hiányosságokat jelöltek meg, ezen belül is elsősorban a fejlesztés ideje alatt bekövetkező változások követésének, illetve az együttműködéskommunikáció problémáira világítottak rá. A RUP ezekre a problémákra a fejlesztési folyamat és a folyamat során elvégzendő tevékenységek, a tevékenységek egymásra épülésének, egymásutániságának, ugyanakkor a változások követésének definiálásával, megoldásával és előírásával próbál válaszolni. A módszertan elméleti módszertan, ami azt jelenti, hogy ajánlásait, mintáit és módszereit a különböző típusú fejlesztési feladatok esetében mindig át kell vizsgálni, és a helyzetnek megfelelően kell azokat alkalmazni. További információk: Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 19
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észletesebben01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
RészletesebbenS01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
RészletesebbenV. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
RészletesebbenA 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észletesebben30 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észletesebbenA fejlesztés módszertana
A fejlesztés módszertana (A térkép) 2003. május ago@intermail.hu http://www.ago.sw.hu 2003. május 1/58 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
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenSoftware Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/
RészletesebbenInformá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észletesebbenInformatikai projektellenőr szerepe/feladatai Informatika / Az informatika térhódítása Függőség az információtól / informatikától Információs
Bevezetés Projektellenőr szerepe és feladatai Informatika Informatikai függőség Informatikai projektek Mérnöki és informatikai feladatok találkozása technológiák 1 Tartalom Informatikai projektellenőr
RészletesebbenInformá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észletesebben5. 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észletesebbenCCS 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észletesebbenA 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észletesebbenTOGAF elemei a gyakorlatban
TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési
RészletesebbenSzoftverfejleszté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észletesebbenSzoftverfejlesztő képzés tematika oktatott modulok
Szoftverfejlesztő képzés tematika oktatott modulok 1148-06 - Szoftverfejlesztés Megtervezi és megvalósítja az adatbázisokat Kódolja az adattárolási réteget egy adatbáziskezelő nyelv használatával Programozás
RészletesebbenDW 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észletesebbenProjectvezető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észletesebbenAutóipari beágyazott rendszerek Dr. Balogh, András
Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat
RészletesebbenSzoftvertechnoló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észletesebbenSzoftver ú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észletesebbenObjektum 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észletesebbenBevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
RészletesebbenTartalom. 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észletesebbenRendszer szekvencia diagram
Rendszer szekvencia diagram Célkitűzések A rendszer események azonosítása. Rendszer szekvencia diagram készítése az eseményekre. 2 1.Iteráció Az első igazi fejlesztési iteráció. A projekt kezdeti szakaszában
RészletesebbenTisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu
Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu BEVEZETŐ az ASP-szolgáltatásról Az ASP-szolgáltatás (Application Service Providing) előnyei A megrendelő
RészletesebbenFogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.
Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Email: info@silentsignal.hu Web: www.silentsignal.hu. 1 Tartalom 1. BEVEZETŐ... 3 1.1 Architektúra (terv) felülvizsgálat...
RészletesebbenElő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észletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
RészletesebbenJárműinformatika A járműinformatikai fejlesztés
Járműinformatika A járműinformatikai fejlesztés 2016/2017. tanév, II. félév Dr. Kovács Szilveszter E-mail: szkovacs@iit.uni-miskolc.hu Informatika Intézet 107/a. Tel: (46) 565-111 / 21-07 A járműfejlesztés
RészletesebbenMiskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenA tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenSzolgá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észletesebbenELTE, Informatikai Kar december 12.
1. Mi az objektum? Egy olyan változó, vagy konstans, amely a program tetszőleges pontján felhasználható. Egy olyan típus, amelyet a programozó valósít meg korábbi objektumokra alapozva. Egy olyan változó,
RészletesebbenS01-8 Komponens alapú szoftverfejlesztés 2
S01-8 Komponens alapú szoftverfejlesztés 2 Tartalom 1. Komponens megvalósítása: kölcsönhatás modell, viselkedési vagy algoritmikus modell és strukturális modell. 2. Komponens megtestesítés: finomítás és
RészletesebbenVezető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észletesebbenProgramozási technológia
Programozási technológia Dinamikus modell Tevékenységdiagram, Együttműködési diagram, Felhasználói esetek diagramja Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Tevékenység diagram A tevékenység (vagy
RészletesebbenUML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
RészletesebbenProgramfejleszté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észletesebbenInformatikai projekteredmények elfogadottságának tényezői
Informatikai projekteredmények elfogadottságának tényezői Rabi Ákos 2014.02.18. Tartalom 1. Problémafelvetés Informatikai projekteredmények elfogadottsága 2. Informatikai projektek sikertényezői 3. Szoftverek
RészletesebbenSzoftverarchitektú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észletesebbenVerzió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észletesebbenDesigner képzés tematika oktatott modulok
Designer képzés tematika oktatott modulok 1142-06 - Számítógépkezelés, szoftverhasználat, munkaszervezés o Hardvert üzemeltet, szoftvert telepít o Irodai programcsomagot egyedi és integrált módon használ
RészletesebbenVerifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
RészletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
RészletesebbenE-learning tananyagfejlesztő képzés tematika oktatott modulok
E-learning tananyagfejlesztő képzés tematika oktatott modulok 1142-06 - Számítógépkezelés, szoftverhasználat, munkaszervezés o Hardvert üzemeltet, szoftvert telepít o Irodai programcsomagot egyedi és integrált
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
RészletesebbenALKALMAZÁ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észletesebben4. 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észletesebbenIII. Alapfogalmak és tervezési módszertan SystemC-ben
III. Alapfogalmak és tervezési módszertan SystemC-ben A SystemC egy lehetséges válasz és egyben egyfajta tökéletesített, tovább fejlesztett tervezési módszertan az elektronikai tervezés területén felmerülő
RészletesebbenSzoftver-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észletesebbenAmi a vízesésen túl van
Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két
RészletesebbenBá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észletesebbenBevezetés. Szendrei Rudolf Informatikai Kar Eötvös Loránd Tudományegyetem. Programozási technológia I. Szendrei Rudolf. Bevezetés. Szoftvertechnológia
UML tervező JAVA fejlesztő és Informatikai Kar Eötvös Loránd Tudományegyetem 1 Tartalom 1 UML tervező JAVA fejlesztő és 2 UML tervező JAVA fejlesztő és 2 technológiai áttekintése UML tervező JAVA fejlesztő
RészletesebbenTartalommenedzser képzés tematika oktatott modulok
Tartalommenedzser képzés tematika oktatott modulok 1154-06 - Tartalommenedzser Elektronikus hírújságot tervez, szerkeszt és működtet WEB-lapok tartalmának szerkesztését, karbantartását végzi Tematikus
RészletesebbenMiskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
RészletesebbenProgramrendszerek 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észletesebbenDr. 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észletesebbenInformatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező
11-06 Rendszer/alkalmazás -tervezés, -fejlesztés és -programozás A 10/07 (II. 27.) SzMM rendelettel módosított 1/06 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő
RészletesebbenSzámítógépes munkakörnyezet II. Szoftver
Számítógépes munkakörnyezet II. Szoftver A hardver és a felhasználó közötti kapcsolat Szoftverek csoportosítása Számítógép működtetéséhez szükséges szoftverek Operációs rendszerek Üzemeltetési segédprogramok
RészletesebbenProgramozá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észletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
RészletesebbenFogalmi modellezés. Ontológiák Alkalmazott modellező módszertan (UML)
Fogalmi modellezés Ontológiák Alkalmazott modellező módszertan (UML) Fogalom képzés / kialakítás Cél: Példák: A fogalom képzés segít minket abban, hogy figyelmen kívül hagyjuk azt, ami lényegtelen idealizált
RészletesebbenInternetes alkalmazásfejlesztő képzés tematika oktatott modulok
Internetes alkalmazásfejlesztő képzés tematika oktatott modulok 1142-06 - Számítógépkezelés, szoftverhasználat, munkaszervezés o Hardvert üzemeltet, szoftvert telepít o Irodai programcsomagot egyedi és
Részletesebben1 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észletesebbenBevezeté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észletesebbenNyí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észletesebbenNyilvá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észletesebbenInformatikai prevalidációs módszertan
Informatikai prevalidációs módszertan Zsakó Enikő, CISA főosztályvezető PSZÁF IT szakmai nap 2007. január 18. Bankinformatika Ellenőrzési Főosztály Tartalom CRD előírások banki megvalósítása Belső ellenőrzés
RészletesebbenSoftware 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észletesebbenGazdasági informatika alapjai
PSZK Mesterképzési és Távoktatási Központ / H-1149 Budapest, Buzogány utca 10-12. / 1426 Budapest Pf.:35 II. évfolyam Név: Neptun kód: Kurzus: Tanár neve: HÁZI DOLGOZAT 2. Gazdasági informatika alapjai
RészletesebbenMIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
RészletesebbenSzekvencia diagram. Szekvencia diagram Dr. Mileff Péter
Dr. Mileff Péter 1 2 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é mutató időtengelyt képvisel.
RészletesebbenAgilis 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ÁSZF 1. melléklet. GST-Max Kereskedelmi és Szolgáltató Kft. 1021 Budapest, Völgy utca 32/b. részéről
ÁSZF 1. melléklet GST-Max Kereskedelmi és Szolgáltató Kft. 1021 Budapest, Völgy utca 32/b részéről Click&Flow licenc, éves szoftverkövetés és kapcsolódó szolgáltatások díjai 1/6 Tartalomjegyzék Click &
RészletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
RészletesebbenA 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észletesebbenIRÁ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észletesebben1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS
1. SZÁMÚ FÜGGELÉK MŰSZAKI LEÍRÁS Az Enterprise Architect (EA) modell illesztése az számú, Komplex népegészségügyi szűrések elnevezésű kiemelt projekt megvalósításához kapcsolódóan 1. Fogalmak és rövidítések
RészletesebbenHELYES 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észletesebbenSzakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman
Szakterületi modell A fogalmak megjelenítése 9. fejezet Applying UML and Patterns Craig Larman 1 Néhány megjegyzés a diagramokhoz Ez a tárgy a rendszer elemzésről és modellezésről szól. Noha például egy
RészletesebbenOrvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT
Orvostechnikai eszköz tesztelése DSS Unit test Taliga Miklós BME-IIT Szabványok és direktívák Orvostechnikai eszközök feladatai Objektív eredmények képzése Embernek érzékelhetetlen paraméterek mérése Sokféle
RészletesebbenAZ 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észletesebbenNETinv. Új generációs informatikai és kommunikációs megoldások
Új generációs informatikai és kommunikációs megoldások NETinv távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés NETinv 1.4.2 Távközlési szolgáltatók és nagyvállatok
RészletesebbenElőadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.
Fejlesztéskövetés fejvesztés nélkül, avagy Kiadáskezelés megvalósítása banki környezetben Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.
RészletesebbenProjekt siker és felelősség
Projekt siker és felelősség dr. Prónay Gábor 10. Távközlési és Informatikai Projekt Menedzsment Fórum 2007. április 5. AZ ELŐADÁS CÉLJA figyelem felhívás a siker kritériumok összetettségére, az elmúlt
RészletesebbenThe 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észletesebbenBevezetés a kvantum informatikába és kommunikációba Féléves házi feladat (2013/2014. tavasz)
Bevezetés a kvantum informatikába és kommunikációba Féléves házi feladat (2013/2014. tavasz) A házi feladatokkal kapcsolatos követelményekről Kapcsolódó határidők: választás: 6. oktatási hét csütörtöki
RészletesebbenSzámítógép architektúra
Budapesti Műszaki Főiskola Regionális Oktatási és Innovációs Központ Székesfehérvár Számítógép architektúra Dr. Seebauer Márta főiskolai tanár seebauer.marta@roik.bmf.hu Irodalmi források Cserny L.: Számítógépek
RészletesebbenLáthatósági kérdések
Láthatósági kérdések Láthatósági algoritmusok Adott térbeli objektum és adott nézőpont esetén el kell döntenünk, hogy mi látható az adott alakzatból a nézőpontból, vagy irányából nézve. Az algoritmusok
RészletesebbenVárosi tömegközlekedés és utastájékoztatás szoftver támogatása
Városi tömegközlekedés és utastájékoztatás szoftver támogatása 1. Általános célkitűzések: A kisvárosi helyi tömegközlekedés igényeit maximálisan kielégítő hardver és szoftver környezet létrehozása. A struktúra
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?) Év indító IT szakmai nap - PSZÁF Budapest, 2007.01.18 Honnan indultunk? - Architektúra EBH IT
Részletesebben10-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észletesebbenA projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál
A projektvezetési eszköz implementációja hazai építő-, szerelőipari vállalkozásoknál Előadó: Ulicsák Béla műszaki igazgató BRIT TECH Üzleti Tanácsadó Kft. Napirend 1. Az építő-, szerelőipar érdekcsoportjai
RészletesebbenMinőségi téradat-szolgáltatások. fejlesztése és. és üzemeltetése
Minőségi téradatszolgáltatások fejlesztése és üzemeltetése Kolesár András térinformatikus, webfejlesztő Budapest Főváros Kormányhivatala Földmérési, Távérzékelési Földhivatali Minőségi téradat-szolgáltatások
RészletesebbenSoftware 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észletesebbenMegfelelés a PSD2 szabályozásnak, RTS ajánlásokkal Electra openapi
Megfelelés a PSD2 szabályozásnak, RTS ajánlásokkal Electra openapi Gyimesi István Fejlesztési vezető gyimesi.istvan@cardinal.hu CARDINAL Kft. Termékbemutató 2017.05.31. Heiter Ferenc Termékfejlesztési
RészletesebbenCsoportos ü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