Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

A rendszerfejlesztés technológiája Előadásvázlat.

Hasonló előadás


Az előadások a következő témára: "A rendszerfejlesztés technológiája Előadásvázlat."— Előadás másolata:

1 A rendszerfejlesztés technológiája Előadásvázlat

2 A szoftver A szoftver a programok, az adatok és a dokumentációk együttese, nem csak maga a program. Adatok alatt a szoftver vásárlásakor kapott állományokat kell érteni: ilyenek pl. a telepítő és a konfigurációs állományok.

3 A szoftver egy termék bizonyos funckiót szolgáltat (szolgáltatási funkció) határidőre kell előállítani (előállítási határidő) előállításának van költsége (előállítási költség) minőségi elvárásoknak kell megfelelnie (minőségi elvárások)

4 Szerzői jog - szabadalom Automatikusan jár, ingyenes – bejegyzése, fenntartása országonként díjhoz kötött, a szabadalmi per is drága Szerző halála után 70 évig, utána közkincs – 20 évig Szellemi termékekre – találmányokra

5 A szoftverek csoportjai 1. általános célú (dobozos; COTS = Commercial On The Self) szoftvertermékek –bárki megvásárolhatja –általában sok év fejlesztőmunkája van mögötte –általában nagy szoftverek –a szakértelmet és a befektetett energiát kell megfizetni –pl.: az Oracle adatbázis-kezelő rendszere

6 A szoftverek csoportjai 2. Célszoftverek –megrendelésre készülnek –a kifejlesztést kell megfizetni –pl.: a Neptun egységes felsőoktatási tanulmányi rendszer

7 Új módszerek Az információs rendszerek fejlesztéséhez, a szoftvertechnológiához, a szűkebben vett információ oldali részhez a kitalálás óta két új dolog csatlakozott: minőségbiztosítási módszerek a szoftverek kifejlesztéséhez; projektvezetési, -irányítási, -szervezési módszerek a fejlesztést végző emberek munkájának menedzselésére

8 A szoftver, mint termék előállítása tevékenységsorozatban specifikáció: az elvárásokat tárjuk fel, konkretizáljuk, rögzítjük elkészítés/implementáció validáció: az elkészült szoftverről belátjuk, hogy megfelelő szoftverevolúció: az elkészült szoftver módosítása, továbbfejlesztése (nem hibajavítás!)

9 A szoftverfejlesztés rendszerszervezési elemei elemzés (analízis), tervezés, implementáció, követés.

10 Absztrakt megközelítés A szoftverfejlesztési életciklusban egy abszrakt megközelítéstől egy teljesen konkrét megközelítés felé megyünk el valamilyen módon, valamilyen alkalmazott tevékenységsorozat folyamán. A cél ezt a tevékenységsorozatot abba az irányba tolni, hogy minél hamarabb, minél absztraktabb módon megfogalmazott dolgokból tudjuk a konkrét dolgokat automatikusan létrehozni.

11 A folyamat a követelmények meghatározása és elemzése tervezés alrendszerek fejlesztése rendszerintegráció a rendszer telepítése a rendszer működtetése rendszerevolúció a rendszer üzemen kívül helyezése

12 A szoftverfejlesztés folyamatának kiegészülése Minőségbiztosítás és projektmenedzsment Fő célok: határidők meghatározása, melyik lépést mikorra kell végrehajtani; szükséges hardver-, szoftver-, emberi, és anyagi erőforrások biztosítása; az emberek munkájának irányítása, az erőforrások szétosztása, határidők biztosítása stb.

13 A követelmények meghatározása és elemzése funkcionális követelmények: rendszerszolgáltatások, pl.: tantárgyfelvétel, jegybeírás stb. rendszertulajdonságok: a rendszer egészére jellemző dolgok, pl.: rendelkezésre állás, biztonságosság, felhasználói felület lehatárolás: a rendszernek mit nem kell tudnia

14 Tervezés Alrendszerek azonosítása Követelmények alrendszerekhez rendelése Alrendszerek interfészének definiálása Alrendszerek funkcionalitásának meghatározása Követelmények felosztása A tervezés során a követelményektől eljutunk valamilyen módon az alrendszerekig.

15 Alrendszerek fejlesztése Az alrendszerek általában párhuzamosan fejlesztendők, fejleszthetők. Az egyes alrendszereken dolgoznak az egyes fejlesztői csapatok; tervezés után fejlesztik, implementálják, kódolják, majd tesztelik az egyes alrendszereket. Ennek eredményeképpen előállnak az alrendszereink.

