Szoftver technológia ProgMat -
|
|
- Rezső Orbán
- 8 évvel ezelőtt
- Látták:
Átírás
1 Szoftver technológia ProgMat - 1. Szoftver életciklus modellek 1.1 Klasszikus waterfall vízesés modell Jellemzői: Technikai problémának tekintia fejlesztést. Nem foglalkozik a kommunikációs csatornákkal. Visszacsatolás túl későn lehetséges. Gyakorlatilag csak a teljes rendszer elkészülte után van rá mód. Diagram: 1.2 Gyors prototípus rapid prototyping modell Jellemzői: Elősegíti a fejlesztő és a felhasználó kommunikációját ellentétben a waterfall modellhez képest. Föleg kis csoportok számára javasolt a tapasztalatok szerint. Diagram: 1.3 Evolúciós inkrementálsi modell Jellemzői: Az eredeti célhoz egyre közelebb álló rendszerek sorozata. Minden egyes rendszer átmegy legalább a tervezés, az implementálás és a tesztelés fázisán.
2 Diagram: 1.4 Újrafelhasználási modell Jellemzői: Alulról felfelé építkező modell. Gyors módszer, ha van elég építőanyag. Azaz elegendő újra hasznosítható elemünk. Hatékonyság a szükséges helyeken utólag javítható. Újrahasználható elemek: Implementáció algoritmusok függvény könyvtárak osztály és objektum könyvtárak szoftver komponensek korábban fejlesztett, hasonló rendszerek Tervezés tervezési minták bevált architekturális megoldások Analízis, specifikáció leginkább az előző fejlesztések tapasztalatai Diagram:
3 1.5 Very High Level Languages Nem-procedurális nyelvek, alkalmazás-generátorok. Jellemzői: A fejlesztő eszköz számára le kell írni, hogy mit csináljon. A többi az eszköz dolga. Általában jól körülhatárolt területekre javasolt, mint például Oracle, FOCUS, Magic-AB alkalmazások. Esetleg hatékonysági problémák léphetnek föl. Diagram: 1.6 Spirál-modell Boehm 1988-s modellje. Újdonság a korábbi modellekhez képest a kockázat kezelés. Jellemzői: A fejlesztés iterációs lépések sorozata. Az egyes iterációkban kitűzött célok folyamatosan fejlődnek. Valamennyi fázis ciklikusan változik. Ezt ábrázolva kapjuk meg a spirálhoz hasonlatos alakzatot. Minden rész megoldását, részmegoldást ki kell értékelni. Elemezni kell az adott megoldás kockázatát. Ha a kockázat kisebb, mint a várható haszon akkor következhet a következő ciklus. Diagram:
4 2. Alapfogalmak (módszer, technika, eszköz) Módszer (methodology): Tudás, azaz a tapasztalat és az ajánlott technikák ( tudás + ajánlott technikák) Jó módszer jellemzői Hatékonyság Racionalítás, azaz tudományos alapok, melyeket a gyakorlat igazol. Konzisztens az egyes fázisokban. Teljes, azaz minden fázisra ajánl megoldást. Ismételhető, azaz személytől független, jól definiált, és megtanulható. Automatizálható és automatizált. Technikák célja: Az egyes részfolyamatok segítése. Információk rögzitése az egyértelműség elsősegítése véget. Kapcsolatok rögzitése. Ellentmondások kiszűrése. Leggyakrabban grafikus felület. Eszközök: Programok, amelyek támogatnak módszer(eke)t techniká(ka)t dokumentáció készítést Jellemzője az integráltság színtje és a támogatott fázisok száma. 3. Dekompozíció Alap probléma a szoftver komplexitása. A megoldás reménye, hogy a részek ösz komplexitása kisebb, mint az egész komplexitása. A dekompozíció lényege a teljes szoftver módszeres részekre bontása. Egy módszer meghatározza a dekompozíció elveit. Funkcionális szemlélet: Program = adatszerkezetek + algoritmusok Dekompozíció alapja adat avgy processz. Módja felülről lefelé (top-down) vagy alulról fölfelé (bottom-up). Modulok között kommunikációszükséges ebből következik a belső interface szükségessége. Dualítás elve Modul Processz alapú (Algoritmus) Adat alapú (Adatszerkezet) Adatszerkezet Algoritmus Interface Több lépés szükséges ebből következnek az absztrakciós színtek! Objektum Orientált szemlélet: Program = együttműködő objektumok halmaza Struktúra az osztályok/objektumok közötti kapcsolatok, működás üzenetváltás, és a modulok egysége az osztály. 4. Analízis fázis célja, feladata, szemlélete. Célja: A projekttel szemben támasztott követelméynek meghatározása. Felhasználó igényei. Elérendő célok és haszon. Emberi, gépi erőforrások.
5 Időszükséglet. Költségek. Szervezeti követelmények. Feladata: A rendszerre vonatkozó összes információt összegyűjteni és megérteni. Ehhez szükséges elemezni a meglévő, jelenleg müködő és a tervezett, leendő rendszert. Szemlélete: A legfontosabb szempontok a teljesség, az egyértelműség és a dokumentáltság. A cél tehát a harácsolás! 5. Analízis fázis módszerei (használható) Használható módszerek: A felhasználói munkafolyamat megfigyelése. Gyakorlat az adott területen. Interjúk, melyekben folyamatosan rákérdezünka dolgokra. Kérdőívek. Az alkalmazás elméletének és gyakorlatának kutatása. Analógia más rendszerekkel. Meglévő dokumentáció tanulmányozása. Eljárási szabályok Bizonylatok Jelentések, összesítések Szervezeti felépítés Munkaköri leírások Hatáskörök szabályozása Vonatkozó külső előírások Törvények, előírások Szerződések, megállapodások, vállalt kötelezettségek CASE eszközök Dokumentációs technikák Teljesség és konzisztencia vizsgálat A további fázisokban felhasználható forma Adatszótár Prototípus készítése Jobb kommunikáció a felhasználóval (Gyors prototípus modell) A felhasználó időben felismerheti az igényei teljesíthetetlenségét vagy pontatlanságát. A fejlesztő jobban megértheti a felhasználó munkamódszereit. Jó munkamódszer jellemzői: Rámenősség Kérdezzünk rá mindenre, mert így a magától érthetödö dolgokra, mehanizmusokra is fényderülhet. Ne hagyatkozzunk a megérzéseinkre vagy feltételezéseinkre. Pártatlanság Ne befolyásoljanak részérdekek. Az összes résztvevő számára legjobb megoldást keressük. Előítélet mentesség tételezzük fel, hogy minden lehetséges. Ne fogadjuk el feltétel nélkül pl. Ezt mindig is így csináltuk...
6 Ezt én mindig így oldottam meg eddig... A hagyomány lehet, hogy már csak értelmetlen megszokás. Figyeljünk a részletekre Minden tény összefügg(het) más tényekkel. Minden definíció legyen precíz. Gondoljunk a kivételes esetekre is. Egy adat/információ a rendszerben csak akkor felesleges, ha mindenkinek az! Kreativitás Tekintsünk friss szemmel a rendszerre. 6. Követelményekosztályozása jellemzésük (3db) Három absztrakciós szint: Felhasználói követelmények Rendszerkövetelmények Szoftver tervervezés specifikációja. Ennek az elkészítésének a feladata a specifikációs fázis feladata. Szokásos felosztás: Funkcionális követelmények Nem funkciónális követelmények Szakterületi követelmények Funkciónális követelmények: A rendszertől várt funkciók és szolgáltatások leírása. Különböző részletezettséggel adhatók meg. A felhasználó vagy a fejlesztő szemszögéből is megfogalmazhatók. Elvben teljesek és ellentmondás mentesnek kell lennie. A késöbbi munkafolyamatok során felfedezett hiányosságok javítandók, így a fejlesztés során egyre pontosabb leírást állítunk elő. Nem funkcionális követelmények: Nem közvetlenül a rendszer szolgáltatásaira vonatkozó követelmények. Általános rendszertulajdonságok, például Megbízhatósági, biztonsági szint. Válaszidő, kapacitás igények. Minőségi jellemzők. Környezettel való kapcsolat, például Más rendszerekkel való kapcsolattartás. Hardver és szoftver adottságok, abból adódó korlátozások. Szervezeti szabályok, törvényi előírások. A fejlesztési folyamatra vonatkozó előírások. Használandó módszertan. Előírt minőségbiztosi modell. Előírt/Elvárt fejlesztőeszközök. Problémák: Nem mindig könnyű eldönteni, hogy egy követelmény funkcionális vagy nem funkcionális. Egy nem funkcionális követelmény új funkcionális követelmény megjelenését jelentheti. Szakterületi követelmények: Nem közvetlenül felhasználói igényekből, hanem az alkalmazás által kiszolgált szakma követelményeiből adódik. Adhat új funkcionális vagynem funkcionális követelményt. Jelenthet korlátozást már mefogalmazott követelményhez.
7 Előírhatja egy adott rendszer funkció végrehajtásának módját. Problémák A fejlesztők számára nehezen érthetőek. Gyakran hiányosak, mert bizonyos szabályok a szakmai szakértők számára nyílvánvalóak. Felhasználói követelmények: A rendszer külső viselkedése a felhasználó fogalmaival. Eszközei: Természetes nyelv. Közismert ábrázolási módok, táblázatok. Use-case modell (UML) Problémák Egyértelműség hiánya. Követelmények keveredése. Követelmények összeolvadása. Célszerű elkülöníteni a technikai jellegű renszerkövetelmény leírástól. Tippek... Használjunk egységes formátumot. Használjunk kiemeléseket. Ha szükséges mindennapi szavak jelentésében is egyezzünk meg. Szótár 7. Dokumentáció használói, kik, mire használják Használói Mire használják Megrendelő Menedzserek Rendszertervező Tesztelők, minőségellenőrök Karbantartók Követelmények meghatározása, ellenörzése, változások megadása. Árajánlat készítése, a fejlesztési folyamat tervezése és ellenörzése. Annak megértése, hogy milyen rendszert kell fejleszteni. A rendszer működésének és minőségének ellenörzéséhez. A rendszer működésének és a rendszer részei közötti összefüggések megértéséhez. 8. Analízis és specifikációs fázis összehasonlítása (fogyasztó, nyelv,...) Analízis Specifikáció Fogyasztó: Felhasználó Szoftver fejlesztő Nyelv: Természetes nyelv Formális nyelv Pontosság: Nem precíz Precíz Terminológia: Az alkalmazás szakkifejezései Szoftver terminológia Szemlélet: Nem technológiai Technológiai
8 9. Strukturált specifikációs technikák (2 db, ábra, darabonként rövid leírás) Három komponens: Ezért léteznek Processz-specifikációs és Adat-specifikációs technikák. Processz-specifikáció: Adatfolyam diagram Állapotátmenet diagram állapotok, átmenetek, feltételek Döntési tábla, döntési fa. Mátrixok a függőségek időbeliségek ábrázolására. Adat-specifikáció: ER diagram. (EER is?) Jackson ábra 10. Specifikációs ajánlások (IEEE, RUP) IEEE: Követelmény analízis során készített dokumentum kiegészítése az alábbiakkal Rensdzerkövetelmény specifikáció Funkcionális és nem funkcionális követelmények pontos leírása. Más rendszerekkel való együttműködéshez szükséges interface-ek. Felhasználói interface leírása. Rendszermodellek A rendszer komponensei és azok kapcsolatai. Rendszer és környezetének kapcsolatai. Adatfolyam modellek. Szemantikus adatmodellek. RUP: SRS Körülbelül, mint az IEEE ajánlása. A rendszer funkciónalításait összefoglaló Use-case modell megalkotása. A Use-case modellben nem jól dokumentálható követelmények leírása. SAD Rendszermodellek leírására. A tervezési fázis során kibővül. Test Plan Tesztelési terv. 11. A tervezés szintjei, azok jellemzői (3 db) Külső (interface) tervezés.
9 Architekturális tervezés. Részletes tervezés. Külső tervezés: A szoftver külvilággal való kapcsolatának megtervezése. Csak technikai kérdés a más szoftverekkel és hardverekkel való kapcsoalt. A felhasználói felület tervezése kulcskérdés, mert ez jeleníti meg a program funkcionalítását a felhasználó felé. Nem csak technikai szempontok vannak. Prototípus készítése hasznos lehet. Időben elhúzódó is lehet. Diagramok: Kapcsolatok. Időben elhúzódó is lehet! Architekturális tervezés: A rendszer struktúrájának megtervezése. Több lépéses folyamat. A lépések száma mérettől függ. Egy alacsonyabb szint a felette lévő dekompozíciójával vagy az absztrakciós szint csökkentésével jön létre. Bármely szinten álló struktúra, modulok és a közöttük lévő interface-ek rendszere. Diagram: Strukturális tervezés: A tervezés végét jelzi, ha a modulok belső komplexitása és az interface-ek komplexitása hasonló. Objektum-Orientált megközelítésnél modul az objektum.
10 12. Objektum Orientált technológiák Programnyelvek (OOP) Szoftver trevezés (OOD) Szoftver specifikáció (OOA) Szoftver követelmény analízis (OORA) OOA: A rendszer megkívánt viselkedésének leírása. Felfedezzük a problématér (domain) lényeges osztályait illetve objektumait és kapcsolataikat a követelmény analízis felhasználásával. Osztály vagy objektum lehet esemény (helyfoglalás) OOD: szerep (utas) szervezeti egység (légitársaság) (al)rendszer (repülőgép) processz (járat) hely (célállomás) eljárás, függvény Feladata megtalálni és kiválasztani a megoldási tér osztályait és objektumait, azok viszonyait és együttműködésük módját. A megoldási tér osztályai Problématér osztályainak a leképzései. A megoldás céljából a tervező által létrehozott osztályok. Diagram: 13. UML fogalma, célkitűzései Fogalma: Az UML egy nyelv arra, hogy specializáljuk, vizualízáljuk, megkonstruáljuk és dokumentáljuk a szoftvert üzleti és egyéb nem szoftveres renszerek számára. Az UML a legjobb technikák gyűjteménye. Célkitűzései:
11 Kifejező vizuális modellező nyelv biztosítása. Fejlesztés támogatása. Kommunikáció támogatása. Lehetőség az alap koncepció bővítésére és specializálására. Alkalmazkodni tudjon a különböző fejlesztések szükségleteihez. Programozási nyelvtől és módszertantól független legyen. Biztosítson formális alapot a modellező nyelv megértéséhez. Támogatja az objektum orientált eszközök fejlesztését. Eddigi gyakorlati tapasztalatok integrálása. Magas szintű fejlesztési koncepciók támogatása. 14. Sorolja fel csoportosítva az UML diagramjait! Use-case diagram Osztály diagram Viselkedés diagrammok állapot diagram aktivitás diagram sorrend diagram együttműködési diagram Implementációs diagram komponens diagram telepítési diagram Kiterjesztési mehanizmusok Az UML tehát nem módszertan! 15. UML kiterjesztési mehanizmusai Feladata: Szabványos jelölésrendszer testre szabása Szabványos elemekkel nem leírható modell tulajdonságok rögzítése. Fajtái: Sztereotípia : új modell elemek jelölésére :: << sztereotípia >> Megszorítás : az UML más jelöléseivel meg nem adható tulajdonságok :: {megszorítás leírása} Kulcsszavas értékek : modell elemek speciális jellemzőinek megadására. :: {kulcsszavas érték} Megjegyzések :: {megjegyzés} 16. USE CASE diagram feladata, elemei, elemeinek jelölése A rendszer határait jelölhetjük ki vele. Lényeges szerepe van a követelmény analízis során. Ez a modell jellemzi a rendszer működését a felhasználó (Actor) és a felé irányuló szolgáltatások illetve funkciók (Use Case) között. Actor/Aktor: A felhasználó egy szerepe a rensdzerben. Több felhasználó egy aktor Egy felhasználó több aktor Aktor lehet külső rensdzer is.
12 Use case: Egy jól meghatározott funkció, amelynek végrehajtása a rendszer és egy külső entitás közötti üzenetváltást kíván. A rensdzer, egy alrendszer vagy egy osztály objektumai által végrehajtott funkció együttes. Pontos leírása is szükséges. Kapcsolatok: Aktor és use case között asszociáció, melynek akár a számossága is jelölhető. <<include>>:a1 magában foglalja A2-t. (részletezés, vagy ismétlődés kezelése) <<extend>>: A1 működését A2 kiegészíti. (többlet funkciók vagy speciális esetek) Általánosítás Elemei: Példák: A rendszert egy téglalappal kerítjük körbe, a felhasználó ezen kívül helyezkedik el. Általánosítás, extend és include.
13 20. Szekvencia diagram feladata, elemei, elemeinek jelölése Objektumok közötti üzenetváltások az időben. (függölegesen lefele telik az idő) Elemei: Példák: Életvonal, élettartam kezdete, üzenetek. Beágyazott üzenet, alternatív működés, visszatérés, elágazás.
14 21. Állapot diagram feladata, elemei, elemeinek jelölése Egy adott objektum lehetséges állapotai, átmenetek egyes állapotok között. Állapotváltozások és az ehhez kapcsolható események, az objektum értékeihez kapcsolható feltételek [feltétel] formában, valamint az ismétlődés jelzése x. Kezdő és végállapot. Egy állapot részletezhető (strukturált áll. Diagram). Állapotok közt lehet álltalánosítás kapcsolat. Elemei: Példa: Állapot jelölése, lehetséges állapotok felsorolása. Kezdő pont (vég pont ugyan az, mint az aktivitási diagramnál), állapot, sima/parametrizált átmenet. 22. Együttműködési diagram feladata, elemei, elmeinek jelölése Hasonlóan az állapot diagramhoz, szintén objektumok közötti üzenetváltások az időben. Elemei. A példa objektumok. Aktív, vastag keret vagy {akcive } megszorítás üzenetet küldhet másik objektumnak. Passzív, üzenet hatására aktivizálódik. Multiobjektum, objektumok egy csoportja. Az együttműkdödő objektumok. Vonallal összekötve.
15 A megfelelő osztályok között az osztálydiagramon asszociációnak kell lennie! Üzenetek. Objektumok közötti nyilak, sorszámozva és névvel ellátva. A nyíl iránya jelzi az üzenetküldés irányát. A sorszám pedig sorrendiséget jelez. Az üzenetnek lehet. Argumentuma és eredménye. Jele a kiskörből kiinduló nyíl. Az adatáramlás irányát jelzi. A nyílon az argumentum vagy az eredmény neve. Az ábrán szerepelhet aktor is, ekkor tőle indul az első üzenet. Példák, jelölések: Példa, multi objektum, argumentumos üzenet, aktor. 23. Aktivitási diagram feladata, elemei, elemeinek jelölése Időben lezajló változások ábrázolása a végrehajtandó tevékenységek és azok sorrendjének megadásával. Alapjai A munkafolyamat diagram. A folyamatábra. Alapelemei Tevékenységek (ívelt oldalú téglalap) Átmenet (nyíl) Szinkronizációs vonal (vastag vízszíntes vonal darab) Döntési pont (rombusz) A diagram függőlegesen sávokra oszthatók. Egy sáv egy felelőssségi kört határoz meg/jelöl.
16 Elemei: Példa: Kezdet, vég, szinkrozinációs vonal, döntési pont. 24. Komponens, telepítési diagram feladata, elemei, elemeinek jelölése Komponensek fizikai alkotóelemek, melyek tipikusan forrás-állományok könyvtárak futtatható állományok dokumentumok adatállományok szoftver komponensek Definiált sztereotípiák << executable >>
17 << library >> << tables >> << files >> << document >> Telepítési diagram tartalma a rendszer hardver elemei és a közöttük lévő fizikai viszonyok. Valamint a hardver és a szoftver elemek összerendelése. Példák/Elemek: Komponensek és a kapcsolatok. Telepítési diagram (kockák a hardverek), komponensek, kapcsolatok es módjai. 26. OMT szemlélete, modelljei (ábra) OMT szemlélete Alkalmazás 3 része Objektum modell - mivel A rendszer általános struktúrája. Funkcionális dekompozíció helyett struktúrális. Jelölésrendszere osztály és/vagy komponens diagram.
18 Funkcionális modell - mi A rendszeren belüli számítások, feldolgozások. Nem tartalmaz időt. Megadhatjuk az objektum modell műveleteit, a dinamikus modell akcióit és az objektum modell korlátozó feltételeit. Eszközei a DFD, aktivitási és együttműködési diagram. Dinamikus modell - mikor A rendszer építőelemeinek viselkedése, időbeli változása. Minden objektumra hogyan változtatja állapotát és hat a környezetére. Eszközei az állapot, sorrend és az eseményfolyam diagram. Ábra: Krumpli modell, az alkalmazás összetevői. 27. OMT fejlesztés fázisa Analízis A rendszer lényeges elemeinek leírása, a feladat szöveges leírásának ellemzésével. Rendszertervezés Alrenszerekre bontás A megvalósítás stratégiai döntései. Erőforrások elosztása. Optimalizálandó tulajdonságok. Alrendszerek közötti kommunikáció. A végrehajtás/vezérlés módja. Objektum tervezés A három modell összhangba hozása. (Dinamikus, Funkciónális és a Objektum modell) Adatszerkezetek és algoritmusok. Implementáció A modell lefordítása egy programozási nyelvre. 28. OMT analízis fázis objektum modell Osztályok azonosítása. Megfelelő osztályok kiválasztása. Törlendők
19 Redundáns osztályok Felesleges osztályok Pontatlan osztályok Attribútomok Műveletek Szerepkörök Implementációs elemek Osztályok leírása. Asszociációk azonosítása. Többszörös asszociációk átalakítása. Asszociációk szemantikájának ellenörzése. Attributumok azonosítása. Megfelelő attributumok kiválasztása. Általánosítás. Elérési útak ellenörzése. Modulok meghatározása. Finomitás, ha a rendszer összetetsége indokolja. 29. OMT analízis fázis dinamikus modell Forgatókönyvek készítése. A működést kisérő események. Felhasználói felület. Vezérlési Információcsere Szekvencia diagram rajzolása. Állapot diagram rajzolása. Eseményfolyam digram készítése. 30. OMT analízis fázis funkciónális modell Be/Ki meneti értékek azonosítása. Adatfolyam diagram megrajzolása. A transzformációk specifikálása. Objektumok közötti korlátozások. Optimalizálandó értékek meghatározása. 31. OMT rensdzertervezés A megvalósítás magas szitű döntései. Alrendszerekre bontás. Információ áramlás az alrendszerek között. Lényegi konkurencia meghatározása. Alrenszerek processzorokhoz és taskokhoz rendelése. Erőforrás igény. Kapcsolódás eszköze. Adattárolás eszközének kiválasztása. Globális erőforrások elosztásának szabályozása. (memória, processzor, hálózat, stb.) Vezérlés elvének kiválasztása. A rensdzer háttérfeltételeinke meghatározása. Felhasználói felület /külső interface tervezése.
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é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é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é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é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é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é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é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é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é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észletesebbenObjektumorientá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é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é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észletesebbenObjektumorientá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é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é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észletesebbenModellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK
Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell
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é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é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é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észletesebbenAbsztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:
Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban
RészletesebbenObjektum orientált programozás Bevezetés
Objektum orientált programozás Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 03. 04. OOPALAP / 1 A program készítés Absztrakciós folyamat, amelyben a valós világban
RészletesebbenSzoftverminő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é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é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észletesebbenKölcsönhatás diagramok
Kölcsönhatás diagramok Célkitűzés Olvasni tudják az alap UML kölcsönhatás diagramok (kommunikáció és szekvencia) diagramok jelöléseit. 2 Bevezetés Miért léteznek az objektumok? Azért, hogy a rendszer valamilyen
RészletesebbenHASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)
HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM) Célja: A követelményrögzítés (a szoftverfejlesztés els fázisaiban, pl. a követelménydefiníciós fázisban használatos). Funkcionális diagram: középpontban a rendszer
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é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é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é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észletesebbenHatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok
Ré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észletesebbenNagy 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é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észletesebbenRendszer-modellezés, modellezési technikák
Rendszer-modellezés, modellezési technikák System engineering and modelling Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 8. Roger S. Pressman: Software Engineering, 5th e. chapter 10,
Részletesebbenny Tornabajnokság g eredmény nyilvántart ntartó rendszere A megoldandó feladat Követelmény analízis 1. Ficsor Lajos Általános Informatikai Tanszék
OMT esettanulmány ny Tornabajnokság g eredmény nyilvántart ntartó rendszere Lajos Miskolci Egyetem Általános Informatikai Tanszék A megoldandó feladat A cél egy tornabajnokság eredmény nyilvántartó rendszerének
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é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é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é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észletesebbenAz informatika kulcsfogalmai
Az informatika kulcsfogalmai Kulcsfogalmak Melyek azok a fogalmak, amelyek nagyon sok más fogalommal kapcsolatba hozhatók? Melyek azok a fogalmak, amelyek más-más környezetben újra és újra megjelennek?
RészletesebbenSzoftver követelmények meghatározása
Szoftver meghatározása Requirements engineering (analysis) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 6-7. Roger S. Pressman: Software Engineering, 5th e. chapter 11. 2 Követelménymeghatározás
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é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é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észletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenÁttekintés. Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 08. 10. 16. Ficsor Lajos. Unified Modeling Language UML / 1
Unified Modeling Language (UML) Áttekintés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 08. 10. 16. Unified Modeling Language UML / 1 Szüks kségessége Az objektum orientált fejlesztési
RészletesebbenÁttekintés. rténete 1. Az UML törtt. Miskolci Egyetem Általános Informatikai Tanszák. Ficsor Lajos UML / 1
UML / 1 Unified Modeling Language (UML) Áttekintés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 08. 10. 16. Unified Modeling Language UML / 1 Szüks kségessége Az objektum orientált
RészletesebbenModell 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észletesebbenTartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet
Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés
RészletesebbenOMT esettanulmány. ny Tornabajnokság g eredmény nyilvántart. ntartó rendszere
OMT esettanulmány ny Tornabajnokság g eredmény nyilvántart ntartó rendszere Lajos Miskolci Egyetem Általános Informatikai Tanszék A megoldandó feladat A cél egy tornabajnokság eredmény nyilvántartó rendszerének
RészletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 1 of 67
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 5. ELŐADÁS - RENDSZERTERVEZÉS 1 1 of 67 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK
RészletesebbenOOP. Alapelvek Elek Tibor
OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós
RészletesebbenÜzleti architektúra menedzsment, a digitális integrált irányítási rendszer
Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer XXII. MINŐSÉGSZAKEMBEREK TALÁLKOZÓJA A digitalizálás a napjaink sürgető kihívása Dr. Ányos Éva működésfejlesztési tanácsadó Magyar
RészletesebbenTémakörök. Structured Analysis (SA) Előnyök (SA) (SA/SD) Jackson Structured Programming (JSP) Szoftvertechnológia
Témakörök Struktúrált fejlesztés Szoftvertechnológia előadás Structured Analysis/Stuctured Design (SA/SD) Jackson Structured Programming (JSP) Jackson System Development e e (JSD) Data Structured Systems
RészletesebbenSoftware 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észletesebbenKomponens alapú fejlesztés
Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
Ré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é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észletesebbenKövetelmény meghatározás. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1
Követelmény meghatározás Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1 A követelményjegyzék a rendszerfejlesztési alapmintában Döntési struktúra Vizsgálat/ helyzetfelmérés
Részletesebben2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA
2.Szoftverfejlesztés 2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA Szoftverfejlesztés: magában foglalja mindazon elveket, módszereket és eszközöket, amelyek célja a programok megbízható és hatékony elkészítésének
RészletesebbenAutóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
Részletesebben55 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é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észletesebbenSzoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.
Architektúrák dokumentálása UML-lel Irodalom L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addison-Wesley, 2003 H. Störrle: UML 2, Panem, 2007 2 Szoftver architektúra (emlékeztet!)
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észletesebbenAdat és folyamat modellek
Adat és folyamat modellek Előadásvázlat dr. Kovács László Folyamatmodell nyersanyag miből termék mit funkció ki munkaerő eszköz mivel Objektumok Tevékenységek Adatmodell Funkció modell Folyamat modell
RészletesebbenSzoftver-mérés. Szoftver metrikák. Szoftver mérés
Szoftver-mérés Szoftver metrikák Szoftver mérés Szoftver jellemz! megadása numerikus értékkel Technikák, termékek, folyamatok objektív összehasonlítása Mér! szoftverek, programok CASE eszközök Kevés szabványos
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
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é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 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é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észletesebbenPlanning and Design of Information Systems. André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987.
Planning and Design of Information Systems André Blokdijk, Paul Blokdijk ACADEMIC PRESS, 1987. 4.3 A tervezés határai Mi a tető, mi a lent, mi a centrum - tisztázni kell előre. A 4 modell milyen részlet
Részletesebben1. Bevezetés a szoftvertechnológiába
1. Bevezetés a szoftvertechnológiába Kérdések Mi a szoftvertechnológia (szoftvermérnökség)? Mik a szoftvertechnológiát érintő legfontosabb kérdések és válaszok? Etikai és szakmai kérdések: hogyan érintik
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (9) Szoftverminőségbiztosítás Specifikáció alapú (black-box) technikák A szoftver mint leképezés Szoftverhiba Hibát okozó bement Hibás kimenet Input Szoftver Output Funkcionális
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észletesebbenProgramozás alapjai Bevezetés
Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma
RészletesebbenAdatstruktúrák, algoritmusok, objektumok
Adatstruktúrák, algoritmusok, objektumok 3. Az objektumorientált paradigma alapelemei Objektum Osztály Példányosítás A konstruktor és a destruktor Osztályok közötti kapcsolatok Miklós Árpád, BMF NIK, 2006
RészletesebbenAz előadás célja. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1
Az előadás célja A munkafolyamat ezés módszereinek és technikáinak bemutatása A munkafolyamat ezést körülvevő fejlesztési környezetnek és a munkafolyamat ezés főbb lépéseinek ismertetése Információrendszer
RészletesebbenJava programozási nyelv
Java programozási nyelv 2. rész Vezérlő szerkezetek Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/23 Tartalomjegyzék
RészletesebbenRendszer-modellezés, modellezési technikák
Rendszer-modellezés, modellezési technikák System engineering and modelling Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 8. Roger S. Pressman: Software Engineering, 5th e. chapter 10,
RészletesebbenOsztálytervezés és implementációs ajánlások
Osztálytervezés és implementációs ajánlások Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2006. 04. 24. Osztálytervezés és implementációs kérdések OTERV / 1 Osztály tervezés Egy nyelv
RészletesebbenMé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észletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenProgramozás alapjai (ANSI C)
Programozás alapjai (ANSI C) 1. Előadás vázlat A számítógép és programozása Dr. Baksáné dr. Varga Erika adjunktus Miskolci Egyetem, Informatikai Intézet Általános Informatikai Intézeti Tanszék www.iit.uni-miskolc.hu
RészletesebbenSzoftver-technológia II. Modulok és OOP. Irodalom
Modulok és OOP Irodalom Steven R. Schach: Object Oriented & Classical Software Engineering, McGRAW-HILL, 6th edition, 2005, chapter 7. 2 Modulok és objektumok Modulok Lexikálisan folytonos utasítás sorozatok,
RészletesebbenIntegrációs mellékhatások és gyógymódok a felhőben. Géczy Viktor Üzletfejlesztési igazgató
Integrációs mellékhatások és gyógymódok a felhőben Géczy Viktor Üzletfejlesztési igazgató Middleware projektek sikertelenségeihez vezethet Integrációs (interfész) tesztek HIÁNYA Tesztadatok? Emulátorok?
RészletesebbenAdatbázis rendszerek. dr. Siki Zoltán
Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti
RészletesebbenIntegrált keretrendszer
Integrált keretrendszer Példa SAP R/3 Üzleti, szervezeti folyamatok modellezése Eseményvezérelt folyamat lánc (Event-driven Process Chain (EPC), Ereignisgesteuerte Prozessketten (EPK)) 1 BPMN Business
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észletesebbenUML Feladatok. UML Feladatok
UML Feladatok 2008.01.08 4. Feladat Az alábbi ábrán három UML2 modell elemet megjelöltünk. Adja meg elemenként, hogy az melyik UML2 meta-modell elem példánya! 2008.01.15 4. Feladat Jelölje meg, hogy a
RészletesebbenTémakörök. Struktúrált fejlesztés. Elınyök (SA) Structured Analysis (SA) Hátrányok (SA) Alapfogalmak (SA)
Témakörök Struktúrált fejlesztés Szoftvertechnológia elıadás Structured Analysis/Stuctured Design (SA/SD) Jackson Structured Programming (JSP) Jackson System Development (JSD) Data Structured Systems Development
RészletesebbenInformatika tanítási módszerek
Informatika tanítási módszerek Programozás tanítási módszerek módszeres, algoritmusorientált; adatorientált; specifikációorientált; feladattípus-orientált; nyelvorientált; utasításorientált; matematikaorientált;
RészletesebbenS S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method Mi az SSADM? Kifejezetten a rendszerelemzést és a szoftverfejlesztést támogatja. Eljárási, műszaki és dokumentációs
RészletesebbenTERMÉKTERVEZÉS PANDUR BÉLA TERMÉKTERVEZÉS
TERMÉKTERVEZÉS A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA Szoftverfejlesztés: magában foglalja mindazon elveket, módszereket és eszközöket, amelyek célja a programok megbízható és hatékony elkészítésének támogatása.
RészletesebbenMINISZTERELNÖ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