Szoftvermenedzsment 4. fejezet A szoftverfolyamat

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "Szoftvermenedzsment 4. fejezet A szoftverfolyamat"

Átírás

1 4. fejezet A szoftverfolyamat Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai és Gazdasági Intézet július 1

2 A szoftverfolyamat Ahogyan az első fejezetben megbeszéltük: A szoftverfolyamat tevékenységek és kapcsolódó eredmények olyan sora, amelyek egy szoftvertermék előállításához vezetnek Ezek történhetnek a szoftverfejlesztés kezdeteitől, de gyakran egy meglévő szoftver módosítására irányulnak Nehezen gépesíthető, mert nagyon sok emberi tényezőtől függ, kreativitást igényel Egyes fázisai támogathatók CASE eszközökkel CASE: Computer Aided Software Engineering 2

3 A szoftverfolyamat fázisai Sokféle megközelítés létezik, de vannak közös pontok: Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció 3

4 A szoftverfolyamat modelljei Nincs olyan modell, ami minden folyamatra alkalmazható lenne. Vannak különböző megközelítésmódok, amelyeket ismerve, vegyesen alkalmazhatjuk ezeket: Vízesés modell Evolúciós fejlesztés Formális rendszerfejlesztés Újrafelhasználás alapú fejlesztés 4

5 A vízesés modell Ez a szoftverfolyamat első publikált modellje (1970) Nevezik szoftveréletciklusnak is Az ábrán látszik, hogy honnan kapta a nevét Mit jelentenek a nyilak? 5

6 Követelmények elemzése és meghatározása A rendszer által nyújtandó szolgáltatások, és a megszorítások a megrendelővel, illetve a leendő felhasználókkal történő konzultáció(k) alapján alakulnak ki Ezeket részletesen kifejtjük, írásba foglaljuk Aláíratjuk a felhasználóval Ez alkotja a rendszerspecifikációt 6

7 Rendszer- és szoftvertervezés A rendszertervezés fázisában választjuk szét a hardver és szoftver követelményeket Kialakítjuk a rendszer átfogó architektúráját A szoftvertervezés fázisában meghatározzuk az alapvető szoftverabsztrakciókat, azaz eldöntjük, hogy a rendszer egyes elemeit milyen szoftvereszközökkel fogjuk megvalósítani Meghatározzuk az elemek közötti kapcsolatokat Mindezt írásban rögzítjük 7

8 Implementáció és egységteszt Ebben a fázisban megvalósítjuk a szoftvertervben meghatározott szoftvermodulokat Az egységteszt ellenőrzi, hogy az egyes modulok megfelelnek-e a specifikációnak 8

9 Integráció és rendszerteszt Integráljuk az elkészült programmodulokat Teszteljük a teljes rendszert Célszerű fokozatosan végezni az integrációt és a tesztelést először két modult integrálunk és tesztelünk majd hozzákapcsoljuk a harmadikat, és teszteljük és így tovább, amíg minden modult be nem építettünk a rendszerbe Sikeres rendszerteszt után a rendszer átadható a megrendelőnek 9

10 Működtetés és karbantartás Általában ez a szoftver életciklus leghosszabb szakasza, de nem mindig. Mondjunk egy példát, amikor nem így van! Megtörtént a rendszer telepítése és használatbavétele A karbantartás elemei: olyan hibák kijavítása, amelyek nem derültek ki a korábbi fázisokban az egyes modulok továbbfejlesztése a rendszer továbbfejlesztése újabb szolgáltatások megvalósításával 10

11 Megjegyzések a vízesés modellhez Az egyes fázisok eredményei különböző dokumentumok Ezeket mindkét félnek jóvá kell hagynia, aláírás Elvileg akkor indulhat a következő fázis, amikor az előző sikeresen befejeződött, a gyakorlatban azonban ezek átfedhetik egymást Lehet, hogy vissza kell lépnünk egy korábbi fázisra tervezés közben derül ki, hogy módosítanunk kell a specifikációt implementáció közben derül ki, hogy módosítanunk kell a tervet 11

12 Megjegyzések a vízesés modellhez A szoftverfolyamat általában nem lineáris folyamat, hanem többszörös iterációk sorozata A leggyakrabban akkor szükséges visszalépés, amikor megváltoznak a megrendelő elvárásai Ha ez gyakran előfordul, az felboríthatja a rendszer struktúráját Ezért a modell akkor használható jól, ha előre ismertek a felhasználói elvárások Maga a gondolkodásmód azonban máskor is jól használható, ha nem ragaszkodunk szigorúan a merev határokhoz 12

13 Evolúciós fejlesztés Alapelv: fejlesszünk ki egy kezdeti implementációt mutassuk meg a megrendelőnek módosítsuk az elvárásainak megfelelően ezt ismételjük addig, amíg az aktuális verzió teljesen meg nem felel a megrendelő elvárásainak Ez csak akkor alkalmazható, ha a megrendelő elfogadja ezt az eljárást 13

14 Evolúciós fejlesztés Ez a módszer nem választja szét mereven a specifikációt, a fejlesztést és a validálást, így lehetővé teszi a párhuzamos munkát és a gyors visszacsatolást 14

15 Az evolúciós fejlesztés típusai 1.Feltáró fejlesztés A folyamat célja, hogy a megrendelővel együtt alakítsuk ki a követelményeket, majd a végleges rendszert A fejlesztés a rendszer ismert részeivel kezdődik Egyre több új funkciót építünk a rendszerbe 2.Eldobható prototípus készítés A folyamat célja, hogy egyre jobban megértsük a követelményeket A prototípus célja, hogy jobban megértsük a megrendelő igényeit 15