16 Rendszerintegráció A kifejlesztett alrendszerekből összeállítjuk a teljes rendszert. Előfordulhat, hogy bizonyos alrendszereket nem fejlesztünk, hanem megvesszük. Bár a rendszerintegrációnál feltesszük, hogy az egyes alrendszerek önmagukban jól működnek, a rendszer összeállítása sok gondot okozhat.

17 A rendszer telepítése Ha a rendszerfejlesztő cég és a megbízó jónak látja az elkészült rendszert, akkor következik a rendszer telepítése. A kifejlesztett rendszert konkrét hardver és szoftver platformra kell telepíteni.

18 A rendszer működtetése A rendszer működtetése során derülnek ki a problémák, amire nem gondolt a felhasználó, működés közben ezeket a problémákat orvosolni kell. Ki tegye mindezt? Ez főnök vagy szerződés kérdése. Nagyon fontos a felhasználók képzése; a felhasználókat el kell látni információval.

19 Rendszerevolúció A rendszert módosítjuk, továbbfejlesztjük a felhasználói környezet, a törvényi szabályozás, a cég méretének stb. megváltozása miatt. Tehát természetes fejlődés megy végbe a szoftvereknél is, amelynek semmi köze nincs a hibákhoz. Tervezéskor figyelembeveendő.

20 A rendszer üzemen kívül helyezése Az információs rendszer általában nem önmagában létezik, hanem további rendszerek környezetében dolgozik: más rendszerektől adatokat fogad, más rendszereknek adatokat szolgáltat. A végiggondolt rendszerevolúció oda vezet, hogy nem a teljes rendszert állítjuk le, csak a rendszernek bizonyos részeit, bizonyos alrendszereket cserélünk le

21 Szabványok tényleges, törvényszintű (de jure) szabványok: szabványügyi szervezetek (ISO, ANSI) dolgozzák ki őket ipari (de facto) szabványok: a szakterület vezető cégei összeállnak és alkotnak valamilyen formációt, konszenzusra jutnak, és ezt nyilvánosságra hozzák. (W3C) piaci szabványok: olyan szakterületeken alakulnak ki, amelyeken van egy nagyon erős piaci cég, őhozzá igazodnak a többiek

22 Folyamatmodellek vízesés modell evolúciós modell formális fejlesztési modell újrafelhasználás-alapú modell iteratív modellek –spirális fejlesztési modell –inkrementális fejlesztési modell

23 Vízesésmodell Az első folyamatmodell, amely a történelemben kialakul, 1970-ben definiálták. Ez más termékelőállítási folyamatmodellből származik. követelmények meghatározása rendszer- és szoftvertervezés implementáció és egységteszt működtetés és karbantartás

24 Vízesésmodell Előnyei: –a legegyszerűbb, a legjobban alkalmazható modell –kicsi és közepes méretű rendszereknél jól struktúrált, jól felépített, jó architekturális jellemzőkkel rendelkező, robusztus rendszer fejleszthető Hátrányai: –Merev, nem flexibilis egymásraépülés. –Minden egyes folyamat teljeskörűen lezárul, mielőtt a következő folyamat elindulna. –A legutolsó lépésben derülnek ki a korai lépések problémái: nem teljesített követelmények, félreértések, stb.

25 Evolúciós modell A 80-as évek elején találták ki, párhuzamos fejlesztési modell, implementációk verzióin keresztül jutunk el a végső verzióhoz: verziósorozatot produkál vázlat leírása specifikáció fejlesztés validálás kezdeti verzió közbülső verziók végleges verzió

26 Evolúciós megközelítések feltáró fejlesztés: a felhasználó és a fejlesztő közösen finomítja a követelményeket eldobható prototípuskészítés:a felhasználó kipróbálja a prototípust, így rájöhet, hogy mit akar.

27 Evolúciós modell Előnyei –Nagyon hamar kap kipróbálható verziók –A felhasználó hamar rájöhet, hogy a követelmények jók vagy nem Hátrányai –A túl sok verzió áttekinthetetlenné válhat –Nem robusztusak: általában rossz struktúráltságú, architektúrájú szoftverhez vezet. –Gyors fejlesztést, rapid techikákat igényel

28 Formális modell A 70-es években alakult ki a vízesés modell egy változataként. követelmények meghatározása formális specifikáció formális transzformáció integráció és rendszerteszt rendszer- validáció A közbenső rész más: a rendszerspecifikációból matematikai eszközökkel formálisan generálunk működő programot. A transzformációs folyamat a formálisan megadott követelményekből előállít egy adott nyelvű kódot.

29 Formális modell Előnye: –automatizált a folyamat; bármilyen rendszer esetén alkalmazható –biztonságkritikus rendszerek esetén alkalmazzák Hátránya: –a rendszerkövetelmények formalizálása kézzel kell, hogy történjen

