Szoftverfejlesztési modellek
|
|
- Fanni Borbély
- 9 évvel ezelőtt
- Látták:
Átírás
1 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 vagy modellnek nevezzük. A szoftverek elkészítésének lépései, problémái és részfeladatai nagyjából minden szoftver esetén hasonlóak, illetve meghatározhatók olyan kulcspontok, amelyek minden fejlesztésben megtalálhatók. Ennek alapján felállíthatók olyan fejlesztési modellek, amelyek általában alkalmazhatók minden szoftverfejlesztési folyamatra. Vízesés modell Néhány évtizeddel ezelőtt a világ lényegesen lassabban változott, mint manapság. Egy szoftverfejlesztési feladat megoldásánál volt idő arra, hogy alaposan feltárjuk, minden részletében megértsük a feladatot, a megrendelő elvárásait. Amikor az alapos és rendszerint hosszan tartó elemzések, követelményfeltárások után elkészült az ún. feladatspecifikáció, azt a megrendelő átvizsgálta, majd jóváhagyta. A fejlesztés újabb fázisa a megoldásterv elkészítése csak ez után következett. A megoldásterv jóváhagyását követte a kivitelezés, majd az elkészült termék tesztelése következett. A módszer az általa definiált fejlesztési folyamat munkaszakaszairól, pontosabban azok összekapcsolási módjáról kapta nevét. A vízesés modell a szoftverfejlesztés folyamatának első publikált modellje (1970). Mint az alábbi ábrán látható, az egyes fejlesztési munkafázisok lépcsőzetesen, vízesésszerűen kapcsolódnak egymáshoz. 1. ábra A vízesés modell Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 1
2 Az egyes fázisok tartalma Követelmények elemzése és meghatározása A rendszerrel kapcsolatos követelmények feltárásának szakasza. A rendszer szolgáltatásai, megszorításai és céljai a majdani felhasználókkal való konzultációk során derülnek ki. Ezeket részletesen leírják, és ebből alakul ki a rendszerspecifikáció. Rendszer- és szoftvertervezés A rendszer tervezési folyamatában válnak szét a hardver- és szoftverkövetelmények. Itt kell kialakítani a rendszer átfogó architektúráját. A szoftver terve a korábban pontosan definiált követelményrendszeren alapul. A tervezési folyamat eredménye a megoldásterv, amely modelleket és szöveges definíciókat tartalmaz a megvalósítás mikéntjére vonatkozóan. Implementáció és egységteszt A korábbi szoftverterveket ebben a szakaszban kódolják: előállnak azok a szoftvermodulok, amelyekből a teljes alkalmazás kialakítható. Az egységteszt azt ellenőrzi, hogy a szoftvermodulok megfelelnek-e a követelményspecifikációnak. Integráció és rendszerteszt Ebben a szakaszban történik meg a különálló szoftvermodulok összekapcsolása és a kapcsolt modulok együttműködésének tesztelése. A teszteléssel kapcsolatban külön tesztelési tervek és dokumentációk készülnek. Működtetés és karbantartás A rendszer telepítése után megtörténik a használatba vétel. A karbantartás a még mindig előforduló hibák kijavítására, illetve később bizonyos korlátozott mértékű rendszer-továbbfejlesztésre terjed ki. Az egyes lépcsőkok eredményei alapvetően nem mások, mint egy vagy több olyan dokumentum, melyek jóváhagyása a következő megkezdése előtt megtörténik: a következő fázis addig nem indulhat el, amíg az előző (hivatalosan) be nem fejeződött. A soron következő fázisok szigorúan az előzőek eredményeire támaszkodnak. Mint látható, a vízesés módszer a teljes szoftverfejlesztési ciklust lefedi. Előírja az elvégzendő munkafolyamatokat, sőt az egyes fázisokban elkészítendő résztermékeket és dokumentációkat is. A folyamatban jól azonosíthatók az általános problémamegoldás lépései. A módszer akkor alkalmazható hatékonyan és eredményesen, ha a követelmények jól definiáltak és stabilak vagyis a majdani szoftver környezete kiérlelt, beállt elvek alapján működik, és a működési feltételek nem, vagy nagyon lassan és jól tervezhetően változnak (így már a fejlesztés korai szakaszában meghozhatunk és fenntarthatunk átfogó és alapvető döntéseket). Ellenkező esetben azonban előfordulhat, hogy mire a fejlesztési folyamat végére érünk, a környezet már másképp működik, így mások lesznek az elvárások is: legrosszabb esetben ez használhatatlan szoftvert eredményez. A vízesés modell kifejezetten érzéketlen a fejlesztés ideje alatt bekövetkező követelményváltozásokra. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 2
3 Az elmúlt húsz-harminc évben felgyorsult világban egyre kevésbé (vagy egyre kevesebb területen) alkalmazható ez a módszer. A gazdasági, jogi, politikai változások ma már gyorsabban követik egymást, mint régebben. A vízesés modell egyes fázisaiban természetesen ellenőrizhetjük a helyzet- és követelményváltozásokat, és ezek miatt vissza is térhetünk egy korábbi fázisra, hogy módosítsuk terveinket vagy az implementációt de ez egyrészt mérhetetlenül költséges és időrabló, másrészt a modell jellegéből adódóan így előfordulhat, hogy sosem érünk a fejlesztés végére! A spirál modell A spirál modell a vízesés modell elemeit ún. prototípus-használattal egészíti ki. Nagy, drága és bonyolult rendszerek fejlesztésére szánt módszer. A modell alkalmazása során 1. Amennyire lehetséges, feltárjuk a rendszerrel szembeni követelményeket. 2. Ennek alapján elkészítünk egy első rendszertervet. 3. A rendszertervben foglaltak szerint létrehozunk egy kezdeti, működő megoldást (prototípust). Kiértékeljük ezt a prototípust annak a. erősségei-gyengeségei és kockázatai szerint, b. további, időközben megjelenő, kiderülő követelményeket definiálunk, c. megtervezzük a következő prototípust, d. elkészítjük és elemezzük az új, továbbfejlesztett megoldást. 4. A felhasználó a fejlesztési folyamatot bármikor megszakíthatja, ha túl drágának, kockázatosnak tartja a folytatást. 5. Egyébként a prototípusok fejlesztése addig tart, amíg a felhasználó úgy nem dönt, hogy a rendszer már teljesen megfelel az igényeinek. 6. Mire a végső változat kialakul, minden funkció minden szinten alaposan tesztelve lett. A módszer előnye, hogy a fejlesztés költségei, idő- és egyéb erőforrásigénye folyamatosan pontosíthatók. A módszer érzékeny a követelményváltozásokra, azok hamar érvényesíthetők a megoldásokban. Hátrányai hasonlóak, mint a következő, evolúciós modellé. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 3
4 Evolúciós modell Az evolúciós modell a változó világ problémájára kívánt elfogadható választ adni. Alapötlete az, hogy a kezdeti követelmények alapján lehetőleg olcsón és gyorsan fejlesszünk ki egy termékverziót. Ennek a terméknek a használata során összegyűlt tapasztalatokat építsük be egy újabb termékverzióba. Ezt a folyamatot mindaddig ismételjük, amíg el nem érjük a kívánalmaknak már megfelelő rendszert. 2. ábra Az evolúciós modell Az evolúciós módszer sokkal jobban biztosítja a gyors visszacsatolások lehetőségét, így használata praktikus, amikor közvetlen felhasználói instrukciók alapján kell fejleszteni, vagy változékony a környezet, és a változásokra folyamatosan reagálni kell. A folyamat során a rendszer specifikációja és az implementáció párhuzamosan fejlődik (iterációs fejlesztés) és egyre részletesebb, finomabb szintet ér el miközben követi a követelményváltozásokat is. Ugyanakkor hátrány, hogy maga a komplex fejlesztési folyamat nehezen átlátható és még nehezebben követhető, így a vezetői (projekt) ellenőrzés nehezen gyakorolható. Az állandó változtatások, átalakítások a rendszer strukturáltságát és dokumentálhatóságát is rontják, egyre nehezebb és költségesebb az egyes modulok integrálása. Az evolúciós modell jól használható kisebb, belső használatra szánt, átmeneti vagy speciális igényeket kielégítő programok esetén. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 4
5 Inkrementális fejlesztés Az eddigiekben megismertük a vízesés, a spirál és az evolúciós módszert, láttuk előnyeiket és hátrányaikat. Ezen előnyök és hátrányok érvényesülése erősen függ a fejlesztési, illetve a majdani használat területének jellegétől, stabilitásától. Jó lenne olyan módszer, amely ezt (legalább nagyrészt) kiküszöböli, egyesíti az eddigi modellek előnyeit, miközben minimalizálja hátrányaikat. A vízesés modell azt követeli meg a megrendelőtől, hogy pontosan megfogalmazza és véglegesítse követelményeinek halmazát, mielőtt a tervezési munka megindulna, a tervezőtől pedig azt, hogy az implementáció előtt válasszon végleges tervezési stratégiát. Habár a vízesés modell előnye, hogy könnyen menedzselhető és szétválasztja a tervezési és implementációs szakaszokat, a folyamat olyan rendszerhez vezethet, amely végül nem felel meg az átadáskori követelményeknek. Az evolúciós modell megengedi, hogy a követelményekkel és tervezéssel kapcsolatos döntéseket későbbre halasszuk, de gyengén strukturált, nehezen karbantartható rendszerekhez vezethet. Az inkrementális módszer köztes megoldás a korábbi két modell között, kombinálja azok előnyös tulajdonságait. Az inkrementális fejlesztés során a rendszerspecifikáció, a tervezés és az implementálás kis inkrementációs lépésekre (inkremensekre, fokozatokra) vannak felosztva, melyeket több fordulóban végzünk el. A folyamat során a megrendelő először nagy vonalakban meghatározza, hogy milyen szolgáltatásokat vár a rendszertől. Azt is meghatározza, hogy ezek közül melyek a fontosak és a kevésbé fontosak (prioritási sorrend). Jegyezzük meg, hogy ez a felhasználó szakmai igényein alapuló sorrend! Sok további inkrementációs lépést majd később határozunk meg annak alapján, hogy minden ilyen fokozat funkciók egy-egy újabb halmazát adja a már meglévőkhöz. A szolgáltatások egyes fejlesztési inkremensekben való elhelyezése függ a prioritásuktól is a magas prioritással rendelkezőket hamarabb kell a megrendelő számára biztosítani. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 5
6 3. ábra Az inkrementális fejlesztés modellje Amennyiben meghatároztuk az inkremenseket (de legalább az elsőt), az első inkremens által előállítandó szolgáltatások követelményeit pontosan definiálni kell, majd ez után erre az inkremensre végrehajtjuk a teljes fejlesztési folyamatot. Azt, hogy milyen módszert (fejlesztési modellt) alkalmazunk, az inkremens részletezettségi foka, illetve az egyes szolgáltatásokkal kapcsolatos feltételek határozzák meg. Elképzelhető, hogy egyes inkremensek vagy szolgáltatások vízesés módszerrel fejleszthetők, másoknál pedig iteratív megoldást kell választani. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 6
7 Az inkrementális fejlesztés során: A megrendelőnek nem kell megvárnia, amíg a teljes rendszer elkészül: az első inkremens kielégítheti a legfontosabb szolgáltatásokat, így a szoftver már elég korán használatba kerülhet. Az egyes inkremensek korai használatba vételével a megrendelő tapasztalatokat szerezhet a rendszer használatával kapcsolatban, és ezek jól felhasználhatók a későbbi inkremensek tervezésénél, megvalósításánál. Mivel a magas prioritású (a rendszer célja szempontjából legfontosabb) szolgáltatásokat szállítjuk le leghamarabb, nyilván ezeket használják, tesztelik a legtöbbször. Így kisebb az esélye annak, hogy a rendszer teljes elkészülte után a fontos funkciókban hibák maradjanak. Az előnyök mellett az inkrementális fejlesztésnek is megvannak a maga hátrányai: az inkremenseknek viszonylag kisméretűeknek kell lenniük, ekkor viszont problémát okozhat a funkciók megfelelő felosztása. Sok rendszer ugyanis igényel általános (felhasználói vagy technikai) szolgáltatásokat, melyeket több más frontszolgáltatás közösen használ. Mint láthattuk a különböző módszerek tárgyalásánál, a szoftverfejlesztés során a klasszikus feladatmegoldás lépéseire alapozott munkafolyamatokat végzünk el. A fejlesztési folyamatot szakaszokra bontjuk, és az egyes szakaszok a korábbiak eredményeire támaszkodnak. A vízesés módszer a fejlesztési folyamatot egymás után végrehajtandó munkafázisok sorozatának tekinti, melynek végén előáll a korábbi specifikációs szakaszokban meghatározott követelményeknek megfelelő rendszer. Ez a megoldás azonban rugalmatlan a változásokkal szemben, így sok esetben olyan megoldást kell választani, amelyben képesek vagyunk a fejlesztés ideje alatt bekövetkezett változásokat figyelembe venni és érvényesíteni. Az evolúciós fejlesztés abból indul ki, hogy a rendszert az általánostól a speciális részletekig mintegy piramisszerűen fejlesztjük, mindig vissza-visszatérve az egyes szintekhez, egyre pontosabbá, teljesebbé téve azokat. Ezek a visszatérések iterációk a folyamatos követelményelemzéseken keresztül a rendszer specifikációját és implementációját párhuzamosan fejlesztve alakítják ki a végső megoldást. Az inkrementális fejlesztés a vízesés módszer stabilitását és az evolúciós módszer rugalmasságát próbálja ötvözni azzal, hogy a fejlesztési folyamat evolúciós jellegébe mérhető rendszert, szakaszolást visz ezek az inkremensek. Az egyes inkremenseken belül komplett mini projektet, teljes fejlesztési folyamatot hajtunk végre, a helyzetnek megfelelő fejlesztési módszer alkalmazásával. Mindegyik tárgyalt módszernek megvannak a maga előnyei és hátrányai, melyeket figyelembe kell vennünk, amikor fejlesztési modellt választunk. Készítette: Centroszet Szakképzés-Szervezési Nonprofit Kft. 7
Szoftvertermékek csoportjai. A szoftver. Bemutatkozás és követelmények 2011.09.04.
Bemutatkozás és követelmények Dr. Mileff Péter Dr. Mileff Péter - Általános Informatikai Tanszék Fizika Tanszék A/1-303. szoba. Konzultációs idő:???. Követelmények: Vezetett gyakorlat nincs. Jelenléti
A folyamat közös fázisai. A szoftverfolyamat modelljei. A vízesésmodell fázis: követelmények elemzése és meghozása
A szoftver Dr. Mileff Péter A szoftver szót sokan egyenlınek tekintik a számítógépes programokkal. Nincs egyértelmő definíciója. Több ennél: hozzájuk kapcsolódó dokumentációk, konfigurációs adatok. Ezek
Félévi követelmények Bemutatkozás és követelmények
Félévi követelmények Dr. Mileff Péter Féléves feladat: egy objektum orientált alkalmazás szoftverspecifikációját és tervét kell elkészíteni. Csoportos munka: 5-7 fős csoportok alakítása. Minden csoporthoz
Félévi követelmények. Gyakorlatvezetők
Dr. Mileff Péter Bemutatkozás és követelmények Dr. Mileff Péter Helyileg: A/1-303. szoba. Fizika Tanszék Konzultációs idő: Szerda 10 12 mileff@iit.uni-miskolc.hu Követelmények: Vezetett gyakorlat nincs.
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
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
Szoftvermenedzsment 4. fejezet A szoftverfolyamat
4. fejezet A szoftverfolyamat Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai és Gazdasági Intézet 2007. július 1 A szoftverfolyamat Ahogyan az első fejezetben megbeszéltük: A szoftverfolyamat
V. 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
Ami a vízesésen túl van
Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két
Bevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, Személyek és szerepkörök Kitekintő: Modell, módszertan 2 Dr. Barabás
Programfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
Információs rendszerek Információsrendszer-fejlesztés
Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés
Verifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
Miskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
A tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
Bevezetés Mi a szoftver? Általános termékek: Mi a szoftvertervezés?
Bevezetés Mi a szoftver? Számítógép-programok és kapcsolódó dokumentációk, illetve konfigurációs adatok, amelyek elengedhetetlenek ahhoz, hogy ezek a programok helyesen működjenek. Szoftvertermékek fejleszthető
Programtervezés. Dr. Iványi Péter
Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű
MIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
Üzletmenet folytonosság menedzsment [BCM]
Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment Megfelelőség, kényszer? Felügyeleti előírások Belső előírások Külföldi tulajdonos előírásai Szabványok, sztenderdek, stb Tudatos
Gara Péter, senior technikai tanácsadó. Identity Management rendszerek
Gara Péter, senior technikai tanácsadó Identity Management rendszerek I. Bevezetés Tipikus vállalati/intézményi környezetek Jogosultság-kezeléssel kapcsolatos igények Tipikus jogosultság-igénylési folyamatok
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI
1 A SIKERES PROJEKT KOCKÁZATMENEDZ SMENT FŐ ELEMEI ÉS KULCSTÉNYEZŐI 1.1 MIT JELENT ÉS MIÉRT FONTOS A KOCKÁZATMENEDZSMEN T? A Project Management Institute (PMI) definíciója szerint a projekt egy ideiglenes
S 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
Információtartalom vázlata
1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos
Intelligens partner rendszer virtuális kórházi osztály megvalósításához
Intelligens partner rendszer virtuális kórházi osztály megvalósításához 1. Célkitűzések A pályázat célja egy virtuális immunológiai osztály kialakítása, amelynek segítségével a különböző betegségekkel
Né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,
Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar
Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver
SLA RÉSZLETESEN. 14. óra
14. óra SLA RÉSZLETESEN Tárgy: Szolgáltatás menedzsment Kód: NIRSM1MMEM Kredit: 5 Szak: Mérnök Informatikus MSc (esti) Óraszám: Előadás: 2/hét Laborgyakorlat: 2/hét Számonkérés: Vizsga, (félévi 1db ZH)
Szoftverminő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,
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család
Programozá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
IRÁNYÍTÓ RENDSZER IRÁNYÍTANDÓ FOLYAMAT. Biztonsági funkciók Biztonsági integritás. Normál működés. Hibák elleni védettség Saját (belső) biztonság
Biztonsági funkciók Biztonsági integritás Teljes funkcionalitás Biztonsági funkciók Irányító funkciók Gyakoriság Normál működés Kockázat osztályozás Veszélyelemzés Kockázatcsökkentés Súlyosság Belső kockázat
Szoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor
Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor A szotverarchitektúra fogalma A szoftverarchitektúra nagyon fiatal diszciplína. A fogalma még nem teljesen kiforrott. Néhány definíció: A szoftverarchitektúra
cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től
Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét
Informatikai projekteredmények elfogadottságának tényezői
Informatikai projekteredmények elfogadottságának tényezői Rabi Ákos 2014.02.18. Tartalom 1. Problémafelvetés Informatikai projekteredmények elfogadottsága 2. Informatikai projektek sikertényezői 3. Szoftverek
Működési szabvány MPTSZ Minősített Pénzügyi Tervezők Magyarországi Szövetsége
MPTSZ NONPROFIT KFT. HAQFP Hungarian Association of Qualified Financial Planners Nonprofit Ltd. Sas utca 9. II/5., Budapest H-1051, Hungary P: (+36)30944426 e-mail: info@mptsz.org www.mptsz.org Működési
Cégismerteto. Ez így kicsit tömören hangzik, nézzük meg részletesebben, mivel is foglalkozunk!
Cégismerteto Modern világunkban nem létezhetünk információ nélkül: az informatika végérvényesen alapinfrastruktúrává vált, mindig, mindenhol jelen van, mindannyiunk életét meghatározza. A mai üzleti világban
Projektmenedzsment sikertényezők Információ biztonsági projektek
Projektmenedzsment sikertényezők Információ biztonsági projektek A Project Management Institute (PMI, www.pmi.org) részletesen kidolgozott és folyamatosan fejlesztett metodológiával rendelkezik projektmenedzsment
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
Szemléletmód váltás a banki BI projekteken
Szemléletmód váltás a banki BI projekteken Data Governance módszertan Komáromi Gábor 2017.07.14. Fókuszpontok áthelyezése - Elérendő célok, elvárt eredmény 2 - Egységes adatforrásra épülő, szervezeti egységektől
Szoftverfejlesztési folyamatok és szoftver minőségbiztosítás
Szoftverfejlesztési folyamatok és szoftver minőségbiztosítás Dr. Ulbert, Zsolt Szerzői jog 2014 Pannon Egyetem A tananyag a TÁMOP-4.1.2.A/1-11/1-2011-0042 azonosító számú Mechatronikai mérnök MSc tananyagfejlesztés
Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi
Projektterv Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi Verziók: Verzió Dátum Szerző Státusz Megjegyzés 0.1 2008.10.14 Balikó Ivett Tervezet Kiindulási változat, véleményezésre 0.2 2008-10-20
SDM. Adatbáziskezelés és könyvtári rendszerszervezés. Konkrét problémamegoldásra orientált elvek, szabályok együttese
SDM Adatbáziskezelés és könyvtári rendszerszervezés Módszertanok Módszer fogalma: Konkrét problémamegoldásra orientált elvek, szabályok együttese Módszertan fogalma: Az információs rendszer létrehozásához
Agilis projektmenedzsment
Agilis projektmenedzsment 2013. április 10. 1 Adaptive Consulting Kft. Csutorás Zoltán Agile coach, tréner zoltan.csutoras@adaptiveconsulting.hu 2 www.scrummate.hu 3 Agilis ernyő Scrum Lean/Kanban Crystal
Nemzetközi számvitel. 12. Előadás. IAS 8 Számviteli politika, a számviteli becslések változásai és hibák. Dr. Pál Tibor
Dr. Pál Tibor Nemzetközi számvitel 12. Előadás IAS 8 Számviteli politika, a számviteli becslések változásai és hibák 2014.05.13. IAS 8 Bevételek 2 Az IAS 8 célja A fejezet célja, hogy bemutassa Hogyan
4. A szoftvergyártás folyamata
4. A szoftvergyártás folyamata Kérdések Mi a szoftvergyártás modellje? Mi a három alapvető modell és mikor használjuk ezeket? Mik a követelménytervezés, a szoftverfejlesztés, a tesztelés és az szoftver-evolúció
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment
A fejlesztési szabványok szerepe a szoftverellenőrzésben
A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés
Programrendszerek tanúsítása szoftverminőség mérése
SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát
5. Témakör TARTALOMJEGYZÉK
5. Témakör A méretpontosság technológiai biztosítása az építőiparban. Geodéziai terv. Minőségirányítási terv A témakör tanulmányozásához a Paksi Atomerőmű tervezési feladataiból adunk példákat. TARTALOMJEGYZÉK
Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu
Tisztelettel köszöntöm a RITEK Zrt. Regionális Információtechnológiai Központ bemutatóján. www.ritek.hu BEVEZETŐ az ASP-szolgáltatásról Az ASP-szolgáltatás (Application Service Providing) előnyei A megrendelő
Branch-and-Bound. 1. Az egészértéketű programozás. a korlátozás és szétválasztás módszere Bevezető Definíció. 11.
11. gyakorlat Branch-and-Bound a korlátozás és szétválasztás módszere 1. Az egészértéketű programozás 1.1. Bevezető Bizonyos feladatok modellezése kapcsán előfordulhat olyan eset, hogy a megoldás során
MINŐSÉGÜGYI ELJÁRÁSOK
Eötvös Loránd Tudományegyetem MINŐSÉGÜGYI ELJÁRÁSOK ME 1.7.4. Gólyafelmérés és eredményeinek felhasználása Készítette: Rektori Kabinet Minőségügyi Iroda Verzió/kiadás dátuma: 1/2017.11.10. Jóváhagyta:
Verziókövető rendszerek használata a szoftverfejlesztésben
Verziókövető rendszerek használata a szoftverfejlesztésben Dezső Balázs Szakszeminárium vezető: Molnár Bálint Budapesti Corvinus Egyetem Budapest, 2009. június 24. 1 Bevezetés 2 Verziókövetőrendszerek
MINTA Projektterv 2007
PROJEKTTERV 1 (7) MINTA Projektterv 2007 1 Összefoglaló Ez a MINTA projekt projektterve. (Tömör leírás, kihangsúlyozva a fő eredményeket.) 2 Verziók Verzió Szerző Dátum Státusz Megjegyzés 0.1
IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél
IT ügyfélszolgálat és incidenskezelés fejlesztése az MNB-nél Molnár László MNB, ITIL Projektvezető Fábián János ICON Professional Services Vezérfonal Az MNB IT működése, a SIP kiváltó okai A projekt módszereinek
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (7) Szoftverminőségbiztosítás Szoftvertesztelési folyamat Szoftverek és környezet Nem egyforma a szoftverek használatához kapcsolódó kockázat Különböző kockázati szintek -> eltérő
Információ menedzsment
Információ menedzsment Szendrői Etelka Rendszer- és Szoftvertechnológiai Tanszék szendroi@witch.pmmf.hu Infrastruktúra-menedzsment Informatikai szolgáltatások menedzsmentje Konfigurációkezelés Gyorssegélyszolgálat
AZ ELLENŐRZÉSI NYOMVONAL
AZ ELLENŐRZÉSI NYOMVONAL 1. Az ellenőrzési nyomvonal fogalma Az Ámr. rendelkezése szerint az ellenőrzési nyomvonal A Polgármesteri Hivatal tervezési, pénzügyi lebonyolítási folyamatainak, valamint ellenőrzési
Szoftverfejlesztés. Created by XMLmind XSL-FO Converter.
Szoftverfejlesztés Ficsor Lajos (1,3,4,7,8,9,10,11,12,13 fejezet) Krizsán Zoltán (14,16 fejezet) Dr. Mileff Péter (2,5,6,15 fejezet) 2011, Miskolci Egyetem, Általános Informatikai Tanszék Szoftverfejlesztés
Jászivány Község Önkormányzata évi belső ellenőrzési terve
Jászivány Község Önkormányzata 2016. évi belső ellenőrzési terve Az államháztartásról szóló 2011. évi CXCV. törvény (a továbbiakban: Áht.) 61. -a szerint az államháztartási kontrollok célja az államháztartás
Gödöllő Város Önkormányzata
Gödöllő Város Önkormányzata 2100 Gödöllő, Szabadság tér 7. (11) fejlesztési elem: A KÖZSZOLGÁLTATÁSOK NYÚJTÁSÁNAK ÉS A SZERVEZET MŰKÖDÉSÉNEK FOLYAMATOS, CIKLIKUS MINŐSÉGFEJLESZTÉSE ÉRDEKÉBEN NEMZETKÖZILEG
1/50. Teljes indukció 1. Back Close
1/50 Teljes indukció 1 A teljes indukció talán a legfontosabb bizonyítási módszer a számítástudományban. Teljes indukció elve. Legyen P (n) egy állítás. Tegyük fel, hogy (1) P (0) igaz, (2) minden n N
Informatikai 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
5/1. tétel: Optimalis feszítőfák, Prim és Kruskal algorithmusa. Legrövidebb utak graphokban, negatív súlyú élek, Dijkstra és Bellman Ford algorithmus.
5/1. tétel: Optimalis feszítőfák, Prim és Kruskal algorithmusa. Legrövidebb utak graphokban, negatív súlyú élek, Dijkstra és Bellman Ford algorithmus. Optimalis feszítőfák Egy összefüggő, irányítatlan
minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.
minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás
Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata
Kutatási beszámoló a Pro Progressio Alapítvány számára Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Mérnök informatika szak Orvosi készülékekben használható modern
Cégprofil publikus CÉGPROFIL 1
CÉGPROFIL 1 BEMUTATKOZÁS A Molaris Kft-t magyar magánszemélyek alapították 2006-ban, jelenleg is 100%-ban magyar tulajdonban van. Cégünk legfontosabb célkitűzése, hogy kiemelkedő színvonalú szolgáltatásai
8/2011. sz. Szabályzat FOLYAMATBA ÉPÍTETT ELŐZETES ÉS UTÓLAGOS VEZETŐI ELLENŐRZÉS RENDSZERE
8/2011. sz. Szabályzat FOLYAMATBA ÉPÍTETT ELŐZETES ÉS UTÓLAGOS VEZETŐI ELLENŐRZÉS RENDSZERE A Csákvár Nagyközség Polgármesteri Hivatala Folyamatba épített, előzetes és utólagos vezetői ellenőrzés rendszerét
ISO 9001 revízió Dokumentált információ
ISO 9001 revízió Dokumentált információ Dokumentumkezelés manapság dokumentált eljárás Minőségi kézikönyv DokumentUM feljegyzés Dokumentált eljárás feljegyzések kezeléséhez Dokumentált eljárás dokumentumok
S01-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
Kedves Servantes Felhasználó! Mint számítástechnikai szakcég, a következőkről tájékoztatjuk:
Tárgy: Fontos tájékoztatás az Ön számlázó programjáról Kedves Servantes Felhasználó! Bizonyára hallott már arról, hogy 2016. január 1-jétől olyan számlázó szoftvert lehet csak használni, amely tartalmazza
Szakmai ajánlat független külső minőségbiztosítási tevékenység ellátására a. Struktúraváltás a Bajai Szent Rókus Kórházban című
Szakmai ajánlat független külső tevékenység ellátására a Struktúraváltás a Bajai Szent Rókus Kórházban című projekthez kapcsolódóan Azonosítószám: TIOP-2.2.4-09/1-2010-0003 2011. január 11. PSZM-PEN Kft.
Gondolatok a PM módszertan korlátairól, lehetőségeiről amit a felsővezetőknek tudniuk kell! dr. Prónay Gábor
Gondolatok a PM módszertan korlátairól, lehetőségeiről amit a felsővezetőknek tudniuk kell! dr. Prónay Gábor 5. Távközlési és Informatikai Projekt Menedzsment Fórum 2002. április 18. AZ ELŐADÁS CÉLJA néhány
Szoftverfejlesztés. (MSc) Miskolci Egyetem Általános Informatikai Tanszék MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR
MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR Szoftverfejlesztés (MSc) KÉSZÍTETTE: DR. MILEFF PÉTER Miskolci Egyetem Általános Informatikai Tanszék 2010 Tartalomjegyzék 1. A szoftver... 4 2. A szoftverfolyamat
Bevezetés a programozásba előadás: Alapvető programtervezési elvek
Bevezetés a programozásba 2 12. előadás: Alapvető programtervezési elvek Miről lesz szó A félév célja a nagyobb programrendszerek felépítésében való részvétel képességét megszerezni Mindenki a saját widgetkészletének
Kolozsi Erik. Beszámoló
Beszámoló Kolozsi Erik Először is köszönetemet szeretném kifejezni, mivel az ösztöndíj nagyon nagy segítséget nyújtott a művészeti alkotótevékenységem fejlődésemben. Gyakorlatilag az ösztöndíj sok kreatív
Lá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
Minőségmenedzsment és Informatika Test-Driven Development
Minőségmenedzsment és Informatika Test-Driven Development Varga Balázs G5S8 2008.10.27 Szoftverfejlesztés jellemzői Megrendelői igények Tervezés Implementálás Tesztelés Dokumentálás
Darts - Krikett Projekt feladat specifikáció
Darts - Krikett Projekt feladat specifikáció 1 Tartalomjegyzék 1 Tartalomjegyzék... 2 2 Bevezetés... 3 2.1 A feladat címe... 3 2.2 A feladat rövid ismertetése... 3 3 Elvárások a feladattal kapcsolatban...
MŰ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
Minőség-ellenőrzés 2016
Minőség-ellenőrzés 2016 Visegrád 2016. szeptember 8. Mádi-Szabó Zoltán MKVK Minőségellenőrzési Bizottság elnöke 1 A minőség-ellenőrzés célja A minőség-ellenőrzési rendszer célja a könyvvizsgálók által
ELŐADÁS ÁTTEKINTÉSE. Tevékenységek tervezése Gantt diagramm
ELŐADÁS ÁTTEKINTÉSE Tevékenységek tervezése Gantt diagramm TEVÉKENYSÉGEK TERVEZÉSE Fel kell vázolni egy lehetséges tevékenység sorozatot, egyfajta megoldást, illetve elvárt eredményt, amit a célrendszerrel
A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata
A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata A Budapesti Értéktőzsde Részvénytársaság Igazgatósága A Budapesti Értéktőzsde Részvénytársaság Szabályzata a Távkereskedés
2. Szoftver minőségbiztosítás
2. Szoftver minőségbiztosítás A szoftver egy termelési folyamat végterméke, azaz végső soron a szoftver is egy termék. Az alábbiakban a minőség fogalmát tekintjük át általánosságban, mely így nemcsak a
KÉSZÍTETTE: DR. MILEFF PÉTER
MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR Szoftverfejlesztés (MSc) KÉSZÍTETTE: DR. MILEFF PÉTER Miskolci Egyetem Általános Informatikai Tanszék 2011 Tartalomjegyzék 1. A szoftver...4 2. A szoftverfolyamat
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben. SDLC System Development Life Cycle Software Development Life Cycle
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben SDLC System Development Life Cycle Software Development Life Cycle Mi az életciklus? A termék piacon való megjelenésétől a kivonásáig terjedő
Blokkolási paraméter ablak leírása. 1/5 CLIP-ERP HUNGARY INFORMÁCIÓS LEVELE 2017/63. SZÁM OKTÓBER. A szerkesztő gondolatai
A szerkesztő gondolatai Ahogy múlik az idő, egyre többen szeretnének még részletesebb információt kinyerni a rendszerből. Ennek támogatására tesszük most közé ezt a dokumentáció szintű leírást a blokkolásokról.
Közbeszerzési tapasztalatok a Kohéziós Alap projektek kapcsán. Dr. Velikovszky László
Közbeszerzési tapasztalatok a Kohéziós Alap projektek kapcsán Dr. Velikovszky László Európai Uniós Közbeszerzési Koordinációs és Szabályossági Egység 1 Értékelések - minőségbiztosítás amire a tapasztalatainkat
A folyamatszemlélet, a dokumentált információ és a kockázatértékelés integrálásának gyakorlati bemutatása (A szabályozás evolúciója)
A folyamatszemlélet, a dokumentált információ és a kockázatértékelés integrálásának gyakorlati bemutatása (A szabályozás evolúciója) KERTÉSZ Zoltán, GÖNDÖR Vera Óbudai Egyetem Szervezet rövid bemutatása
Szoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
1 Informatikai beszerzések.
1 Informatikai beszerzések. Az informatikai szabályzat beruházási fejezete az informatikai eszközök beszerzésével kapcsolatos belső tevékenységet, illetve a szállítóktól elvárt, a beszállítás részeként
A projekt partnerkapcsolatainak eseménynaplója. Dátum: 2008.08.26. Helyszín: Rudas és Karig Kft. székhely, Budapest II. Szilágyi Erzsébet fasor 5.
A projekt partnerkapcsolatainak eseménynaplója Dátum: 2008.08.26. Esemény: Kapcsolatfelvétel és vállalkozói szerződések előkészítése Leírás: Karig Gábor a GOP projektben való alvállalkozói részvétel feladatairól
Software engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz:
Software engineering (Software techológia) Bevezetés, alapfogalmak Utolsó módosítás: 2006. 02. 16. SWENGBEV / 1 Történelem 1. 60-as évek Megoldandó problémák: egyedi problémákra kis programok Fejlesztő:
55 481 04 0000 00 00 Web-programozó Web-programozó
A /2007 (II. 27.) SzMM rendelettel módosított 1/2006 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről alapján. Szakképesítés,
Projektterv. Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi
Projektterv Projekt Neve: Ingatlan Bérbeadási Nyilvántartás Csoport: nmi Verziók: Verzió Dátum Szerző Státusz Megjegyzés 0.1 2008.10.14 Balikó Ivett Tervezet Kiindulási változat 0.2 2008-10-20 Fertői Ferenc
Követelmény alapú minőségbiztosítás az államigazgatásban
Követelmény alapú minőségbiztosítás az államigazgatásban László István 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Témák Követelmény