16 Az evolúciós fejlesztés előnyei Hatékonyabb, mint a vízesés modell, ha olyan rendszert akarunk fejleszteni, amely közvetlenül megfelel a megrendelő elvárásainak A rendszerspecifikáció inkrementálisan, fokozatosan fejleszthető Ahogyan egyre jobban megértjük a felhasználó igényeit, azokat beépítjük a specifikációba és magába a rendszerbe 16

17 Az evolúciós fejlesztés hátrányai A folyamat nem jól látható A rendszerek gyakran szegényesen strukturáltak. A folyamat előrehaladása nem jól látható kívülről, a vezetőség nehezen tudja követni a projekt alakulását A folyamatos változtatások hatására gyakran elromlik a rendszer szerkezete Speciális eszközökre és technikákra van szükség A gyors fejlesztéshez speciális eszközökre van szükség (program generátorok) Ezek nem mindig kompatibilisek más eszközökkel 17

18 Összehasonlítás A tapasztalatok szerint a rövid élettartamú és kis (kevesebb, mint 100 ezer programsor), vagy közepes (500 ezer sorig) méretű rendszerek esetében az evolúciós fejlesztés a leghatékonyabb A nagy és hosszú élettartamú rendszerek esetében a problémák túlságosan nagy veszélyt jelentenek Ezek esetében egy kombinált eljárás használata javasolt 18

19 Kombinált megoldás Evolúciós megközelítéssel készítünk egy prototípust, aminek felhasználásával kialakítjuk a pontos specifikációt Eldobjuk a prototípust Vízesés módszerrel újraimplementáljuk a rendszert A rendszer bizonyos részeit, pl. a felhasználói felületet feltáró programozással fejleszthetjük ki leghatékonyabban 19

20 Formális rendszerfejlesztés A vízesés modellhez hasonló megközelítés, de nagyon precízen, matematikai módszerekkel fogalmazzuk meg a rendszerspecifikációt ezt a specifikációt matematikai transzformációk segítségével fokozatosan átalakítjuk futtatható programmá 20

21 Formális rendszerfejlesztés A formális specifikációt, elemi transzformációk sorozatával, lépésekben alakítjuk át futtatható programmá Olyan transzformációkat hajtunk végre, amelyekről be tudjuk bizonyítani, hogy helyesek Ezért nincsen szükség arra, hogy a teljes program helyességét bebizonyítsuk 21

22 A formális rendszerfejlesztés előnye és hátránya Ezt az eljárás szinte képtelenség megvalósítani nagyobb programok esetén, legalábbis nagyon nagy ráfordítás szükséges hozzá Vannak azonban olyan esetek, amikor szükség van arra, hogy formális módszerekkel is garantálni tudjuk a program helyességét: biztonsági rendszerek kritikus rendszerek (űrhajózás, katonaság) A nagy rendszerek közötti kölcsönhatások következményeit azonban ez a módszer sem tudja garantáltan hibátlanul kezelni, erre itt is hasonló tesztelési módszereket kell használni, mint a többi módszertan esetében 22

23 Újrafelhasználás-orientált fejlesztés Valamilyen szinten minden projektben előfordul, hogy felhasználunk kész komponenseket Amikor észrevesszük, hogy egy adott feladatra létezik kész megoldás, vagy legalább részmegoldás, akkor elővehetjük azt, szükség szerint módosítjuk, majd beépítjük a projektbe Az evolúciós megközelítés esetében ez szinte kötelező a gyors prototípus készítés érdekében A napjainkban divatos komponens alapú tervezés is ezen az ötleten alapszik 23

24 Újrafelhasználás-orientált fejlesztés A folyamat eleje és vége megegyezik a többi módszertannal, a középső fázisok azonban eltérőek 24

25 Az újrafelhasználás-orientált fejlesztés fázisai Komponenselemzés: az elkészült követelményspecifikáció alapján meg kell vizsgálni, hogy léteznek-e kész komponensek, amelyek felhasználhatók a követelmények kielégítésére Követelménymódosítás: a talált komponenseket össze kell vetni a követelményekkel gyakori eset, hogy módosítani kell a követelményeket ha ez nem lehetséges, akkor a talált komponens nem használható fel 25

26 Az újrafelhasználás-orientált fejlesztés fázisai Rendszertervezés újrafelhasználással ebben a fázisban meg kell tervezni a rendszer szerkezetét úgy, hogy a rendelkezésre álló kész komponensek beépíthetők legyenek amelyik feladatra nincsen kész komponens, azt el kell készíttetni Fejlesztés és integráció el kell készíteni az új komponenseket integrálni kell a meglévő és az új komponenseket ebben az esetben az integráció kapja a fő hangsúlyt 26

27 Újrafelhasználás-orientált fejlesztés előnyei és hátrányai Előnyök: kevesebb modult kell kifejleszteni csökken a költség és az időszükséglet Hátrányok: kompromisszumokat kell kötni a követelményekben lehet, hogy a rendszer így nem elégíti ki a megrendelő igényeit nem rendelkezünk teljes felügyelettel a rendszer minden komponense felett, ez gondot okozhat például a továbbfejlesztés során 27

28 Folyamatiteráció Minden eddigi módszernek vannak előnyei és hátrányai A legtöbb fejlesztés esetében több megközelítési módot kell alkalmazni, azaz egy hibrid modellt használunk Az is gyakran előfordul, hogy a folyamat egyes fázisait meg kell ismételni például a követelmények megváltozása miatt 28

29 Hibrid modellek Inkrementális fejlesztés Spirális fejlesztés a specifikációt, a tervezést és az implementálást is kis szakaszokra (inkremensek) osztjuk és ezeket egymás után több fordulóban hajtjuk végre A rendszer fejlesztése egy spirál vonallal jellemezhető a kezdeti vázlattól a kész rendszerig Mindkét módszer esetében a specifikációt a rendszerrel együtt fejlesztjük, így a teljes specifikáció nem lehet része a szerződésnek Ezt nem minden megrendelő fogadja el! 29