30 Újrafelhasználás-orientált modell Léteznek olyan komponensek, amelyeket újrafelhasználhatunk (kód, tervezési szinten) követelmények specifikációja komponens- elemzés követelmények módosítása rendszerterv újrafelhasználással fejlesztés és integráció rendszer- validáció

31 Újrafelhasználás-orientált modell Hátrány: kompromisszumok, leromolhat a rendszer struktúrája Előnyök: idő, pénz megtakarítása; a komponensek kipróbáltak, teszteltek stb., így egyfajta biztonságérzetet nyújt, sok validációs lépést megspórolhatunk.

32 Iteratív folyamatmodellek: inkrementális fejlesztési modell A fejlesztés inkremensekben történik, az inkremenseket építünk, inkremensekkel bővítjük, és ha szükséges, nyilván megismételjük az inkremenshez akár a specifikációs tervezés lépését is.

33 Inkrementális modell vázlatos követelmények meghatározása követelmények inkremensekhez rendelése rendszer- architektúra megtervezése rendszer- inkremens fejlesztése inkremens validálása inkremens integrálása rendszer validálása véglege s rendszer a rendszer nem teljes

34 Inkrementális modell Előnyei: –inkremensek kicsik, jól körülhatárolhatók, adott esetben a követelmények egyértelműen specifikálhatók –az inkremensek fejlesztése történhet párhuzamosan –kezdhetjük a legfontosabb inkremensekkel, a felhasználó nagyon hamar kap egy nem eldobható prototípust, –a rendszerfejlesztés kockázata kisebb –a rendszerfejlesztés közben a hibák hamarabb kiderülnek

35 Spirális modell 1. lépés: célok meghatározása 2. lépés: kockázatelemzés, kockázatok felismerése, megszüntetése 3. lépés: fejlesztés és validálás 4. lépés: áttekintés, döntés a folytatásról

36 Spirális modell Előnyei: –foglalkozik a kockázatokkal –sokkal szisztematikusabban foglalkozik a projekttel Hátrányai: –nem a legtriviálisabb modell –nagy rendszereknél javallott

37 KÖVETELMÉNYEK MEGHATÁROZÁSA, ELEMZÉSE A követelmények osztályozása –felhasználói követelmények –rendszerkövetelmények –szoftverterv-specifikáció

38 A követelmények osztályozása funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, bizonyos bekövetkező szituációkra, teljes és ellentmondásmentes nem-funkcionális követelmények szakterületi követelmények

39 A követelmények kiknek szólnak A felhasználói követelményekkel elsősorban a fejlesztői oldali és a megrendelő oldali menedzserek találkoznak. A rendszerkövetelményekkel a rendszerfejlesztők, az informatikusok találkoznak. A szoftverterv specifikáció nyilvánvalóan a szoftver tervezőinek alapvető fontosságú.

40 Követelmények másik felosztása funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, szituációkra, kivételek feltárása nem-funkcionális követelmények: általános, teljes rendszerre vonatkozik szakterületi követelmények

41 Nem funkcionális követelmények nem-funkcionális követelmények termék- követelmények szervezeti követelmények külső követelmények hatékonysági követelmények használhatósági követelmények megbízhatósági követelmények hordozhatósági követelmények telepítési követelmények implementációs követelmények szabány- követelmények együttműködési követelmények etnikai követelmények törvényi követelmények adatvédelmi követelmények biztonsági követelmények teljesítmény követelmények tárterület követelmények

42 A funkcionális és nem- funkcionális követelmények elválasztása ha együtt kezeljük, túl nagy lesz a specifikáció, nem veszünk észre bizonyos követelményeket; validációnál a bonyolultság miatt bizonyos követelmények elsikkadhatnak. ha külön kezeljük, akkor nehéz az ellentmondások felderítése

43 Követelmények dokumentációja természetes nyelv diagramok (UML) leíró nyelvek: programnyelvekhez hasonló matematikai specifikáció hibrid megoldás

44 Rendszermodellek környezeti modellek (HOL) viselkedési modellek (HOGYAN) adatmodellek (MIVEL)

45 Környezeti modellek A rendszer határainak felderítése biztonsági rendszer bankautomata rendszer karbantartó rendszer központi nyilvántartór. központi számlázór. számla- adatbázis Igénybevételi adatbázis

46 Viselkedési modellek adatfolyam modellek: tipikus struktúrált modellek állapotátmenet modellek: tipikusan OO- modellek (adatfolyam modell az OO-ban nincs)

