Szoftvermenedzsment 4. fejezet A szoftverfolyamat
|
|
- Anikó Orbán
- 9 é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
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
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
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
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
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
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.
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
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
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
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
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ő
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ó
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
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
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
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?
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ó
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,
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
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
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
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:
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
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/
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:
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,
Miskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
A tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
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
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
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
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ő:
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
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.
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
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
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
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
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
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ó
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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ű
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ő
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
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
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
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
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,
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ó
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
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ő
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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ó...
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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,
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
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