30 Inkrementális fejlesztés A vízesés modell megköveteli, hogy az ügyfél véglegesítse a specifikációt mielőtt a tervezés elkezdődne, a tervezőtől pedig azt, hogy az implementáció megkezdése előtt véglegesítse a rendszertervet Ennek eredménye egy jól menedzselhető, tiszta szerkezet, ami azonban nem nyújt lehetőséget a menet közbeni változtatásokra Az evolúciós megközelítési mód megengedi, hogy későbbre halasszuk a követelményekkel és a tervezéssel kapcsolatos döntéseket, ennek azonban egy gyengén strukturált, nehezen menedzselhető rendszer a következménye Jó lenne kombinálni a két módszer előnyeit! 30

31 Inkrementális fejlesztés 31

32 Inkrementális fejlesztés A vázlatos követelménymeghatározás után csoportokba soroljuk az elvárásokat Kiválasztjuk a megrendelő számára legfontosabb funkciókat Az ezeket megvalósító inkremenst a legmegfelelőbb módszertan szerint részletesen specifikáljuk, megtervezzük, kifejlesztjük, teszteljük és integráljuk a rendszerbe A megrendelő elkezdheti használni a részrendszert Ha minden igényt kielégítettünk, akkor készen vagyunk Ha maradtak még kielégítendő követelmények, akkor folytassuk a következő inkremenssel 32

33 Az inkrementális fejlesztés előnyei A megrendelőnek nem kell megvárnia, amíg a teljes rendszer elkészül, ha az első inkremensbe soroljuk a legfontosabb funkciókat, akkor ezeket már a fejlesztés legelején használatba veheti Az inkremensek specifikálásához felhasználhatjuk a korábbiak implementálása, sőt akár használata során szerzett tapasztalatokat Kisebb az esélye annak, hogy a teljes projekt kudarcba fullad, legalább részben nagy valószínűséggel elkészül 33

34 Az inkrementális fejlesztés előnyei Minden inkremenst a legmegfelelőbb módszertannal fejleszthetünk Ha a legfontosabb szolgáltatásokat az első inkremensekbe soroljuk, akkor ezeket fogjuk a legtöbbször használni, tesztelni, mielőtt a teljes fejlesztés véget ér, így kisebb az esélye annak, hogy kritikus funkciókban hibák maradnak 34

35 Spirális fejlesztés A szoftverfolyamatot egy spirálként ábrázoljuk. Minden egyes kör a folyamat egy-egy fázisának felel meg legbelső kör: megvalósíthatóság a követelmények meghatározása a rendszer tervezése Minden egyes ciklust négy fázisra bontunk, amelyek minden ciklusban hasonló jellegű tevékenységet jelentenek 35

36 36

37 A spirális fejlesztés ciklusainak négy fázisa Célok kijelölése: az adott ciklus által kitűzött célok meghatározása azonosítani kell a projekt kockázati tényezőit, és azoktól függően alternatív stratégiákat kell tervezni Kockázat becslése és csökkentése: minden egyes kockázati tényezőre vonatkozóan részletes elemzést kell végezni meg kell próbálni csökkenteni a kockázatot például, ha felmerül, hogy a követelmények nem megfelelőek, akkor célszerű fejleszteni egy prototípust 37

38 A spirális fejlesztés ciklusainak négy fázisa, folyt. Fejlesztés és validálás: a kockázatok vizsgálatának eredményétől függően választani kell egy fejlesztési modellt, például ha a felhasználói felületet érezzük kockázatosnak, akkor választhatjuk az evolúciós fejlesztést ha a biztonsági kockázatokat találtuk a legfontosabbnak, akkor használjuk a formális transzformációkat végezzük el a fejlesztést és ellenőrizzük a kész modult Tervezés meg kell vizsgálni a projektet, és el kell dönteni, hogy folytassuk-e a következő ciklussal 38

39 A spirális fejlesztés értékelése Más módszerekkel szemben kifejezetten számol a kockázati tényezőkkel Kockázat minden olyan dolog, ami elromolhat a projekt folyamán Ebben a modellben nincsenek kötelezően előírt fázisok, mint specifikáció, vagy tervezés Magába illeszthet bármilyen más módszertant, minden ciklusban eldöntjük, hogy ezt milyen módszerrel fejlesztjük ki 39

40 A szoftverfolyamat alapvető elemei A következőkben megvizsgáljuk közelebbről a szoftverfolyamat alapvető szakaszait, amelyek valamilyen formában minden módszertannak részét képezik: Szoftverspecifikáció Szoftvertervezés és implementáció Szoftvervalidáció Szoftverevolúció 40

41 Szoftverspecifikáció Más szóval követelménytervezés Ezt a fázist, gyakran nem veszik elég komolyan Az itt elkövetett hibák, pontatlanságok alapvetően befolyásolják a projekt eredményét A követelménytervezés eredménye a követelménydokumentum 41

42 A követelménytervezés folyamata 42

43 A követelmények tervezésének négy fázisa 1. Megvalósíthatósági tanulmány meg kell becsülni, hogy a felhasználók kívánságai kielégíthetők-e az adott körülmények között el kell dönteni, hogy a rendszer költséghatékony-e, megvalósítható-e az adott költségvetésből viszonylag gyorsan, hatékonyan el kell dönteni, hogy érdemes-e belefogni a projektbe 43

44 A követelmények tervezésének négy fázisa 2. Követelmények feltárása és elemzése Tisztázni és dokumentálni kell, hogy milyen elvárásoknak kell megfelelnie a majdani rendszernek Eszközei: a megrendelővel, potenciális felhasználókkal folytatott megbeszélések a jelenleg rendszer(ek) alapos tanulmányozása különböző rendszermodellek, prototípusok felállítása 44