47 Adatfolyam modellek Az adatfolyamok hogyan mozognak, hogyan áramlanak a rendszeren belül, hogyan kerülnek feldolgozásra. Jelölések: ellipszis: feldolgozás, ezek egy-egy függvénynek tekinthető, amely a beérkező adatokból legenerálja a kimenetet és továbbítja. Nyíl: az adatáramlás irányát jelölik, az adatok milyensége a nyilakra van írva. Téglalap: adattárolók; ezek állományok, adatbázisok; itt megőrzésre kerülnek az adatok és újra elővehetők.

48 Adatfolyam modell példája kitöltött megrendelő űrlap megrendelés validálása megrendelés rögzítése továbbítás szállítóhoz költségkeret módosítása megrendelés- állomány költségvetés- állomány megrendelés részletei + üres megrendelő űrlap kitöltött megrendelő űrlapkitöltött megren- delő űrlap aláírt megren- delő űrlap aláírt megren- delő űrlap megrendelés részletezése megrendelés végösszege + számla rögzítése átvizsgált és aláírt megren- delő űrlap

49 Állapotátmenet modell A formális automata, mint absztrakt matematikai eszköz megjelenése a formális rendszerfejlesztésben. Ha túl bonyolult a rendszer, bizonyos állapotokat metaállapotnak tekintve külön állapotátmenet diagramon ki lehet fejteni.

50 Adatmodellek Az adatok struktúráját írják le, az egyedek tulajdonságait, és az egyedek közötti kapcsolatokat modellezik. Ezen modellek vezetnek az objektum modellek kialakulásához a 90-es évek elején. ETK, ER, OO adatmodellek

51 ER adatmodell 3 fő komponense van: –egyed –kapcsolat –tulajdonságok A T

52 Egyed elem az ER-ben Egyed: egy objektum típus, egy a külvilág többi részétől egyértelműen megkülönböztetett dolog önálló léttel bír amikről az információkat tárolni kivánjuk Típusai: normál egyed (önmagában azonosítható): dolgozó, autó gyenge egyed (más egyedhez való kapcsolatán keresztül azonosított): dolgozó felesége, autó lámpája egyed neve normál egyedgyenge egyed

53 Kapcsolat elem az ER-ben opcionális: létezhet olyan egyed- előfordulás, melyhez nem kapcsolódik egyed-előfordulás a kapcsolatban kötelező: minden egyed-előforduláshoz kell kapcsolódnia egyed-előfordulásnak a kapcsolatban opcionális AB kötelező az A oldalon

54 Kapcsolat elem az ER-ben 1:1 A B N:M ország - főváros tulajdonos - autó 1:N egy A-hoz több B színész - színdarab

55 Tulajdonság elem az ER-ben normál: egyértékűember.szülidő kulcs: azonosító szerepűember.TAJszám összetett: több tagból állember.lakcim (irsz,varos) többértékű: több értéke is lehet, ember.hobby származtatott: értéke kiszámítható ember.életkor t normál t kulcs t összetett t t t többértékű t származtatott

56 KÖVETELMÉNYTERVEZÉS Amelynek során előáll a követelmény- dokumentum, és ez szolgál majd a tervezés alapjául dokumentumként. Alfolyamatai: –megvalósíthatósági tanulmány elkészítése –követelmények feltárása, elemzése –követelmények specifikálása és dokumentálása –követelmények validálása

57 Követelménytervezés folyamata megvalósíthatósági tanulmány követelmények feltárása, elemzése követelmények specifikálása követelmények validálása megvalósíthatósági jelentés rendszer- modellek felhasználói és rendszerkövetelmények követelmények dokumentumai

58 Megvalósíthatósági tanulmány / jelentés A rendszer nagyvonalú leírását tartalmazza, ez alapján döntjük el, hogy egyáltalán elindul-e a folyamat. A kifejlesztendő rendszer támogatja-e az adott szervezet általános célkitűzéseit, munkáját, igényeit? Megvalósítható-e a megfogalmazott időkeret, költségkeret és technológiai keretek között? (alternatívák) Integrálható-e, beilleszthető-e a jelenleg használatban lévő rendszerbe?

59 Követelmények feltárása, elemzése szakterület megismerése követelmények összegyűjtése követelmények ellenőrzése követelmények osztályozása fontossági sorrendbe állítás ellentmondások feloldása követelmények specifikációja követelmények dokumentációja a folyamat belépési pontja

60 Követelmények feltárása - problémák Nem tudják, mit várnak a rendszertől (vagy megfogalmazás problémája). Triviális, vagy megoldhatatlan elvárások Kommunikáció a fejlesztővel, ellentmondások feloldása Külső körülmények, pl. vállalati politika

