Szoftvermenedzsment 4. fejezet A szoftverfolyamat
|
|
- Anikó Orbán
- 8 évvel ezelőtt
- Látták:
Á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.
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észletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
RészletesebbenFé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észletesebbenA 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észletesebbenHatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok
RészletesebbenInformációtartalom vázlata
1. Az Ön cégétől árajánlatot kértek egy üzleti portál fejlesztésére, amelynek célja egy online áruház kialakítása. Az árajánlatkérés megválaszolásához munkaértekezletet tartanak, ahol Önnek egy vázlatos
RészletesebbenFé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észletesebbenBevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
RészletesebbenSzoftverfejlesztési modellek
i modellek Ha egy kitűzött célt el akarunk érni, elképzeljük, megtervezzük a hozzá vezető utat. A szoftverfejlesztés esetében a cél a szoftvertermék előállítása az ehhez elvezető utat fejlesztési módszernek
RészletesebbenVerifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
RészletesebbenA szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
RészletesebbenBevezeté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észletesebben4. A szoftvergyártás folyamata
4. A szoftvergyártás folyamata Kérdések Mi a szoftvergyártás modellje? Mi a három alapvető modell és mikor használjuk ezeket? Mik a követelménytervezés, a szoftverfejlesztés, a tesztelés és az szoftver-evolúció
RészletesebbenSzoftverspecifiká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észletesebbenInformációs rendszerek Információsrendszer-fejlesztés
Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés
RészletesebbenV. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
RészletesebbenSzoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
RészletesebbenProgramfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
Részletesebben55 481 04 0000 00 00 Web-programozó Web-programozó
A /2007 (II. 27.) SzMM rendelettel módosított 1/2006 (II. 17.) OM rendelet Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről alapján. Szakképesítés,
RészletesebbenKÉ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észletesebbenMINISZTERELNÖKI HIVATAL. Szóbeli vizsgatevékenység
MINISZTERELNÖKI HIVATAL Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése: 1188-06/1 Szóbeli vizsgatevékenység Szóbeli vizsgatevékenység időtartama: 45 perc A 20/2007. (V. 21.) SZMM rendelet
RészletesebbenSzoftvertechnoló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észletesebbenSzoftver-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észletesebbenSoftware Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, Személyek és szerepkörök Kitekintő: Modell, módszertan 2 Dr. Barabás
RészletesebbenSoftware Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/
Részletesebben01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
RészletesebbenMiskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert
Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,
RészletesebbenMiskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenA tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenJava programozási nyelv
Java programozási nyelv 2. rész Vezérlő szerkezetek Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/23 Tartalomjegyzék
RészletesebbenSzoftverfejleszté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észletesebbenBá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észletesebbenSoftware engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz:
Software engineering (Software techológia) Bevezetés, alapfogalmak Utolsó módosítás: 2006. 02. 16. SWENGBEV / 1 Történelem 1. 60-as évek Megoldandó problémák: egyedi problémákra kis programok Fejlesztő:
RészletesebbenProgramozás alapjai Bevezetés
Programozás alapjai Bevezetés Miskolci Egyetem Általános Informatikai Tanszék Programozás alapjai Bevezetés SWF1 / 1 Tartalom A gépi kódú programozás és hátrányai A magas szintÿ programozási nyelv fogalma
RészletesebbenS01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
RészletesebbenVerziókövető rendszerek használata a szoftverfejlesztésben
Verziókövető rendszerek használata a szoftverfejlesztésben Dezső Balázs Szakszeminárium vezető: Molnár Bálint Budapesti Corvinus Egyetem Budapest, 2009. június 24. 1 Bevezetés 2 Verziókövetőrendszerek
RészletesebbenS S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method Mi az SSADM? Kifejezetten a rendszerelemzést és a szoftverfejlesztést támogatja. Eljárási, műszaki és dokumentációs
RészletesebbenAutóipari beágyazott rendszerek Dr. Balogh, András
Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat
RészletesebbenSzoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
RészletesebbenProjectvezetők képességei
Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés
RészletesebbenA szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató
RészletesebbenProgramrendszerek tanúsítása szoftverminőség mérése
SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát
Részletesebbencí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észletesebbenObjektum orientált software fejlesztés (Bevezetés)
Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok
RészletesebbenSzoftverprototí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észletesebbenOpenCL 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észletesebbenAmi a vízesésen túl van
Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két
RészletesebbenTesztelé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észletesebbenALKALMAZÁS KERETRENDSZER
JUDO ALKALMAZÁS KERETRENDSZER 2014 1 FELHASZNÁLÓK A cégvezetők többsége a dobozos termékek bevezetésével összehasonlítva az egyedi informatikai alkalmazások kialakítását költséges és időigényes beruházásnak
Részletesebben1. Bevezetés a szoftvertechnológiába
1. Bevezetés a szoftvertechnológiába Kérdések Mi a szoftvertechnológia (szoftvermérnökség)? Mik a szoftvertechnológiát érintő legfontosabb kérdések és válaszok? Etikai és szakmai kérdések: hogyan érintik
RészletesebbenSzoftverfejleszté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észletesebben1. 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észletesebbenAlkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (8) Szoftverminőségbiztosítás Szoftvertesztelési folyamat (folyt.) Szoftvertesztelési ráfordítások (Perry 1995) Tesztelésre fordítódik a projekt költségvetés 24%-a a projekt menedzsment
Részletesebbenminic 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észletesebbenMIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
RészletesebbenProgramtervezé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észletesebbenSzoftverminő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észletesebbenBevezetés a programozásba előadás: Alapvető programtervezési elvek
Bevezetés a programozásba 2 12. előadás: Alapvető programtervezési elvek Miről lesz szó A félév célja a nagyobb programrendszerek felépítésében való részvétel képességét megszerezni Mindenki a saját widgetkészletének
RészletesebbenSzoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom
Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver
RészletesebbenSzoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
RészletesebbenIRÁ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észletesebbenFolyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
RészletesebbenObject 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észletesebbenProgramozási technológia
Programozási technológia Dinamikus modell Tevékenységdiagram, Együttműködési diagram, Felhasználói esetek diagramja Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Tevékenység diagram A tevékenység (vagy
RészletesebbenNagy bonyolultságú rendszerek fejlesztőeszközei
Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő
RészletesebbenSzoftverfejleszté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észletesebbenAngolul: 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észletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 1 of 67
SZOFTVERTECHNOLÓGIA Bánsághi Anna anna.bansaghi@mamikon.net 5. ELŐADÁS - RENDSZERTERVEZÉS 1 1 of 67 TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK
RészletesebbenAutóipari beágyazott rendszerek. Komponens és rendszer integráció
Autóipari beágyazott rendszerek és rendszer integráció 1 Magas szintű fejlesztési folyamat SW architektúra modellezés Modell (VFB) Magas szintű modellezés komponensek portok interfészek adattípusok meghatározása
RészletesebbenS01-8 Komponens alapú szoftverfejlesztés 2
S01-8 Komponens alapú szoftverfejlesztés 2 Tartalom 1. Komponens megvalósítása: kölcsönhatás modell, viselkedési vagy algoritmikus modell és strukturális modell. 2. Komponens megtestesítés: finomítás és
RészletesebbenRendszer-modellezés, modellezési technikák
Rendszer-modellezés, modellezési technikák System engineering and modelling Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 8. Roger S. Pressman: Software Engineering, 5th e. chapter 10,
RészletesebbenSzoftver-mérés. Szoftver metrikák. Szoftver mérés
Szoftver-mérés Szoftver metrikák Szoftver mérés Szoftver jellemz! megadása numerikus értékkel Technikák, termékek, folyamatok objektív összehasonlítása Mér! szoftverek, programok CASE eszközök Kevés szabványos
RészletesebbenKövetelmény meghatározás. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1
Követelmény meghatározás Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1 A követelményjegyzék a rendszerfejlesztési alapmintában Döntési struktúra Vizsgálat/ helyzetfelmérés
RészletesebbenTOGAF elemei a gyakorlatban
TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési
RészletesebbenA 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észletesebbenThe Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos
The Unified Software Development Process Rational Unified Process Krizsán Zoltán Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 12. 04. Történet The Rational Rational
RészletesebbenSzakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman
Szakterületi modell A fogalmak megjelenítése 9. fejezet Applying UML and Patterns Craig Larman 1 Néhány megjegyzés a diagramokhoz Ez a tárgy a rendszer elemzésről és modellezésről szól. Noha például egy
RészletesebbenProgramozási Technológia 1. 1. előadás bevezetés. Előadó: Lengyel Zsolt
Programozási Technológia 1. 1. előadás bevezetés Előadó: Lengyel Zsolt Tartalom Információk a tantárggyal kapcsolatban Programozási technológiai eszközök áttekintése UML tervezőeszközök JAVA fejlesztőeszközök,
RészletesebbenSzoftvertechnoló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észletesebbenSzoftvertechnoló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észletesebben30 MB INFORMATIKAI PROJEKTELLENŐR
INFORMATIKAI PROJEKTELLENŐR 30 MB DOMBORA SÁNDOR BEVEZETÉS (INFORMATIKA, INFORMATIAKI FÜGGŐSÉG, INFORMATIKAI PROJEKTEK, MÉRNÖKI ÉS INFORMATIKAI FELADATOK TALÁKOZÁSA, TECHNOLÓGIÁK) 2016. 09. 17. MMK- Informatikai
RészletesebbenA 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észletesebbenHogyan 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észletesebbenBevezeté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észletesebbenSW-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észletesebbenBiztonsá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észletesebbenA 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észletesebbenUML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
RészletesebbenDr. 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észletesebbenBánsághi Anna anna.bansaghi@mamikon.net. 2014 Bánsághi Anna 1 of 31
IMPERATÍV PROGRAMOZÁS Bánsághi Anna anna.bansaghi@mamikon.net 9. ELŐADÁS - OOP TERVEZÉS 2014 Bánsághi Anna 1 of 31 TEMATIKA I. ALAPFOGALMAK, TUDOMÁNYTÖRTÉNET II. IMPERATÍV PROGRAMOZÁS Imperatív paradigma
RészletesebbenTartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség
Tartalom 6. Unified Process & Rational Unified Process lmi a szoftverfejlesztési módszertan? lunified Process lrational Unified Process (RUP) la Rational XDE CASE eszköz lpélda BMF-NIK-SZTI Tick: Szoftver
RészletesebbenTartalom. 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észletesebbenA szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Segédeszközök szükségessége Szoftver
RészletesebbenMá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észletesebbenMŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI
MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN
RészletesebbenA fejlesztés módszertana
A fejlesztés módszertana (A térkép) 2003. május ago@intermail.hu http://www.ago.sw.hu 2003. május 1/58 1. BEVEZETÉS A MÓDSZERTANOK VILÁGÁBA...5 MI A MÓDSZERTAN ÉS MIÉRT VAN RÁ SZÜKSÉG?... 5 A PROGRAMOZÁSTÓL
RészletesebbenNév: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
RészletesebbenStatikus 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észletesebben2. 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