45 A követelmények tervezésének négy fázisa 3. Követelményspecifikáció az elemzés eredményéül kapott információkat egy egységes dokumentummá alakítjuk Tartalmilag és formailag két részre tagolódik: felhasználói követelmények a megrendelők, felhasználók számára fogalmazzák meg a rendszerrel szemben fennálló absztrakt elvárásokat, ennek megfelelő formában és nyelvezetben kell készülnie rendszerkövetelmények a fejlesztők számára tartalmazzák a konkrét elvárásokat a rendszerrel szemben, tulajdonképpen megadjuk, hogy milyen funkciókkal kell rendelkeznie a rendszernek 45

46 A követelmények tervezésének négy fázisa 4. Követelményvalidáció ennek keretében ellenőrizendő, hogy mennyire valósak, konzisztensek, és mennyire teljesek a követelmények fel kell tárni és ki kell javítani az esetleges hibákat A folyamat végén a megrendelővel el kell fogadtatni, alá kell íratni a követelménydokumentumot Ennek alapján fognak dolgozni a fejlesztők, ha ebben hiba van, akkor a rendszer biztosan hibás lesz, ezért mindkét fél érdeke, hogy alapos munkával készüljön el, és mindkét fél elfogadja 46

47 Szoftvertervezés és implementáció Nem más, mint a rendszerspecifikáció futtatható programmá történő konvertálása Mindig magába foglalja a rendszer megtervezését, és a programozást, de például az evolúciós megközelítés esetén a specifikáció finomítását és tartalmazhatja 47

48 Szoftvertervezés Ki kell alakítani az elkészítendő rendszer szerkezetét, a komponensek közötti kapcsolatokat és az interfészeket Meg kell tervezni az adatok áramlási rendszerét a komponensek között A tervezés szinte soha nem egylépcsős folyamat, rendszerint többszörös iteráció és visszalépés után jutunk el a végeredményig. 48

49 A tervezési folyamat 49

50 A tervezési folyamat tevékenységei Architekturális tervezés: Absztrakt specifikáció: meghatározzuk és dokumentáljuk a rendszert felépítő alrendszereket, és a köztük lévő kapcsolatokat minden alrendszerre megadjuk a szolgáltatások specifikációját, és a rájuk vonatkozó követelményeket Interfész tervezése: minden alrendszerre meg kell tervezni és dokumentálni kell a többi alrendszer felé nyújtott interfészét ennek olyan egyértelműnek kell lennie, hogy anélkül tudjuk használni a szolgáltatásokat, hogy foglalkoznunk kellene az alrendszer belsejével 50

51 A tervezési folyamat tevékenységei Komponens tervezése: Adatszerkezet tervezése: meg kell tervezni az egyes szolgáltatásokat megvalósító komponenseket és azok interfészeit. meg kell tervezni a program által használt adatszerkezeteket Algoritmus tervezése: meg kell tervezni a programban használatos algoritmusokat Ez egy általános modell, a gyakorlatban ezek a lépések nagyon sokféleképpen variálhatók 51

52 Tervezési módszerek A gyakorlatban a tervezés legtöbbször egy ad hoc folyamat, nincs mögötte módszertan A tervező kiindulva a követelményekből elképzel és leír egy rendszert általában természetes nyelven, nem formálisan Ennek alapján megindul az implementáció, aminek során legtöbbször eltérnek a tervtől, és ezt már nem dokumentálják, így az elkészült rendszer és a terv jelentősen eltérhet egymástól Ez jelentősen megnehezíti a rendszer későbbi üzemeltetését, továbbfejlesztését 52

53 Tervezési módszerek Az évek során többféle tervezési módszertant dolgoztak ki, amelyek különböző módokon formalizálják a tervezési folyamatot Strukturált tervezési módszertanok: Structured Design (Constantine, Yourdon, 1979) Structured System Analysis (Gane, Sarson, 1979) Jackson System Development (Jackson, 1983) Objektumorientált tervezési módszertanok: Robinson, 1992 Booch, 1994 Raumbaugh és mások, 1991 Booch és mások, 1999 Raumbaugh és mások, 1999a, 1999b 53

54 Strukturált tervezési módszertanok Különböző, legtöbbször grafikus rendszermodelleket tartalmaznak Szabványos jelölésrendszereket alakítottak ki Szabványos tervezési dokumentumokat határoznak meg Különböző CASE eszközöket is kialakítottak ezek támogatására CASE: Computer Aided Software Engineering A különböző módszertanok a hasonlóság mellett kisebb módosításokkal specializálódtak bizonyos területekre Nincsen egyértelműen jobb, vagy rosszabb módszer 54

55 Strukturált tervezési módszertanok A különböző módszertanok meghatároznak: tervezési folyamatmodellt jelölésrendszert a terv leírásához jelentésformátumokat szabályokat tervezési útmutatókat 55

56 Strukturált rendszermodellek A különböző módszertanok a következő rendszermodellek közül támogatnak egyet, vagy többet: Adatfolyam modell a rendszert különböző adattranszformációk segítségével modellezzük Egyed-kapcsolat (ER-Entity-Relationship) modell különböző egyedek és köztük lévő kapcsolatok leírására szolgál. Az ER-modellek az adatbázis-szerkezetek leírásának modelljei is. 56

57 Strukturált rendszermodellek Folytatás Strukturált modell Objektumorientált módszerek a rendszer komponenseit és a köztük lévő kölcsönhatásokat dokumentálja a rendszer öröklődési modelljét tartalmazzák, modellezik a statikus és dinamikus kapcsolatokat az objektumok között, és az objektumok együttműködését Egyes módszerek más rendszermodelleket is használnak pl. állapotátmenet-diagrammok, egyed-élettartam mátrixok, stb. 57