61 Követelmények összegyűjtése prototípus-készítés nézőpont-orientált feltárás forgatókönyv-technika (interakciók) –eseményforgatókönyvek –használati esetek (OO) etnográfia

62 Követelmények ellenőrzése a felhasználók és a fejlesztők együtt végzik, lépései: ellentmondásmentesség a teljes dokumentációra teljességellenőrzés megvalósíthatóság verifikálhatóság

63 Validációs technikák felülvizsgálat prototípuskészítés tesztesetek generálása automatikus validálás (CASE eszközök)

64 Követelmények menedzselése Környezeti változások  követelmény- változások automatizált dokumentációs eszközökkel: –követelmények azonosítása –változtatáskezelés –nyomonkövethetőség

65 Prototípuskészítés, előnyök Eldobható prototípuskészítés Evolúciós prototípuskészítés –folyamatosan felhasználható a felhasználók képzésére –megerősítő tesztek futtatására –a termék hamarabb piacra dobható –felhasználók hamarabb válnak elkötelezetté

66 Prototípuskészítés, hátrányok az emberek cserélődhetnek a cégnél karbantartási problémák (rossz struktúráltság) nehéz jó fejlesztői szerződést kötni a változások miatt

67 TERVEZÉS Architekturális tervezés: szoftverarchitektúra leírást eredményez, a szoftver struktúráját írja le. Tervezéskor implementációs problémákat is figyelembe kell vennünk. Kiindulópontjai az alrendszerek

68 Alrendszerek, modulok Az alrendszer egy olyan létjogosultságokkal rendelkező része a rendszernek, amelynek működése nem függ az egyéb alrendszerek szolgáltatásaitól. Kommunikációjuk interfészeken keresztül történik. A modulok nem önállóak az alrendszeren belül.

69 Architekturális terv – nem funkcionális rendszerkövetelmények Teljesítménykritikus rendszer – kritikus műveletek kevés modulban Védelem – rétegzett architektúra Biztonságosság – biztonságkritikus műveletek egy, vagy kevés helyen Rendelkezésre állás – redundás rendszerelemek Karbantarthatóság – könnyen módosítható, kis modulok

70 Alrendszerek információtárolási modelljei közös, megosztott adatbázis: ugyanazt az információegyüttest használják az alrendszerek minden alrendszernek külön adatbázis (valódi kommunikáció)

71 Megosztott adatbázis jellemzői minden alrendszernek azonos adatmodell (de nehézkes módosítás) Információ kell arról, hogy az adatot ki, hogyan használja fel Egyszerűbb biztonsági problémák, mentés, védelem, konzisztencia

72 Architektúra-modellek kliens-szerver modell (elosztott architektúra), elosztott rendszereknél célszerű rétegezett modell (több rétegből álló struktúra), inkrementális modellhez illeszkedik

73 Vezérlési modell Alrendszerek és modulok együttműködéséhez Központosított: egy kitüntetett alrendszer koordinálja a többit (szekvencális, vagy párhuzamosnál szinkronizált működésű) Eseményvezérelt

74 Eseményvezérelt modellek Eseményszórás: az egyes elemek regisztrálják magukat bizonyos eseményekre. Probléma: nem tudhatja egy alrendszer, hogy hány másik reagál ugyanarra az eseményre. Eseménymegszakítás: operációs rendszer megszakításkezelése alkalmazásszinten

75 Modultervezés struktúrált módszertan: a modulokat egy adatfolyam modell alapján tervezzük meg. OO-szemlélet : az alrendszereket objektumokká bontjuk szét az objektumok tulajdonságaival

76 Szakterületspecifikus architektúrák általános szakterületi architektúra referencia-architektúra

77 A fordítóprogram architektúrája szimbólumtábla lexikális elemzés szemantikai elemzés szintaktikai elemzés kód- generálás

78 Tervezés újrafelhasználással alkalmazkodó újrafelhasználás: implementálás közben fedezzük fel az elemeket és illesztjük be a programba. módszeres újrafelhasználás: a tervezést eleve így képzeljük el

79 Tervezés újrafelhasználással - előnyök Megbízhatóság Alacsony kockázat Szabványos komponensek (pl. GUI) Rövid tervezési, fejlesztési, tesztelési idő

80 Tervezés újrafelhasználással - problémák Meg kell találni őket Megbízhatóság Dokumentáltság Nagyobb karbantartási költség (komponensek evolúciója, megszűnése)

81 Komponens-orientált tervezés A komponens egy önálló, végrehajtható entitás, amely valamilyen szolgáltatást nyújt más komponenseknek vagy más szoftvereknek. A komponensnek minden esetben van egy interfésze, és a vele történő minden interakció ezen az interfészen keresztül megy végbe.

82 A rendszer/komponens interfésze a rendszer szolgáltatásokat vár, keresendő a komponens, ami ezeket nyújtja. komponens rendszer vagy másik komponens

83 A komponensek absztrakciós szintje funkcionális absztrakció lazán összefüggő entitások adatabsztrakció klaszterabsztrakció rendszerabsztrakció

84 A komponens-orientált tervezés folyamata rendszerarchitektúra tervezése komponensek meghatározása újrafelhasználható kom- ponensek megkeresése felderített kompo- nensek egyesítése Tipikusan követő modell, mert ha nem találunk meg minden komponenst, akkor fejleszteni kell.

85 A komponens-orientált tervezés folyamata #2 már a tervezés előtt keressük a komponenseket kompromisszum: követelménymódosítás vázlatos rendszer- követelmények újrafelhasználható kom- ponensek megkeresése követelmények módosítása a felderített komponenseknek megfelelően architekturális terv újrafelhasználható kom- ponensek megkeresése a rendszer megtervezése az újrafelhasz- nálható koponenseknek megfelelően

86 Alkalmazási keretrendszerek infrastruktúra keretrendszerek: pl. a felhasználói felületek legyártásához köztes termék keretrendszerek (middleware): információcsere, pl. Corba alkalmazásszintű keretrendszerek: szakterületi alkalmazások, pl. CMS, ERP

87 Az újrafelhasználásra alkalmas komponens: stabil szakterületi absztrakción alapul bezárást, reprezentációt valósít meg ideális esetben független más komponensektől a komponens kivételei az interfészben, a felhasználó kezelheti

88 Alkalmazáscsalád (product-line) Általában közös és szakterületspecifikus architektúrát valósít meg (architektúra újrafelhasználás) platformspecializáció konfigurációspecializáció funkcionális specializáció

89 Tervezési minta Terv-újrafelhasználási elem, implementációfüggetlen. Pl: az absztrakt adatszerkezet az algoritmusoknál. Leírja a problémát, a megoldását, az újrafelhasználhatóságot.

90 Szolgáltatás-orientált architektúra (SOA) Objektum  Komponens  Szolgáltatás A szolgáltatás egy zárt, független üzleti függvény, amely képes egy vagy több kérés fogadására és egy vagy több válasz generálására egy jól definiált interfészen keresztül. Speciális fajtája a webszolgáltatás.

91 Webszolgáltatás Emeli az absztrakciós szintet, elfedi hogy mi van mögötte, csak interfészen keresztül érjük el, a kommunikáció eszköze az XML XML alkalmazásokat képeznek le programokra, objektumokra, adatbázisokra vagy üzleti függvényekre Az interfész mögött jellemzően adatbázis- kezelő-rendszer van

92 Interakciós technikák RPC (Remote Procedure Call) – online-alapú, szinkron szolgáltatás; egy kérés egyetlen XML dokumentum továbbítását jelenti, ez egyetlen háttérelemre képezendő le, amely azonnal le is fut, mint egy távoli eljáráshívás. dokumentumorientált technika – batch, aszinkron szolgáltatás; az XML dokumentumot nem leképezni kell, hanem feldolgozni a webszolgáltatás a W3C szabványokon alapul

93 A SOA webservices eszközei XML: szöveges dokumentumkódolási szabályok WSDL: szolgáltatásleíró nyelv, leírja az üzenettípusokat, az interfészt SOAP: a webszolgáltatások kommunikációjának protokollja (XML) UDDI: a szolgáltatás közzétételének, megosztásának eszköze

94 Felhasználói felületek tervezése interfész-orientált tervezés: egy prototípusnál a felhasználó hogyan tud kapcsolatba kerülni az alkalmazással Jellemző a GUI, szokásos elemek, skinek, stb. Ergonómiai szempontok: RTM, olvashatóság, színtévesztés, stb.

95 Felhasználói felületek megtervezésének elvei felhasználói jártasság konzisztencia minimális meglepetés elve visszaállíthatóság elve (undo) felhasználói támogatás felhasználói sokféleség elve

96 Felhasználói interakciók közvetlen manipuláció menüpont kiválasztása űrlapkitöltés parancsnyelv emberi nyelvű vezérlés

97 Információmegjelenítés kérdései mit akarunk megjeleníteni? mi a lényeges a felhasználó számára? csak látni akarja, vagy interakcióba lépni is vele? Diszkrét / analóg megjelenítés kérdése