58 Programozás és nyomkövetés A megtervezett rendszer elkészítése, és az esetleges hibák megkeresése, kijavítása Bizonyos részeit CASE eszközökkel is lehet generálni A programozás még ma is meglehetősen személyes tevékenység, ahány programozó, annyi stílusban dolgozik A programozás közben folyamatosan teszteljük a kódot, megkeressük a hibákat, és kijavítjuk őket Ezt nevezzük nyomkövetésnek, belövésnek 58

59 Debugger Programozói segédeszköz a programhibák felderítésére, és kijavítására Legfontosabb funkciói: a program soronkénti végrehajtása töréspontok kezelése, feltételes töréspontok a változók értékének figyelése, módosítása futás közben a memória tartalmának figyelemmel kísérése assembly szintű nyomkövetés a processzor regisztereinek figyelése, módosítása a hívási verem (call stack) megfigyelése 59

60 Szoftvervalidáció Verifikáció és validáció Megvizsgálandó, hogy az elkészült rendszer megfelel-e a specifikációnak Az implementáció teljes ideje alatt folyamatosan folyik, de a rendszer elkészülte után feltétlenül szükség van alapos tesztelésre Egy összetett rendszer tesztelését alaposan meg kell tervezni, és részletekben kell elvégezni 60

61 A tesztelési folyamat 61

62 A tesztelési folyamat szakaszai Egység tesztelése Modul tesztelése minden egyes komponenst önmagában tesztelni kell, és el kell érni, hogy hibátlan legyen a modul egymással összefüggő komponensek gyűjteménye ezeket a többi modultól függetlenül lehet tesztelni Alrendszerek tesztelése az alrendszert alkotó modulok tesztjeinek összessége, kiegészítve a köztük lévő kapcsolatok, az interfészek tesztelésével 62

63 A tesztelési folyamat szakaszai Rendszerek tesztelése a teljes rendszer tesztelése, különös tekintettel az alrendszerek kapcsolódásainak vizsgálatára a rendszerhibák legnagyobb része az alrendszerek kölcsönhatásaiból származik, ezeket a hibákat csak a rendszer tesztelése során lehet felderíteni ezen a szinten kell megvizsgálni, hogy a rendszer teljesíti-e a specifikációban meghatározott funkcionális és nem funkcionális követelményeket 63

64 A tesztelési folyamat szakaszai Átvételi tesztelés a tesztelés legutolsó fázisa a rendszer használatbavétele előtt ekkor már a megrendelő saját adataival folyik a tesztelés szerencsés, ha a megrendelő is részt vesz benne ekkor derülhetnek ki a követelménytervezés során elkövetett hibák, hogy a rendszer nem felel meg a felhasználó elvárásainak, vagy a rendszer teljesítménye elfogadhatatlan 64

65 Alfa és béta tesztelés Az átvételi tesztet szokás alfa tesztelés-nek hívni Amikor egy szoftvertermék dobozos termékként kerül piacra, akkor szokás a béta teszt-nek nevezett eljárást használni A béta teszt során a potenciális felhasználók egy részéhez juttatják el a programot, akik valós, éles körülmények között kezdik el használni a szoftvert, valamilyen szerződés keretében Tapasztalataikról beszámolnak a fejlesztőknek, akik ezeket felhasználják a rendszer javítására Az elkészülő új verziót egy újabb béta tesztre bocsátják Ez ismétlődik amíg a rendszer minősége el nem éri a kívánt szintet 65

66 Szoftverevolúció Miután egy hardver eszköz gyártása elkezdődik, bármilyen változtatás szinte lehetetlen, illetve nagyon költséges A szoftver esetében azonban a fejlesztés (gyártás) alatt bármikor elvégezhető bármilyen módosítás Sőt az sem lehetetlen, hogy a felhasználónál lévő szoftveren hajtsunk végre módosításokat Ezért van értelme szoftverevolúcióról beszélni 66

67 Szoftverevolúció Ez a korszerű felfogás a szoftverevolúcióról A szoftverrendszerek egész életciklusuk alatt változhatnak, fejlődhetnek 67

68 Rational Unified Process (RUP) egy modern folyamatmodell, az UML-ből származik hibrid modell, mindegyik általános modellből tartalmaz elemeket támogatja az iterációt míg a hagyományos modellek a folyamatoknak csak egy-egy nézetét támogatják, addig a RUP három perspektívával rendelkezik 68

69 A RUP perspektívái 1.dinamikus perspektíva a modell fázisait mutatja 2.statikus perspektíva a végrehajtandó folyamattevékenységeket mutatja 3.gyakorlati perspektíva jól hasznosítható gyakorlatokat javasol a folyamat alatt 69

70 A RUP fázisai 1.Indítás a projekt üzleti vonatkozásainak tisztázása. kik lesznek a projekt résztvevői, ezek kapcsolatai el kell dönteni, hogy elindítsuk-e a projektet 2.Előkészítés célja a probléma megértése, a projektterv kifejlesztése a kulcsfontosságú kockázati tényezők azonosítása Eredménye: a rendszerkövetelmények modellje (UML használati eset) architekturális leírás a szoftver fejlesztési terve 70

71 A RUP fázisai 2 3.Létrehozás a rendszerterv elkészítése implementáció tesztelés 4.Átadás a rendszer áttelepítése a fejlesztési környezetből a felhasználói környezetbe 71

72 A RUP fázisai A RUP két szinten támogatja az iterációt, lásd az ábrán! 72

73 A RUP statikus munkafolyamatai 73