98 A felhasználói felületek ergonómiája Felhasználóbarát felületek (webes megjelenés) –Letöltési idő –Egyszerű, következetes navigáció, átláthatóság (térkép), szemmozgás, stb. –Akadálymentesség –Megfelelő színek, színpárok, kontraszt

99 Ergonómia – felhasználói szokások A felhasználók egy idő után mindent megszoknak.. (pl. Microsoft-Apple) A felhasználó már megszokott egy sémát, akkor elvárja azt az újtól is Amit nem talál meg, az a funkció nem létezik (There is no spoon..)

100 Színek, színhasználat Konzervatív, kevés szín használata (felhasználási területtől függően) Funkcionális használat: kiemeléshez, állapotváltozás jelzéséhez más szín Színek – érzelmi hatások Színhűség, webbiztos színek

101 Felhasználói támogatás Jellemzően szövegesek, ill. illusztráltak Helyzetérzékeny súgó, online súgó Segítség a kezdőknek és a tapasztaltaknak: segítségkérés és informálódás, visszajelzés Informatikai hibaüzenetek elrejtése, becsomagolása Többnyelvűség, honosítás Gráfrendszer, többféle navigáció, belépési pont

102 Felhasználói dokumentáció rendszer- értékelők rendszeradmi- nisztrátorok kezdő felhasználók tapasztalt felhasználók rendszeradmi- nisztrátorok funkcionális leírás telepítési dokumentáció bevezető kézikönyv referencia kézikönyv adminisztráto- rok útmutatója szolgáltatá- sok leírása Hogyan telepítjük a rendszert? kezdeti leírások eszközök leírása működtetés és karbantartás

103 Felhasználói felületek értékelése Tanulhatóság Interakciósebesség Robusztusság Visszaállíthatóság Adaptálhatóság

104 Verifikáció és validáció Verifikáció: megfelel-e a szoftver a specifikációknak, kielégíti-e a követelményeket Validáció: olyan verifikált szoftver, ami a felhasználó igényeit szolgálja, minden lépés után elvégzendő. Módszerek: átvizsgálás, tesztelés

105 Verifikáció és validáció Szoftverátvizsgálás: statikus módszer, általában manuális tevékenység. Szoftvertesztelés: dinamikus módszer, a program futtatása tesztfeladatokkal, majd összehasonlítás az elvárt eredményekkel

106 Tesztelés Hiányosságtesztelés: verifikációs Statisztikai tesztelés: használható validációsra is

107 A tesztelés kideríti A hiányosságokat a szoftverben A teljesítményproblémákat A specifikációtól eltérést Ezt követi a hibák behatárolása, a debuggolás, majd a regressziós tesztelés

108 Szoftvertesztelés tervezése követelmények meghatározása rendszer- specifikáció rendszer- tervezés részletes tervezés szolgáltatás átviteli teszt rendszer- integrációs teszt alrendszer- integrációs teszt modul az egységkó- dolásra és tesztelésre átviteli teszt terve rendszerintegrációs teszt terve alrendszerinteg- rációs teszt terve

109 Átvizsgálás Az átvizsgálás a teljes fejlesztési folyamat minden egyes lépésében alkalmazható. A szoftver átvizsgálása egy szárazteszt, amihez nem kell futtatni a programot. Tehát a forráskód átnézése alapján történő hiányosságtesztelés, verifikáció.

110 Átvizsgálás során felismerhető hibák adatkezelési hibák vezérlési hibák I/O hibák interfész problémák tárkezelési hibák a dinamikus szerkezeteknél kivételkezelés

111 Automatikus statikus tesztelők A program szövege alapján megpróbálják felderíteni a fenti kategóriájú problémákat. Bármilyen nyelvnél tesztelhető: pl. a paraméterek számossága, a formális és aktuális paraméterek típusa, stb. Előnyös az útvonalelemzésnél

112 Modul- és egységteszt A legkisebb tesztelhető programegységek. Az elemek önállóan tesztelhetők. Modul- és egységteszt  Alrendszer- integrációs teszt  Rendszerintegrációs teszt

113 Hiányosságteszt tesztesetek tervezése tesztadatok előkészítése program futtatása tesztadatokkal eredmények összehason- lítása a tesztesetekkkel teszt- esetek teszt- adatok teszt- eredmények teszt- jelentések

114 Kimerítő tesztelés Az összes lehetséges programútvonalat teszteljük. A teszteseteket úgy tervezik, hogy a program minden utasítása legalább egyszer lefusson. Automatizált eszközökkel történhet.