74 A RUP fázisok és folyamatok kapcsolata A RUP fázisai és munkafolyamatai nincsenek kötelező érvénnyel egymáshoz rendelve Elméletileg bármely munkafolyamat bármelyik fázisban lehet aktív Persze ritkán történik Tesztelés az Indítás fázisban, de ez a tervező döntése 74

75 A RUP gyakorlati perspektívája Fejlesszük a szoftvert iteratívan Kezeljük a követelményeket tervezzük meg a rendszer inkremenseit a prioritások alapján, és hozzuk előre a magas prioritású tulajdonságokat dokumentáljuk a megrendelő követelményeit, és tartsuk mindig karban annak változásait elemezzük a változások rendszerre gyakorolt hatásait mielőtt elfogadnánk azokat Használjunk komponens alapú architektúrákat a rendszert szervezzük komponensekbe 75

76 A RUP gyakorlati perspektívája 2 Modellezzük a szoftver vizuálisan Ellenőrizzük a szoftverminőséget használjunk grafikus UML-modelleket a szoftver statikus és dinamikus nézeteihez bizonyosodjunk meg róla, hogy a szoftver megfelel a minőségi előírásoknak Ellenőrizzük a szoftverváltoztatásokat menedzseljük a szoftverváltoztatásokat változtatáskezelési eszközökkel és konfigurációkezelési eljárásokkal 76

77 A RUP értékelése A RUP nem alkalmas minden különböző típusú szoftver kifejlesztésére, de az általános folyamatok új generációjának tekinthető Legfontosabb újítása: a fázisok és a munkafolyamatok szétválasztása az üzembeállítás beemelése a munkafolyamatok közé A fázisok dinamikusak és konkrét célokkal rendelkeznek A munkafolyamatok statikusak és olyan technikai tevékenységeket írnak le, amelyek felhasználhatók az egész fejlesztés folyamán 77

78 Számítógéppel támogatott szoftvertervezés (CASE) Computer-Aided Software Engineering (CASE) Olyan szoftverek együttese, amelyek a szoftverfolyamat egyes tevékenységeinek támogatására szolgálnak Ismerünk már ilyen eszközöket, soroljuk fel ezeket! Most megismerkedünk újabb típusokkal 78

79 Néhány példa CASE eszközök használatára grafikus rendszermodellek fejlesztése a tervek megértését segítő adatszótárak kezelése felhasználói interfész tervezése és implementálása program belövés támogatása, debuggerek kódgenerálás automatikus fordítás egyik programnyelvről egy másikra, pl. COBOL 79

80 A CASE technológiák elterjedése Napjainkban a szoftverfolyamat szinte minden fázisához léteznek CASE eszközök, legtöbbször a rutintevékenységeket támogatják Ennek hatására javult a szoftverek minősége, de ez kisebb mértékű. mint ahogyan kezdetben gondolták, egyes mérések szerint kb. 40%-os a javulás A CASE technológia kezdeti pártolói nagyságrendi javulást jósoltak Nem vált valóra az a várakozás sem, hogy a CASE lényegesen csökkenti a szoftverfolyamat költségeit 80

81 A CASE technológiák korlátai Miért nem következhetett be a várt nagyságrendi változás? a szoftvertervezés tervezői tevékenység, ami kreatív gondolkodáson alapszik, a CASE eszközök azonban ebben nem sokat tudnak segíteni, azok csak a rutintevékenységeket tudják támogatni, csak kisebb mértékben tudnak a mesterséges intelligencia eszközeivel segíteni a szoftvertervezés nagyrészt csoportos tevékenység, állandó kommunikációt, egyeztetést igényel, ebben is csak kisebb segítséget tud nyújtani a számítógép Párhuzam: gépi fordítás 81

82 A CASE eszközök osztályozása Három szempontból fogjuk osztályozni a CASEeszközöket: funkcionális szempontból: folyamatnézőpontból: a CASE eszközök funkciói szerint milyen folyamatot támogatnak integrációs nézőpontból: hogyan vannak integrált egységekbe szervezve 82

83 Funkcionális osztályozás 83

84 Folyamatközpontú osztályozás 84

85 Integrációs szempontú osztályozás Eszközök Eszközkészletek az egyéni folyamatlépéseket támogatják, például fordítóprogram, tesztelőeszközök, stb. a munkafolyamat egy-egy fázisát támogatják, például a specifikációt, tervezést, stb. ezek legtöbbször a fenti eszközökből összeállított csomagok, készletek Környezetek a szoftverfolyamat több, lehetőleg minden részét támogatják egy integrált keretben 85

86 CASE eszközök, eszközkészletek, környezetek osztályozása 86

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

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

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver

Részletesebben

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

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

Részletesebben

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

Részletesebben

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

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

Részletesebben

Információtartalom vázlata

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

Részletesebben

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

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

Részletesebben

Bevezetés a programozásba

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

Részletesebben

Szoftverfejlesztési modellek

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

Részletesebben

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

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

Részletesebben

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai

Részletesebben

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

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

Részletesebben

4. A szoftvergyártás folyamata

4. A szoftvergyártás folyamata 4. A szoftvergyártás folyamata Kérdések Mi a szoftvergyártás modellje? Mi a három alapvető modell és mikor használjuk ezeket? Mik a követelménytervezés, a szoftverfejlesztés, a tesztelés és az szoftver-evolúció

Részletesebben

Szoftverspecifikáció fázis: Követelmény specifikáció. 2. fázis: Követelmények feltárása és elemzése

Szoftverspecifikáció fázis: Követelmény specifikáció. 2. fázis: Követelmények feltárása és elemzése Folyamattevékenységek Dr. Mileff Péter Alapvetıen négy különbözı folyamattevékenység: Specifikáció (követelménytervezés) Tervezés és implementáció Validáció Evolúció Ezeket a különféle fejlesztési folyamatmodellek

Részletesebben

Információs rendszerek Információsrendszer-fejlesztés

Információs rendszerek Információsrendszer-fejlesztés Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés

Részletesebben

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

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

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

Részletesebben

Programfejlesztési Modellek

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

Részletesebben

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

55 481 04 0000 00 00 Web-programozó Web-programozó A /2007 (II. 27.) SzMM rendelettel módosított 1/2006 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről alapján. Szakképesítés,

Részletesebben

KÉSZÍTETTE: DR. MILEFF PÉTER

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

Részletesebben

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység

MINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység MINISZTERELNÖKI HIVATAL Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1188-06/1 Szóbeli vizsgatevékenység Szóbeli vizsgatevékenység időtartama: 45 perc A 20/2007. (V. 21.) SZMM rendelet

Részletesebben

Szoftvertechnológia 2008/2009. tanév 2. félév 1. óra. Szoftvertechnológia

Szoftvertechnológia 2008/2009. tanév 2. félév 1. óra. Szoftvertechnológia Szoftvertechnológia Szabolcsi Judit 2008 (Ajánlott irodalom: Ian Somerville: Szoftverrendszerek fejlesztése. Második, bıvített, átdolgozott kiadás, Panem Kiadó, Budapest 2007.) ÁTTEKINTÉS I. Szoftver és

Részletesebben

Szoftver-technológia I.

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

Részletesebben

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

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

Részletesebben

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

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár Software Engineering Dr. Barabás László Ismétlés/Kitekintő 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észletesebben

01. gyakorlat - Projektalapítás

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

Részletesebben

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

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

Részletesebben

Miskolci Egyetem Általános Informatikai Tanszék

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

Részletesebben

A tesztelés feladata. Verifikáció

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

Részletesebben

Java programozási nyelv

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

Szoftverfejlesztés. (MSc) Miskolci Egyetem Általános Informatikai Tanszék MISKOLCI EGYETEM GÉPÉSZMÉRNÖKI ÉS INFORMATIKAI KAR

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

Részletesebben

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

Bánsághi Anna anna.bansaghi@mamikon.net. Bánsághi Anna 1 of 54 SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT Bánsághi Anna 1 of 54 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK

Részletesebben

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

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

Részletesebben

Programozás alapjai Bevezetés

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

Részletesebben

S01-7 Komponens alapú szoftverfejlesztés 1

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

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

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

Részletesebben

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

Autó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 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észletesebben

Szoftver újrafelhasználás

Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással

Részletesebben

Projectvezetők képességei

Projectvezetők képességei Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés

Részletesebben

A szoftverfejlesztés eszközei

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

Részletesebben

Programrendszerek tanúsítása szoftverminőség mérése

Programrendszerek tanúsítása szoftverminőség mérése SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát

Részletesebben

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től

cím: 6725 Szeged Bokor u. 18. telefon: +36 1 808 9666 Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét

Részletesebben

Objektum orientált software fejlesztés (Bevezetés)

Objektum orientált software fejlesztés (Bevezetés) Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok

Részletesebben

Szoftverprototípus készítése. Szoftverprototípus készítése. Szoftverprototípus készítése 2011.10.23.

Szoftverprototípus készítése. Szoftverprototípus készítése. Szoftverprototípus készítése 2011.10.23. Szoftverprototípus készítése Dr. Mileff Péter A prototípus fogalma: a szoftverrendszer kezdeti verziója Mi a célja? Arra használják, hogy bemutassák a koncepciókat, kipróbálják a tervezési opciókat, jobban

Részletesebben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és

Részletesebben

Ami a vízesésen túl van

Ami a vízesésen túl van Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két

Részletesebben

Tesztelés az XP-ben Tesztelés az XP-ben. A tesztelés kulcsjellemzői:

Tesztelés az XP-ben Tesztelés az XP-ben. A tesztelés kulcsjellemzői: Dr. Mileff Péter 1 2 Az XP nagyobb hangsúlyt fektet a tesztelés folyamatára, mint a többi agilis módszer Oka: a teszteléssel és a rendszer validálásával kapcsolatos problémák elkerülése. A rendszertesztelés

Részletesebben

ALKALMAZÁS KERETRENDSZER

ALKALMAZÁS KERETRENDSZER JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak

Részletesebben

1. Bevezetés a szoftvertechnológiába

1. 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észletesebben

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

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

Részletesebben

1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak.