115 Tesztelési technikák 1. funkcionális vagy feketedoboz teszt: csak a viselkedésmódot, az I/O-t teszteljük. 2. struktúrateszt, fehérdoboz vagy üvegdoboz teszt: egységtesztelő módszer, a kód ismeretében tervezzük a teszt útvonalát.

116 Feketedoboz teszt A tervezett tesztesetek alapján legenerálandók az input tesztaadatok A rendszer visszaadja az eredményeket A teszteredmények nem egyező részhalmaza határolja be a hiányosságokat. output teszt- eredmények input teszt- adatok IEIE OEOE rendszer

117 Tesztesetek tervezése A tesztesetek tervezéséhez generálásához egy ekvivalencia-osztályozást alkalmaznak az inputokon és az outputokon, ugyanis az inputadatok általában jól kategorizálhatók. inputok rendszer outputok

118 Struktúrateszt, fehérdoboz vagy üvegdoboz teszt Tipikusan egységtesztelő módszer, használható integrációs tesztelésnél is, ahol felhasználjuk az implementációt is a tesztelésnél. A kódot arra használjuk fel, hogy ennek ismeretében tervezzük meg teszteseteket, generáljunk tesztadatokat. Ha tervezhető, minden utasítás minimum egyszer végrehajtásra kerüljön.

119 Integrációs tesztelés Az elemek együttműködését teszteli. A rendszerspecifikációból indul ki. Jellemzően inkrementális teszteléssel ellenőrzik az összekapcsolt modulok együttműködését.

120 Inkrementális tesztelés A B T1T1 T2T2 T3T3 A B T1T1 T2T2 T3T3 C T4T4 A B T1T1 T2T2 T3T3 C T4T4 D T5T5

121 Integrációs teszt fentről lefelé 1. szint 2. szint 2. szintű csonkok 3. szintű csonkok 2. szint Előnye: már működő rendszert tesztelünk. Probléma: az integrációs teszt adott esetben nagyon nehéz, mivel az outputot a levélkomponensek biztosítják majd.

122 Integrációs teszt lentről felfelé Előnye: itt valóban együttműködést lehet tesztelni. Probléma: a magasabb szintű elemekhez környezetet kell biztosítani, szimulálni. N. szint N–1. szint tesztelési sorozat

123 Interfésztesztelés paraméter interfész: az egyes elemek paraméterekkel kommunikálnak osztott memória interfész: az egyes elemek osztott tárterületen keresztül kommunikálnak funkcionális interfész: az egyik elem egy hívható alprogram, metódus, eljárás, függvény halmaz specifikációját adja üzenetinterfész (szolgáltatás-orientált): az egyes komponensek üzenetekkel szolgáltatásokat hívnak meg

124 Stressztesztelés A rendszerintegráció során összeálló teljes szoftvert szélsőséges körülmények között, nem normális terhelés mellett teszteljük. Eredményeként lehet teljesítményt hangolni.

125 Objektumorientált tesztelés Objektumorientált szoftverek modultesztelésénél osztályokat tesztelünk, az osztálytesztelés pedig elsősorban viselkedésmód-tesztelést jelent. Az osztályok közötti együttműködés, mint nagyobb objektumcsoport-osztályok közötti integrációs teszt, mivel az alrendszer sok osztályból áll.

126 A tesztelés technológiai háttere tesztmenedzserek tesztadat-generátorok előrejelzők, jóslók dinamikus elemzők szimulátorok

127 Minőség kezelése A szoftver egy termék. Az ipari termékeknek van minőségi specifikációjuk. A szoftver viszont egy szellemi termék.

128 Minőség Minőségbiztosítás –termékszabványok –folyamatszabványok Minőségtervezés Minőségellenőrzés

129 Minőségbiztosítás szoftvereknél termékszabvány: hogyan nézzen ki egy dokumentáció, a tesztelés eredményeként előálló jónak mondott szoftverelemekből hogyan lesz tényleges szoftverelem, hogyan kerül be egy szoftverelem a teljes szoftverbe, hogyan nézzen ki egy forráskód. folyamatszabványok: ki gyártja a teszteket, ki végzi a teszteket, ki végzi a felülvizsgálást, ki tervezi a minőséget a folyamat során, milyen tervezési mód, milyen szabvány, hogyan tervezzük, hogyan dokumentáljuk...

130 Minőségi szabványok Az általános, ipari termékekre vonatkozó minőségszabvány: ISO9000 Az ISO as a szoftverminőség szabvány. A cég minőségbiztosításához minősíttetni kell egy auditáló céggel a termék- előállítási folyamatot.


Letölteni ppt "A rendszerfejlesztés technológiája Előadásvázlat."

Hasonló előadás


Google Hirdetések