1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak. 1. 1. Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak. A szoftver: Számítógép-programok és a hozzájuk tartozó dokumentációk összessége (Somerville def.) (A gyakorlatban

Részletesebben

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment

Részletesebben

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01.

minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. minic studio Melinda Steel Weboldal kivitelezési árajánlat 2013.03.01. Weboldal 1. Előkészítés 1.1. Anyaggyűjtés 1.2. Kutatás 2. Tervezés 3. Kivitelezés 3.1. Drótváz 3.2. Grafikus tervezés 3.3. Programozás

Részletesebben

MIÉRT KELL TESZTELNI?

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

Részletesebben

Programtervezés. Dr. Iványi Péter

Programtervezés. Dr. Iványi Péter Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű

Részletesebben

Szoftverminőségbiztosítás

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ő

Részletesebben

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

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

Részletesebben

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

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

Részletesebben

Szoftverminőségbiztosítás

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

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

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

Részletesebben

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

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

Részletesebben

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

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

Részletesebben

Programozási technológia

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

Részletesebben

Nagy bonyolultságú rendszerek fejlesztőeszközei

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

Részletesebben

Szoftverfejlesztési folyamatok és szoftver minőségbiztosítás

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

Részletesebben

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

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

Részletesebben

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

Bá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észletesebben

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Autó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észletesebben

S01-8 Komponens alapú szoftverfejlesztés 2

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

Részletesebben

Rendszer-modellezés, modellezési technikák

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

Szoftver-mérés. Szoftver metrikák. Szoftver mérés

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

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

TOGAF elemei a gyakorlatban

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

Részletesebben

A 9001:2015 a kockázatközpontú megközelítést követi

A 9001:2015 a kockázatközpontú megközelítést követi A 9001:2015 a kockázatközpontú megközelítést követi Tartalom n Kockázat vs. megelőzés n A kockázat fogalma n Hol található a kockázat az új szabványban? n Kritikus megjegyzések n Körlevél n Megvalósítás

Részletesebben

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

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

Részletesebben

Szakterü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 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észletesebben

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt

Programozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt Programozási Technológia 1. 1. előadás bevezetés Előadó: Lengyel Zsolt Tartalom Információk a tantárggyal kapcsolatban Programozási technológiai eszközök áttekintése UML tervezőeszközök JAVA fejlesztőeszközök,

Részletesebben

Szoftvertechnológia 2012/2013. tanév 1. félév. Szoftvertechnológia

Szoftvertechnológia 2012/2013. tanév 1. félév. Szoftvertechnológia Szoftvertechnológia Szabolcsi Judit 2012 Tartalom I. Szoftver és szoftvertervezés... 4 I.1. Mi a szoftvertervezés?... 4 I.2. Mi a szoftver?... 5 II. A szoftverfolyamat... 6 II.1. Szoftverspecifikáció...

Részletesebben

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

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

Részletesebben

30 MB INFORMATIKAI PROJEKTELLENŐR

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

Részletesebben

A szoftverfolyamat és s a tesztelés

A szoftverfolyamat és s a tesztelés A szoftverfolyamat és s a tesztelés Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2008. 11. 19. swproc / 1 A szoftverfolyamat Alaptevékenységek Tartalom Szoftverfolyamat modellek A

Részletesebben

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

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

Részletesebben

Bevezetés: Mi a CRM? A tervezési fázis helye és szerepe a CRM implementációs projektekben Jógyakorlatok: mire figyeljünk a CRM tervezés közben.

Bevezetés: Mi a CRM? A tervezési fázis helye és szerepe a CRM implementációs projektekben Jógyakorlatok: mire figyeljünk a CRM tervezés közben. Mire figyeljünk a CRM rendszerek tervezésekor? Gyakorlati tapasztalatok Komáromi András Bevezetés: Mi a CRM? A tervezési fázis helye és szerepe Miért fontos a tervezési fázis? A tervezési fázis helye és

Részletesebben

SW-project management

SW-project management SW-project management 1 PM tárgya tervezés megfigyelés ellenőrzés emberek folyamat események 4P People (emberek) Product (termék) Process (folyamat) Project PM szintjei 3 SW előállítási folyamat bizonytalansága

Részletesebben

Biztonsági folyamatirányító. rendszerek szoftvere

Biztonsági folyamatirányító. rendszerek szoftvere Biztonsági folyamatirányító rendszerek szoftvere 1 Biztonsági folyamatirányító rendszerek szoftvere Tartalom Szoftverek szerepe a folyamatirányító rendszerekben Szoftverek megbízhatósága Szoftver életciklus

Részletesebben

A fejlesztési szabványok szerepe a szoftverellenőrzésben

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

Részletesebben

UML (Unified Modelling Language)

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

Dr. Topár József 3. Eladás Marketing Külső szolgáltatás Alvállalkozók Fogyasztók. Engineering Termelés Anyagszabályozás Beszerzés Minőség

Dr. Topár József 3. Eladás Marketing Külső szolgáltatás Alvállalkozók Fogyasztók. Engineering Termelés Anyagszabályozás Beszerzés Minőség A minőségterv (quality plan) olyan dokumentum, amely előírja, hogy milyen folyamatokat eljárásokat és vele kapcsolódó erőforrásokat ki és mikor fogja alkalmazni, hogy egy konkrét projekt, termék, folyamat

Részletesebben

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

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

Részletesebben

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

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

Részletesebben

Tartalom. Nagy rendszerek struktúrált fejlesztése (SSADM) Bevezető. Történet A strukturális modell Az SSADM technikái Az SSADM termékei

Tartalom. Nagy rendszerek struktúrált fejlesztése (SSADM) Bevezető. Történet A strukturális modell Az SSADM technikái Az SSADM termékei Nagy rendszerek struktúrált fejlesztése (SSADM) Szoftvertechnológia előadás Tartalom Áttekintés A strukturális modell Az SSADM technikái Az SSADM termékei 2 Bevezető Az SSADM az angol "Structured Systems

Részletesebben

A szoftverfejlesztés eszközei

A szoftverfejlesztés eszközei A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Segédeszközök szükségessége Szoftver

Részletesebben

Már megismert fogalmak áttekintése

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

Részletesebben

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

A fejlesztés módszertana

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

Név: Neptun kód: Pontszám:

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,

Részletesebben

Statikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása 2011.04.25.

Statikus technikák: A szoftver átvizsgálása. Statikus technikák: A szoftver átvizsgálása 2011.04.25. Dr. Mileff Péter A V & V tervezési folyamatoknak egyensúlyt kell kialakítani a verifikáció és a validációstatikus és dinamikus technikái között. 1 2 Statikus technikák: A szoftver átvizsgálása A szisztematikus

Részletesebben

2. A szoftver mint termék llításának folyamata, a szoftver életciklus modelljei

2. A szoftver mint termék llításának folyamata, a szoftver életciklus modelljei 2. A szoftver mint termék előáll llításának folyamata, a szoftver életciklus modelljei A szoftverfolyamat modellje a szoftverfolyamat absztrakt reprezentációja egy adott speciális aspektusból. Szokásos

Részletesebben