szofttek Flashcards
1
Q
- 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?
A
Számítógépes programok és a hozzá kapcsolódó dokumentációk (pl. követelmények, tervezési modellek és felhasználói kézikönyvek).
Típusai:
* Általános: felhasználók széles rétege számára fejlesztett és általuk használt szoftver.
* Egyedi: egy megrendelő egyedi igényei szerint készült.
A szoftverfejlesztés általános lépései:
* Specifikáció: mit kell a rendszernek tudnia és mik a fejlesztési kényszerek, kötöttségek.
* Fejlesztés: a szoftver rendszer megalkotása.
* Validáció: ellenőrzés: a szoftver azt csinálja, amit a megrendelő akar?
* Evolúció: A szoftver változó igények szerinti továbbfejlesztése.
2
Q
2.Mik a szoftvergyártás általános modelljei?
A
- Vízesés modell.
- Iteratív fejlesztés.
- Komponens alapú fejlesztés.
3
Q
5.Mik a szoftverfejlesztési módszertanok, mik ezek legfőbb elemei?
A
Olyan strukturált szoftverfejlesztési módszerek, amelyek tartalmaznak rendszermodellező eszközöket, jelölési konvenciót, szabályokat és tervezési ajánlásokat, valamint fejlesztési
útmutatót.
Elemei:
* Modell leírások: a létrehozandó grafikus modellek leírása.
* Szabályok: a rendszermodellekre vonatkozó kényszerek.
* Ajánlások: a helyes tervezési megoldásokra vonatkozó tanácsok.
* Fejlesztési útmutató: a modellfejlesztés során végrehajtandó tevékenységek sorozata.
4
Q
6.Mi az a CASE?
A
Olyan szoftver rendszerek, amelyek a szoftverfejlesztési folyamatot automatikus eszközökkel támogatják.
* Upper-CASE: a fejlesztés korai fázisait támogató eszközök.
* Lower-CASE: a fejlesztés későbbi fázisait támogató eszközök.
5
Q
7.Sorolja fel a jó szoftver 5 ismérvét!
A
szoftver 5 ismérvét!
A felhasználó által megkívánt funkcionalitást és teljesítményt szolgáltatja, jól karbantartható, megbízható, hatékony és befogadható.
6
Q
8.Mik a szoftverkészítés legfőbb kihívásai korunkban?
A
- Heterogenitás: szoftverkészítést heterogén platformokra és végrehajtási környezetekre.
- Határidők: gyorsabb fejlesztés és átadás.
- Bizalom: felhasználók bizalmát megnyerni képes fejlesztési technológia.
7
Q
9.Sorolja fel a szakmai felelősség 4 alapvető problémáját!
A
- Titoktartás
- Felkészültség
- Szellemi tulajdonok
- Technikai visszaélés
8
Q
10.Sorolja fel az IEEE/ACM etikai kódex 8 alapelvét és magyarázza el ezek jelentését!
A
- Közérdek: a szoftvermérnököknek a köz érdekének megfelelően kell cselekedniük.
- Ügyfél és alkalmazó: a szoftvermérnöknek a megrendelő és az alkalmazó érdekében kell eljárnia, a közérdek figyelembevételével.
- Termék: a szoftvermérnöknek biztosítania kell, hogy termékei a lehető legmagasabb szakmai színvonalat érjék el.
- Ítélőképesség: a szoftvermérnökök szakmai ítéleteit önállóan és függetlenül kell meghoznia.
- Menedzsment: a menedzserek és egyéb vezetők kötelessége az etikus szoftverfejlesztés és -karbantartás biztosítása.
- Szakma: a szoftvermérnöknek a szakma jó hírét a köz érdekével öregbítenie kell.
- Munkatársak: a szoftvermérnöknek támogatnia kell munkatársait.
- Önfejlesztés: a szoftvermérnöknek folyamatosan fejlesztenie kell szakmai tudását.
9
Q
11.Mit értünk rendszer alatt?
A
Kapcsolódó komponensek halmaza, amelyek egy közös cél érdekében működnek együtt.
A rendszer tartalmazhat szoftvert, mechanikus és elektronikus hardvert.
A rendszert emberek is üzemeltethetik.
10
Q
12.Mik a technikai rendszerek és az ember-gép rendszerek alapvető tulajdonságai?
A
Technikai rendszerek: hardvert és szoftvert tartalmazó rendszerek. Az operátorokat és a rendszert működtető eljárásokat nem tekintjük a rendszer részének.
Ember-gép rendszerek: olyan rendszerek, amelyek technikai rendszereket is tartalmaznak, csakúgy, mint a rendszert működtető eljárásokat és a technikai rendszerrel kapcsolatot tartó embereket.
Alapvető tulajdonságok:
* Globális/eredő tulajdonságok: a rendszerkomponensektől és azok kapcsolatától függenek.
* Nem determinisztikus viselkedés: azonos bemenőjelre nem mindig azonos kimenőjelet produkálnak.
* Szervezeti céloktól való komplex függés: nem csak a rendszertől függ, hogy az mennyire képes a szervezet céljait szolgálni.
11
Q
13.Mik az eredő tulajdonságok, mik ezek ismérvei? Soroljon föl példákat.
A
Az egész rendszerre vonatkozó tulajdonságok, melyek nem származtathatók a komponensek tulajdonságaiból.
* A globális (eredő) a rendszerkomponensek kapcsolatából adódnak.
* Ezen jellemzők csak akkor mérhetők, ha a komponensek rendszerré történő integrációja megtörtént.
Pl.:
Térfogat: a rendszer teljes térfogata a komponensek összeállításának mikéntjétől függ.
Megbízhatóság: a rendszer megbízhatósága függ a komponensek megbízhatóságától.
Javíthatóság: jellemzi, hogy milyen egyszerű a rendszert javítani, miután a hibát észlelték.
Használhatóság: milyen könnyű a rendszert használni.
12
Q
14.Milyen két alapvető eredő tulajdonság-típust ismerünk? Adjon rájuk példákat is.
A
Funkcionális tulajdonságok: akkor láthatók, ha a rendszer valamennyi eleme egy cél elérése érdekében közösen dolgozik.
Pl.: egy kerékpárnak akkor funkcionális tulajdonsága, hogy közlekedési eszköz, ha azt alkatrészeiből már összeszerelték.
Nem-funkcionális tulajdonságok: ezek a rendszernek a környezetével való kapcsolatát jellemzik. Számítógépes rendszereknél gyakran kritikus tulajdonságok: amennyiben egy minimális szintet nem érik el, a rendszer könnyen instabillá válhat.
Pl.: megbízhatóság, teljesítmény, biztonság.
13
Q
15.Mi befolyásolja a megbízhatóságot?
A
- Hardver megbízhatóság: mennyi a hardver komponens meghibásodási valószínűsége és mennyi ideig tart ennek a komponensnek a javítása?
- Szoftver megbízhatóság: mekkora annak valószínűsége, hogy egy szoftver komponens hibás eredményt produkál?
- Operátor megbízhatósága: mennyire valószínű, hogy a rendszeroperátor hibázik?
14
Q
16.Sorolja fel a rendszerkövetelmények 3 típusát!
A
- Absztrakt funkcionális követelmények: a rendszer funkcióit absztrakt módon definiáljuk.
- Rendszertulajdonságok: az egész rendszerre vonatkozó nem funkcionális követelményeket definiáljuk.
- Nem kívánatos tulajdonságok: nem megengedett viselkedés specifikációja.
15
Q
17.Mik a rendszertervezés alapvető lépései? Ismertesse a rendszertervezés folyamatát!
A
Követelménydefiníció ► Rendszertervezés ► Alrendszerek tervezése ► Rendszerintegráció ► Üzembe helyezés ► Rendszerevolúció ► Rendszer leépítése.
A rendszertervezés folyamata:
* A követelmények csoportosítása: követelményeknek kapcsolódó csoportokra osztása.
* Alrendszerek meghatározása: alrendszerek olyan halmazának meghatározása, amelyek együttesen képesek a rendszerkövetelmények teljesítésére.
* Követelmények hozzárendelése az alrendszerekhez: nehézségbe ütközik, ha COTS rendszereket integrálunk.
* Alrendszerek funkcionalitásának specifikálása.
* Alrendszerek interfészeinek definiálása: fontos párhuzamos alrendszer-fejlesztés esetén.
16
Q
20.Mi a COTS rendszer?
A
Már létező vagy készen vásárolható rendszerek.
17
Q
21.Hogyan történik az alrendszerek fejlesztése?
A
- Általában párhuzamosan zajlik a hardver, szoftver és a kommunikáció fejlesztése.
- Tartalmazhat COTS (Commercial Off-The-Shelf) rendszerek beszerzését is.
- A fejlesztő csoportok között nincs kommunikáció.
- Amennyiben változtatásra van szükség, a lassú és bürokratikus engedélyeztetési eljárások miatt gyakran határidő módosítás is szükséges.
18
Q
22.Mi a rendszerintegráció, hogyan történik?
A
Az a folyamat, amelynek során a hardver, szoftver és személyi állomány együttesen rendszert alkot.
* Célszerű inkrementálisan végezni (egyszerre csak egy alegység integrálása).
* Az alegységek közötti interfész problémák rendszerint ebben a fázisban derülnek ki.
* A rendszerkomponensek koordinálatlan beszállítása gondokat okoz.
19
Q
23.Ismertesse a telepítés során várható főbb problémákat.
A
A rendszert elkészülte után a megrendelőnél üzembe kell helyezni.
Problémák:
* A környezettel kapcsolatos feltételezések esetleg tévesek voltak.
* Az új rendszerrel szemben ellenállást tapasztalhatunk a befogadó oldalon.
* A rendszernek egy ideig esetleg együtt kell létezni más rendszerekkel.
* Fizikai problémák is felléphetnek a telepítés során (pl. kábelezési gondok).
* Az operátorok betanításról gondoskodni kell.
20
Q
24.Mit jelent a rendszerek evolúciója?
A
Nagy rendszerek hosszú élettartamúak. Lépést kell tartani a változó követelményekkel.
Az evolúció költséges!
* A változásokat technikai és üzleti szempontból is elemezni kell.
* Az alrendszerek egymásra hatása miatt nem várt problémák adódhatnak.
* Ritkán ismertek az eredeti tervezési megfontolások.
* A rendszer struktúrája sérül a folyamatos változtatások során.
Legacy rendszer: az a régi rendszer, amelynek fenntartása elengedhetetlen.
21
Q
25.Ismertesse a rendszerfejlesztést befolyásoló főbb emberi és szervezeti tényezőket!
A
Emberi és szervezeti tényezők:
Változások a munkafolyamatban:
* A rendszer bevezetése szükségessé tesz-e változásokat a munkafolyamat során?
Munkahelyek veszélyeztetése:
* Elvesznek-e munkahelyek a rendszer bevezetése miatt, illetve meg kell-e változtatni a jelenlegi munkavégzés módját?
Szervezeti változások:
* Megváltoztatja-e a rendszer a szervezeti egység jelenlegi politikai/hatalmi elrendezését?
22
Q
27.Ismertesse a Legacy rendszerek legfontosabb tulajdonságait, tipikus előfordulási
lehetőségeit.
A
Legacy rendszerek: olyan ember-gép rendszerek, amelyek régi vagy elavult technológiával lettek kifejlesztve.
Üzleti szempontból kritikus fontosságúak és gyakran túl kockázatos ezek felszámolása vagy cseréje.
Pl.:
* Banki könyvelési rendszerek
* Repülési karbantartó rendszerek
A legacy rendszerek korlátozzák az új üzleti eljárások bevezetését.
A vállalati kiadások jelentős részét ezek emésztik fel.
23
Q
28.Melyek a szoftvergyártás alapvető tevékenységei?
A
- Specifikáció
- Tervezés
- Ellenőrzés (validáció)
- Továbbfejlesztés (evolúció)
24
Q
29.Sorolja fel az alapvető szoftvergyártási modelleket!
A
A vízesés (waterfall) modell
Evolúciós fejlesztési modellek
Komponens alapú fejlesztés
A fenti modellek variációja
25
31.Mik a vízesés modell hátrányai? Milyen rendszerek fejlesztése esetén hasznos ez a modell? Milyen rendszerek esetén nem?
A vízesés modell legfőbb hátrányai:
* A gyártás megindulása után nehéz változásokat beépíteni.
* Egy munkafázisnak be kell fejeződni, mielőtt a következő elkezdődhet.
* Nehéz a változó megrendelői igényekhez igazodni, mert a projekt nehezen változtatható részegységekből áll.
Hasznos, ha a követelmények jól ismertek és csak nagyon kis változások lehetségesek a fejlesztés során.
Sajnos csak kevés üzleti rendszernek vannak stabil követelményei.
Főleg nagy rendszerek fejlesztése során használják, ahol a fejlesztés több helyszínen történik.
26
32.Ismertesse az evolúciós fejlesztés alapelveit és 2 fő formáját!
* Kísérletező fejlesztés: cél: a megrendelővel együtt egy kezdeti durva specifikációból a végleges rendszert kialakítani. A biztos követelményekből kiindulva a megrendelő igényei szerint újabb funkciókkal bővíthető a rendszer.
* Eldobható prototípus: cél: a homályos követelmények tisztázása. A legkevésbé kiforrott követelményekből indul, hogy tisztázza a valós igényeket.
27
33.Mik az evolúciós fejlesztés előnyei és hátrányai. Hol alkalmazható jól?
Problémák:
* A fejlesztés nem átlátható
* A rendszerek gyakran rosszul strukturáltak
* Speciális felkészültségre lehet szükség (pl. rapid prototyping nyelvek)
Alkalmazhatóság:
* Kis- és középméretű interaktív rendszerek
* Nagy rendszerek részegységei (pl. felhasználói felület)
* Rövid élettartamú rendszerek.
28
34.Ismertesse a komponens-alapú szoftverfejlesztés alapelveit és menetét!
Szisztematikus újrafelhasználáson alapul.
A rendszereket már létező, vagy készen vásárolható (COTS) rendszerekből integráljuk.
A szoftvergyártás lépései:
Komponens analízis
Követelmények módosítása
Rendszertervezés újrafelhasználással
Fejlesztés és integráció
Egyre szélesebb körben terjed, ahogy a komponens szabványok fejlődnek.
29
36.Miért hasznos megközelítés az iteratív szoftvergyártás? Ismertesse 2 alapvető típusát!
A rendszerkövetelmények MINDEN projekt során változnak, így az iteratív megközelítés (korábban elvégzett munkafázisok átdolgozása) minden nagyobb rendszer fejlesztésének része.
Az iteratív megközelítés valamennyi alapvető módszerhez alkalmazható.
2 kapcsolódó megközelítés:
* Inkrementális teljesítés
* Spirális fejlesztés
30
38.Ismertesse a spirális fejlesztés alapelveit. Mit jelentenek a hurkok és a szektorok?
A gyártási folyamat sokkal inkább egy spirállal jellemezhető, mint tevékenységek
(visszalépéses) sorozataként.
A spirál minden hurka a gyártási folyamat egy fázisát jelképezi.
Nincsenek fix hurkok (pl. specifikáció, vagy tervezés). A hurkokat az igényeknek
megfelelően alakítjuk ki.
A kockázatkezelés explicit módon megjelenik a gyártási folyamatban.
A spirális modell szektorai:
* Célkitűzések megállapítása: az adott fázis céljainak megállapítása.
* Kockázatbecslés és -csökkentés: a kockázati tényezők felmérése, valamint a legfőbb kockázati faktorok várható hatásának csökkentése.
* Fejlesztés és validáció: az általános módszerek közül bármely kiválasztása.
* Tervezés: a projekt áttekintése és a spirál következő fázisának megtervezése.
31
40.Ismertesse a szoftvertervezés lépéseit és folyamatát.
A tervezés lépései:
* Architektúra tervezése
* Absztrakt specifikáció
* Interfészek tervezése
* Komponensek tervezése
* Adatstruktúrák tervezése
* Algoritmusok tervezés
32
42.Mi a szoftver validáció célja és elemei?
A verifikáció és validáció (V & V) célja annak bizonyítása, hogy a rendszer teljesíti a specifikációban foglaltakat és a felhasználó igényeinek megfelelően működik.
Elemei: ellenőrzés, felülvizsgálat és rendszertesztelés.
Rendszertesztelés: a rendszer futtatása olyan tesztadatokkal, amely a specifikáció szerint a valós működés során előfordulhat.
33
44.Mit jelent a szoftver evolúciója? Miért van rá szükség? Mik a legfőbb kiváltó okai?
Ahogy a változó üzleti-gazdasági körülmények miatt a követelmények változnak, a kiszolgáló szoftvernek is változnia és fejlődnie kell.
Bár a fejlesztés és karbantartás között régebben éles határvonal húzódott, ez egyre kevésbé releváns, hiszen egyre kevesebb a teljesen új rendszer (evolúció).
34
45.Ismertesse a Rational Unified Process (RUP) filozófiáját, főbb jellemzőit.
Korszerű tervezési modell, amely az UML, és a hozzá kapcsolódó eljárásokból jött létre.
Általában 3 nézetet használunk:
* Dinamikus nézet: a fázisokat az idő függvényében mutatja.
* Statikus nézet: a gyártási folyamatokat mutatja.
* Gyakorlati nézet: jól bevált gyakorlati útmutató.
A RUP fázisai:
Alapozás: a rendszer számára egy üzleti modell megalkotása.
Kidolgozás: a problématér megértése és a rendszer-architektúra kidolgozása.
Konstrukció: rendszertervezés, programozás és tesztelés.
Átmenet: a rendszer telepítése a működési környezetbe.
35
46.Mik a számítógéppel segített szoftverfejlesztés által nyújtott legfontosabb szolgáltatások? Soroljon fel tipikus eszközöket!
CASE (Computer-aided software engineering) olyan szoftver, amely a szoftverfejlesztés és evolúció folyamatát segíti.
Tevékenységek automatizálása:
* Grafikus szerkesztők rendszermodellek fejlesztésére.
* Adatkönyvtár tervezési entitások menedzselésére.
* Grafikus felhasználói felületszerkesztő.
* Debuggerek hibakereséshez.
* Automatikus transzlátorok új programverziók generálásához.
36
47.Mik a CASE eszközök integrációjának alapvető típusai?
Eszköz (tool): elemi műveletek támogatására szolgál.
Munkapad (workbench): egy gyártási fázist támogat. Általában néhány integrált eszközt tartalmaz.
Környezet (environment): az egész szoftvergyártási folyamat minden lényeges elemét tartalmazza. Általában számos integrált munkapadot tartalmaz.
37
48.Mi a szoftver-projekt menedzsment célja?
Biztosítja, hogy a szoftvert időben és a megadott ütemterv szerint szállítsák, a megrendelő és a fejlesztő szervezetek által állított követelmények betartásával.
38
49.Miért különleges a szoftvermenedzsment más menedzsment tevékenységekhez
képest?
A termék nem materiális.
A termék különlegesen flexibilis.
A szoftvermérnökség nem rendelkezik más mérnöki tudományokhoz hasonló szilárd alapokkal (pl. gépész-, villamosmérnök).
A szoftverfejlesztési eljárás nem szabványosított.
Sok szoftver projekt unikális.
39
50.Mik a menedzser fő tevékenységei?
Pályázatok írása.
Projekttervezés és ütemezés.
Költségtervezés.
Projekt felügyelet és ellenőrzés.
Személyzet kiválasztása és értékelése.
Beszámolók írása és prezentációja.
40
51.Mi a projekttervezés?
Valószínűleg a legidőigényesebb projektmenedzsment tevékenység.
Állandó tevékenység a kezdeti koncepciótól a rendszer átadásáig. A terveket állandóan felül kell vizsgálni amint újabb információ áll rendelkezésre.
Több különböző típusú terv készül egy szoftverprojekt során, amelyek az ütemezéssel és a pénzügyekkel foglalkoznak.
41
52.Sorolja fel a projekttervek főbb típusait és röviden ismertesse ezeket!
Minőségbiztosítási terv: a projekt során használatos minőségbiztosítási eljárások és szabványok leírása.
Validációs terv: a rendszervalidáció során használt megközelítés, a felhasznált erőforrások és ütemterv leírása.
Konfigurációs és menedzsment terv: konfiguráció menedzsment eljárások és az alkalmazott struktúrák leírása.
Karbantartási terv: a rendszer karbantartási követelményeit becsli (karbantartási költség és egyéb ráfordítás).
Továbbképzési terv: A projekten dolgozók szakmai felkészültségének és tapasztalatának fejlesztési terve.
42
53.Ismertesse a projekttervezés folyamatát (pl. pszeudo-kóddal)!
A projektet érintő kényszerek és megszorítások definiálása.
A projekt paraméterek kezdeti becslése.
A projekt határidők és teljesítések definiálása
while a projekt nem kész és nem ment csődbe loop
Projekt ütemterv felvázolása
Az ütemterv szerinti tevékenységek indítása
Wait ( egy ideig )
A projekt előmenetelének felülvizsgálata
A projekt becsül paramétereinek felülvizsgálata
Projekt ütemterv frissítése
A kényszerek és teljesítések újratárgyalása
if ( probléma adódik ) then
Technikai felülvizsgálat, esetleg revízió kezdeményezése
end if
end loop
43
54.Mi a projektterv feladata, milyen főbb információkat tartalmaz?
Ismertesse a projektterv tipikus felépítését.
A projektterv tartalmazza:
* A projekt számára elérhető erőforrásokat.
* A munka felosztását.
* A munka ütemtervét.
A projektterv felépítése:
* Bevezetés.
* A projekt felépítése.
* Kockázatelemzés.
* Hardver és szoftver erőforrás igények.
* A munka felosztása.
* A projekt ütemterve.
* Felügyeleti és beszámolási mechanizmusok.
44
55.Ismertesse a határidők (mérföldkövek) és teljesítések definícióját!
Határidő (mérföldkő): egy tevékenységi szakasz lezáró pontja.
Teljesítés: a megrendelőnek leszállított és átadott eredmény.
45
57.Mi a kockázatkezelés feladata? Mi a kockázat? Mi a szoftver-kockázatok három alapvető fajtája? Soroljon fel példákat az egyes kockázatokra!
Kockázatkezelés: a kockázatok felmérésével és azok projektre gyakorolt hatásának minimalizálásának tervezésével foglalkozik.
Kockázat: annak a valószínűsége, hogy egy kellemetlen körülmény bekövetkezik.
* Projektkockázatok: a határidőket és az erőforrásokat befolyásolják.
* Termékkockázatok: a fejlesztett szoftver minőségét és teljesítményét befolyásolják.
* Üzleti kockázatok: a beszerző, illetve fejlesztő céget befolyásolják.
46
58.Ismertesse a kockázatkezelés menetét, annak 4 fő lépését!
Kockázatok azonosítása: a projekt-, termék-, és üzleti kockázatok azonosítása.
Kockázat analízis: a fenti kockázati tényezők valószínűségének becslése.
Kockázattervezés: a kockázatok hatásának minimalizálása érdekében tervek felvázolása.
Kockázatfigyelés: a kockázatok figyelése a projekt teljes időtartama alatt.
47
59.Mi a kockázat-azonosítás során azonosított fő (6) kockázat-típus?
Technológiai kockázatok.
Személyi kockázatok.
Szervezeti kockázatok.
Eszköz kockázatok.
Követelmény kockázatok.
Becslési kockázatok.
48
60.Mi a kockázatanalízis feladata és menete?
Minden kockázati tényező valószínűségének és komolyságának felmérése.
Valószínűség lehet: nagyon alacsony, alacsony, közepes, magas, nagyon magas.
Hatás lehet katasztrofális, komoly, elviselhető, jelentéktelen.
49
61.Mi a kockázattervezés feladata és főbb statégiái?
Minden kockázati tényező kezelésére stratégia kidolgozása.
Elkerülési stratégiák: a kockázati esemény bekövetkezési valószínűségét csökkentjük.
Minimalizáló stratégiák: a kockázati tényező hatását a projektre vagy a termékre csökkentjük.
Vészterv: ha a kockázati esemény bekövetkezik, a vészterv kezeli.
50
62.Mi a kockázatfigyelés feladata és menete?
Időközönként minden kockázati tényező vizsgálata:
* Valószínűsége nő vagy csökken?
* A kockázati tényező hatása változott?
A menedzsment projektmegbeszélésein az összes kockázati tényező megvitatása.
51
63.Mi a követelménytervezés, mik a követelmények?
Követelménytervezés: A felhasználói igények és a rendszer működési feltételek feltárásának folyamata.
Követelmények: a rendszerről a követelménytervezés folyamata során leírt szolgáltatások és feltételek/kényszerek halmaza.
52
64.Mi a követelmény? Két fő típusa.
Követelmények: a rendszerről a követelménytervezés folyamata során leírt szolgáltatások és feltételek/kényszerek halmaza.
Típusai:
* Felhasználói követelmények
* Rendszerkövetelmények
53
65.Mik a felhasználói követelmények és a rendszer követelmények?
Felhasználói követelmények: a rendszer szolgáltatásairól és a működési feltételekről szóló természetes nyelven írt állítások és diagramok. Az ügyfél számára készül.
Rendszerkövetelmények: strukturált dokumentum, amely tartalmazza a rendszer funkcióinak, szolgáltatásainak és működési feltételeinek részletes leírását. Definiálja az implementálandó feladatokat, így a megrendelő és a szállító közti szerződés része lehet.
54
66.Mik a funkcionális, nem funkcionális és környezeti (domain) követelmények?
Funkcionális követelmények: milyen szolgáltatásokat kell a rendszernek nyújtania, hogyan kell bizonyos bemeneti adatokra reagálnia és hogyan kell viselkednie egyes helyzetekben.
Nem funkcionális követelmények: a rendszer szolgáltatásaira és funkcióira vonatkozó feltételek és kényszerek.
Környezeti (domain) követelmények: olyan követelmények, amelyek a felhasználói környezetből erednek és ennek a környezetnek a sajátságait tükrözik.
55
67.Mik a funkcionális követelmények fő jellemzői és fajtái?
Milyen elvárásaink vannak a funkcionális követelményekkel szemben?
Leírja a rendszer szolgáltatásait.
Függ a szoftver típusától, a várható felhasználói körtől és attól, hogy hol fogják a szoftvert használni.
A funkcionális felhasználói követelmények magas szintű állítások is lehetnek a rendszer elvárt viselkedéséről, de a funkcionális rendszerkövetelményeknek a szolgáltatások részletes leírását kell tartalmaznia.
56
68.Mik a nem funkcionális követelmények fő jellemzői és típusai?
A rendszer-követelményeket és a működési feltételeket, kényszereket definiálják.
Pl.: megbízhatóság, válaszidő, tárolásra vonatkozó követelmények. Kényszerek lehetnek pl. az I/O eszközök adottságai, adatformátumok, stb.
Fejlesztésre vonatkozó követelményeket is meg lehet fogalmazni: Pl. egy adott CASE eszköz, programozási nyelv, vagy fejlesztési módszer használata.
A nem funkcionális követelmények sokszor kritikusabbak, mint a funkcionális követelmények. Ha ezek nem teljesülnek, a rendszer használhatatlan.
A nem funkcionális követelmények típusai:
Termék követelmények: olyan követelmények, amelyek meghatározzák a termék viselkedési módját.
Szervezeti követelmények: a szervezet stratégiájából és működési módjából következő követelmények.
Külső követelmények: a rendszer és a fejlesztési eljárás szempontjából külső tényezők hatására fellépő követelmények.
57
69.Mit jelent a nem funkcionális követelmények ellenőrizhetősége?
Miért nehéz probléma ez? Adjon példát lehetséges mértékekre!
A nem funkcionális követelményeket nehéz precízen megfogalmazni, a nem precíz követelményeket pedig nehéz ellenőrizni.
Cél: a felhasználó általános és átfogó szándéka. Pl. könnyű használhatóság.
Ellenőrizhető nem funkcionális követelmény: olyan követelmény, amely objektíven mérhető mértéket tartalmaz.
Követelmények mértékei lehetnek:
Sebesség: másodpercenkénti tranzakciók száma, válaszidő, képernyő-frissítési idő.
Méret: megabájt, ROM lapkák száma.
Könnyű felhasználhatóság: betanítás idő, Súgó lapok száma.
Megbízhatóság: Meghibásodások közötti átlagos idő (mean time to failure, MTF), leállás valószínűsége, hibagyakoriság, rendelkezésre állás.
Robusztusság: újraindítási idő hiba után, események hány százaléka okoz hibát, adatvesztés valószínűsége hiba esetén.
Hordozhatóság: a platformfüggő utasítások aránya, támogatott platformok száma.
58
70.Mit jelent a követelmények egymásra hatása?
Adjon példát nem funkcionális követelmények közötti konfliktusokra!
Komplex rendszerekben gyakori a különböző nem funkcionális követelmények közötti konfliktus.
Példa: repülőgép irányítási rendszere:
* A minél kisebb súly elérése érdekében a rendszerben használt lapkák számát minimalizálni kell.
* A teljesítmény-felvétel csökkentése érdekében alacsony fogyasztású lapkákat kell használni.
* Az alacsony fogyasztású lapkákból több (darab) kell. Melyik a fontosabb követelmény?
59
71.Mik a környezeti (domain) követelmények, főbb típusai, azonosításuk problémái?
Az alkalmazás környezetéből származtatható. A környezetből adódó rendszertulajdonságokat írja le.
Lehetnek új funkcionális követelmények, létező követelményekhez újabb kényszerek, vagy specifikus számításokat definiálhatnak.
Ha a környezeti követelményeket nem elégíti ki a rendszer, akkor teljesen használhatatlan lehet.
60
72.Hogyan történik a felhasználói követelmények megfogalmazása?
Milyen problémákat vet fel a természetes nyelvek használata?
Funkcionális és nem funkcionális követelményeket fogalmaz meg oly módon, hogy az a rendszer (mélyebb technikai ismeretekkel nem rendelkező) felhasználói is megértsék.
A felhasználói követelményeket természetes nyelven, valamint táblázatok és ábrák segítségével, a felhasználók számára érthető módon kell megfogalmazni.
A természetes nyelvek problémái:
Nem világos: nehéz precíznek lenni úgy, hogy a dokumentum ne váljon nehezen olvashatóvá.
Követelmények keveredése: funkcionális és nem funkcionális követelmények könnyen keveredhetnek.
Követelmények összeolvadása: különböző követelmények együtt fogalmazódnak meg.
61
73.Hogyan írjuk le a felhasználói követelményeket?
Legyen egy állandó formátumunk a követelmények számára.
Használjuk a kifejezéseket következetesen.
Pl. „kell" a szükséges, a „javallott" a kívánatos követelmények jelzésére.
Használjunk szövegkiemeléseket a követelmény fontos részeinek jelzésére.
Ne használjunk számítógépes zsargont.
62
74. Hogyan történik a rendszerkövetelmények leírása?
A természetes nyelvi specifikáció problémái, ennek alternatívái.
A rendszer funkcióinak, szolgáltatásainak és működési feltételeinek a felhasználói követelményeknél részletesebb leírása.
Ez lesz a rendszertervezés alapja.
A szerződés része lehet.
A rendszerkövetelményeket definiálhatjuk vagy illusztrálhatjuk különféle rendszermodellekkel.
A természetes nyelvi specifikáció problémái:
Többértelműség: a követelmények írói és olvasói ugyanazt kell értsék a szavakon.
Túlságos flexibilitás: ugyanazt a dolgot sokféleképpen lehet elmondani.
A modularizálhatóság hiánya: a természetes nyelvi struktúrák nem alkalmasak a rendszerkövetelmények strukturálására.
A természetes nyelvi specifikáció alternatívái:
Strukturált természetes nyelv: a specifikáció leírására standard formátumok és sablonok használata.
Terv-leíró nyelvek: a specifikációt a rendszer egy működési modelljének segítségével adja meg, egy programnyelv szerű, de absztraktabb nyelv segítségével.
Grafikus jelölések: a rendszer funkcionális követelményeit egy szöveges megjegyzésekkel bővített grafikus nyelv segítségével írja el. Korai példa: SADT.
Manapság a use-case leírások és a sorrend (sequence) diagramok használatosak.
Matematikai specifikáció: matematikai elveken (pl. véges állapotú automaták, halmazok) alapuló leírási módok.
63
75. Mik a strukturált nyelvi specifikációk? Form-alapú és táblázatos módszerek.
* A követelmény-író szabadságát előre definiált követelmény-sablonok korlátozzák.
* Minden követelményt egy standard módon írunk meg.
* A leírásban használható terminológia korlátozva lehet.
* Előny: a természetes nyelv kifejező ereje megmarad, de mégis egy egységes forma alakítható ki.
Űrlap (form)-alapú módszer:
* A funkció vagy entitás definíciója.
* A bementek leírása + honnak erednek.
* A kimenetek leírása + hová mennek.
* Más felhasznált entitások felsorolása.
* Elő- és utófeltételek (pre-, post-condition).
* Mellékhatások leírása.
Táblázatos módszer:
* Természetes nyelvek kiegészítésére.
* Különösen hasznos, amikor alternatív végrehajtási módokat definiálunk.
64
76.Milyen a grafikus modellek alkalmazhatók funkcionális követelmények leírására?
A grafikus modellek akkor hasznosak, amikor állapotok változását, vagy tevékenységek sorozatát kell leírni.
Szekvencia diagramok:
* Események sorozatát mutatja a rendszerben valamely felhasználói interakció során.
* Felülről lefelé olvasandó.
65
77.Mi az interfész specifikáció feladata, milyen interfész-típusokat használunk?
A legtöbb rendszernek más rendszerekkel együtt kell működnie és az interfészeket a követelmények részeként specifikálni kell.
Interfész típusok:
* Procedurális interfészek
* Adatstruktúrák
* Adatreprezentációk
66
78.Mi a követelmény-dokumentum, mit tartalmaz? Kik számára készül?
Milyen struktúrát ajánl a dokumentum számára az IEEE szabvány?
Követelmény-dokumentum: egy hivatalos dokumentum, amely tartalmazza, hogy mit várunk a rendszer fejlesztőitől.
Tartalmazza a felhasználó követelményeket és a rendszerkövetelmények specifikációját.
Ez nem terv. Amennyire lehetséges, azt tartalmazza, hogy a rendszernek MIT kell csinálni, nem pedig azt, hogy HOGYAN.
Felhasználói:
* Megrendelő, Menedzserek, Rendszertervezők, Tesztmérnökök, Üzemeltetők és karbantartók.
IEEE szabvány struktúrajavaslata:
* Bevezetés.
* Általános leírás.
* Az egyes követelmények leírása.
* Függelékek.
* Index.
67
80.Mi a megvalósíthatósági tanulmány, mi a célja, főbb tulajdonságai?
A megvalósíthatósági tanulmány dönti el, hogy érdemes-e a rendszert fejleszteni.
Rövid, célirányos tanulmány arról, hogy:
* hozzájárul-e a rendszer a szervezet célkitűzéseinek eléréséhez.
* a rendszer a jelenlegi technológiával és pénzügyi kerettel megvalósítható-e.
* a rendszer integrálható-e a jelenleg használatos többi rendszerrel.
Információ gyűjtés, értékelés, jelentés írása.
68
81.Hogyan történik a követelménytervezés során az információgyűjtés és -analízis?
Mik a fő nehézségek?
Követelmény-becslésnek vagy -feltárásnak is hívjuk.
A műszaki szakemberek a megrendelővel az alkalmazási környezet, a kívánt rendszerszolgáltatások és a működési feltételek feltárásán dolgoznak.
A követelményanalízis problémái:
* A részvényesek nem tudják, valójában mit szeretnének.
* A részvényesek követelményeiket saját nyelvezetükön fogalmazzák meg.
* Különböző részvényeseknek ellentmondó követelményei lehetnek.
* A rendszerkövetelményeket szervezeti és politikai tényezők is befolyásolhatják.
* A követelmények változnak az analízis során: új részvényesek bukkanhatnak fel, illetve az üzleti környezet is változhat.
69
83.Ismertesse a követelmények feltárásának célját és módszereit!
Kiket nevezünk részvényeseknek?
Cél: információgyűjtés a javasolt és a jelenlegi rendszerről, majd ebből a felhasználói- és rendszerkövetelmények leszűrése.
Információforrások lehetnek:
* dokumentáció
* részvényesek
* hasonló rendszerek specifikációi.
Részvényesek: az információgyűjtés és -analízisben a végfelhasználók, menedzserek, stb.
70
84.Mik a nézőpontok, típusok és szerepük a követelménytervezésben?
Nézőpontok: lehetőséget adnak a a követelmények strukturálására, a különböző részvényesek szempontjainak reprezentálására.
A részvényesek különböző nézőpontokba sorolhatók.
Fontos a több szempontból történő elemzés.
Nincs egyetlen helyes módja a rendszerkövetelmények analízisének.
A nézőpontok típusai:
* Interaktív nézőpontok: emberek, vagy más rendszerek, amelyek kölcsönhatásban vannak a rendszerrel.
* Indirekt nézőpontok: olyan részvényesek, akik nem használják a rendszert, de a követelményeket befolyásolják.
* Alkalmazási környezet (domain) nézőpontok: alkalmazási környezet jellemzői és kényszerei, amelyek befolyásolják a követelményeket.
71
85.Mik az interjúk, ezek típusai és a hatékony interjúkészítés feltételei?
Formális vagy informális interjúk keretében a részvényeseknek kérdéseket teszünk fel a rendszerről, amit használnak, és a rendszerről, amit fejlesztünk.
Az interjúk típusai:
* Zárt: egy előre meghatározott kérdés-csoportra kell válaszolni.
* Nyílt: nincs előre meghatározott menetrend, a megválaszolandó problémákat a részvényesekkel együtt tárjuk fel.
A hatékony interjú feltételei:
* Az interjú készítője legyen elfogulatlan, figyeljen a részvényesekre és ne legyenek prekoncepciói a követelményekről.
* Legyenek felteendő kérdések vagy javaslatok a meginterjúvoltak számára, ne várjuk, hogy hasznos információt adnak a „mit szeretne" kérdésre.
72
86.Mik a szcenáriók (forgatókönyvek), mit tartalmaznak?
Szcenáriók (forgatókönyvek): valós életből vett példák arról, hogy hogyan kell a rendszert használni.
Tartalmazniuk kell:
* A kiinduló szituáció leírását.
* Az események normál menetének leírását.
* Annak leírását, hogy mi sikerülhet rosszul, kivéte.
* Információt már párhuzamos tevékenységekről.
* A szcenárió befejezése utáni állapot leírását.
73
87.Mik az esettanulmányok (use cases), mit tartalmaznak? A részletesebb kiegészítő információk közlésének lehetséges módszere: szekvencia-diagram.
Szcenárió-alapú technika, az UML része.
Azonosítja az interakcióban részt vevő aktorokat és leírja magát az interakciót is.
Esettanulmányokkal valamennyi lehetséges, a rendszerrel kapcsolatos interakciót le kell írni.
Szekvencia-diagramok: részletes információkat csatolhatnak az esettanulmányhoz.
Bemutatják az események kezelésének sorrendjét a rendszerben.
74
88.Mi az etnográfia célja, szerepe? A célzott etnográfia.
Etnográfia: társadalomkutatók foglalkoznak emberek munka közbeni megfigyelésével és ennek analízisével.
Célja:
* A dolgozóknak így nem kell szóban elmagyarázni a munkájukat.
* Fontos társadalmi és szervezeti tényezőkre derülhet így fény.
* Etnográfiai kutatások szerint a munkafolyamatok általában sokkal gazdagabbak és bonyolultabbak annál, mint azt az egyszerű rendszermodellek mutatják.
Célzott etnográfia:
* Légiirányítók munkáját tanulmányozó projektből ered.
* Kombinálja az etnográfiát a prototípus-készítéssel.
* A prototípus-készítés rávilágít a megválaszolatlan kérdésekre és fókuszálja az etnográfiai kutatást.
* Gond az etnográfiával: a jelen gyakorlatot vizsgálja, ami valamilyen, esetleg már nem is releváns történelmi alapokon nyugszik.
75
89.Mi a követelmény-validáció célja?
Célja: annak igazolása, hogy a követelmények azt tartalmazzák, amit a megrendelő valóban akar.
76
90.Milyen szempontok szerint kell a követelményeket ellenőrizni?
* Érvényesség: a rendszer a megrendelő igényeit legjobban kielégítő szolgáltatásokat nyújtja?
* Konzisztencia: vannak a követelmények között ellentmondások, konfliktusok?
* Teljesség: a megrendelő számára minden szükséges funkció rendelkezésre áll?
* Realitás: a jelenlegi technológiával és költségvetéssel implementálható a rendszer?
* Verifikálhatóság: ellenőrizhetők a követelmények?
77
91.Milyen technikák alkalmazhatók a követelmények ellenőrzésére?
* Követelményszemle: a követelmények szisztematikus kézi ellenőrzése.
* Prototípus készítése: a rendszer végrehajtható modelljének segítségével ellenőrizzük a követelményeket.
* Tesztek készítése: tesztelhetőség ellenőrzése követelmény-tesztek kidolgozásával.
78
92.Ismertese a követelményszemlék menetét és a fő ellenőrző pontokat!
* Verifikálhatóság: a követelmény reálisan tesztelhető?
* Érthetőség: mindenki helyesen érti a követelményeket?
* Követhetőség: a követelmény eredete világosan meg van fogalmazva?
* Változtathatóság: a követelmény megváltoztatható-e más követelményekre gyakorolt nagyobb hatás nélkül?
79
93.Mi a követelmény menedzsment szerepe? Miért van rá szükség?
A változó követelmények kezelésének folyamata a követelménytervezés és a rendszer fejlesztése során.
A követelmények nem teljesek és nem konzisztensek:
* Új követelmények bukkannak elő, ahogy az üzleti érdekek változnak, vagy a rendszerről egyre teljesebb tudásanyag áll elő.
* Különféle nézőpontoknak más és más követelményei vannak, ezek gyakran egymásnak ellentmondanak.
80
94.Milyen terveket kell készíteni a követelmények menedzsmentje során?
* Követelmények azonosítása: hogyan lesznek az egyes követelmények azonosítva.
* Változáskövetési eljárás: ezt az eljárást kell követni követelményváltozás elemzése során.
* Követési stratégiák: milyen és mennyi információt kell tárolni a követelmények közötti összefüggésekről.
* CASE eszköz: milyen CASE segítség kell a követelményváltozások menedzseléséhez.
81
95.Milyen információkat kell tárolni a változások követhetősége céljából?
Forrás követés: a követelményeket azokhoz a részvényesekhez köti, akiktől a javaslat származik.
Követelmény követés: egymástól függő követelmények közötti kapcsolatot kezeli.
Tervezés követés: kapcsolatok a követelmények és a terv elemei között.
82
96.Mik a követelmény-változás menedzsment fő lépései?
* Probléma-analízis: a követelményekkel kapcsolatos problémák megvitatása és javaslat a változtatásra.
* Változás-analízis és költségbecslés: a változtatás hatásának becslése más követelményekre.
* Változtatás végrehajtása: a követelmény-dokumentum és más kapcsolódó dokumentumok megváltoztatása.
83
97.Mi a rendszermodellezés célja? Főbb modell-típusok.
Célja: a rendszer modellezése egyrészt segíti a rendszerelemzőt a rendszer funkcionalitásának megértésében, másrészt modellek segítségével a megrendelővel is lehet kommunikálni.
Modell-típusok:
* Adatfeldolgozás modell: az adat feldolgozásának lépései különböző szinteken.
* Kompozíció (aggregáció) modell: egyes entitások hogyan épülnek fel más entitásokból.
* Architektúrális modell: a legfontosabb alrendszereket mutatja be.
* Osztály-modell: Az entitások közös jellemzőit mutatja be.
* Gerjesztés/válasz modell: a rendszernek különféle eseményekre adott reakcióit mutatja.
84
98.Mi a kontextus modell, mi a szerepe?
Milyen modell-típusokat használhatunk erre a célra?
A kontextus modellek a rendszer működési környezetét mutatják be.
Szerepe: architektúrális modellekkel a rendszert és annak más rendszerekkel való kapcsolatát mutatjuk be.
Modell-típusok:
* Folyamat modellek
* Viselkedési modellek
85
99.Mit tartalmaznak a folyamat modellek?
Folyamat modellek: a teljes folyamatot, és ezen belül a rendszer által támogatott folyamatokat írják le.
Az adatfolyam modellek a folyamatokat és a folyamatok közötti információ-áramlást mutatják.
86
100.Mire szolgálnak a viselkedési modellek, milyen típusai vannak?
A viselkedései modellek a rendszer viselkedését írják le.
Típusai:
* Adatfeldolgozó modellek: az adatok feldolgozásának leírása a rendszeren való áthaladásuk során.
* Állapotgép modellek: a rendszer eseményekre való válaszát írják le.
87
101.Milyen az adatfeldolgozó modellek felépítés, felhasználási területei?
Adatfolyam-diagramok jól használhatók a rendszer adatfeldolgozó funkcióinak leírásához.
A feldolgozás lépéseit mutatják, ahogy az adat áthalad a rendszeren.
Az adatfolyam-diagramok számos analízis módszer lényeges részét alkotják.
Egyszerű és intuitív jelölés, a megrendelő is megérti.
Az adat feldolgozását mutatja a bementettől a kimenetig.
Használhatók még a rendszer és annak környezetében lévő más rendszerek közötti adatcsere bemutatására.
88
102.Mire szolgálnak az állapotgép modellek?
A rendszer viselkedését modellezik annak különböző külső és belső eseményekre adott válaszain keresztül.
Állapotgépek: a rendszer állapotai a csomópontok, köztük futó irányított élek pedig az események. Egy esemény bekövetkezésekor a rendszer egyik állapotból a másikba megy át.
Az állapot-diagramok (statechart) az UML fontos részét alkotják.
Ezzel állapotgépeket írhatunk le.
89
103.Ismertesse az állapot-diagramok felépítését, elemeit és szabályait!
A modellnek kisebb részekre, al-modellekre bontását teszi lehetővé (dekompozíció).
Az akciók rövid leírása az egyes állapotokban a 'do' utasítás után található.
Kiegészíthető az állapotok és a gerjesztések leírását tartalmazó táblázatokkal.
90
104.Mire szolgálnak a szemantikus adatmodellek?
Mik az entitás-reláció-attribútum diagramok?
A rendszer által feldolgozott adatok logikai struktúráját írja le.
Entitás-Reláció-Attribútum diagram: a rendszerben használt entitásokat, az ezek közötti relációkat és az entitások attribútumait mutatja be.
Adatbázisok modellezésénél széles körben használt.
Az UML nem nyújt specifikus jelölésrendszert, de az objektumok és az asszociációk használhatók e célra.
91
105.Mik az adat-szótárak? Előnyei?
Adat-szótár: a rendszer-modellekben használt valamennyi név listája.
Az entitások, kapcsolatok és attribútumok leírását is tartalmazza.
Előnyei:
* Támogatja a név-menedzsmentet és segít az ütközések elkerülésében.
* Fontos szervezési tudástár: összeköti az elemzés, tervezés és implementáció során összegyűlt információkat.
Sok CASE munkapad támogatja az adat-szótárak kezelését.
92
106.Mik az objektum modellek? Lehetséges fajtái?
Objektum modellek: a rendszert az objektum-osztályok és ezek kapcsolatán keresztül mutatják be.
Egy objektumosztály egy olyan objektumhalmaz absztrakciója, amelynek elemeinek közös attribútumai és szolgáltatásai (operációi) vannak.
Lehetséges fajtái:
* Öröklési modellek
* Aggregáció modellek
* Interakció modellek
93
107.Ismertesse az öröklési modellek célját, felépítését, UML-beli reprezentációját!
Egyszeres és többszörös öröklés.
Célja: az objektum-osztályok hierarchiába szervezésére.
Felépítése: a hierarchia csúcsán lévő osztályok az összes osztály közös tulajdonságait reprezentálják. Az objektum-osztályok az attribútumaikat és szolgáltatásaikat egy vagy több szuper-osztálytól öröklik.
UML-jelölések:
* Az objektum-osztályokat téglalapok jelképezik, amelyben a név felül, a tulajdonságok középen, az operációk pedig az alsó részben helyezkednek el.
* Az objektumok közti relációkat (asszociációkat) az objektumokat összekötő vonalak jelképezik.
* Az öröklést itt általánosításnak nevezik és a hierarchiában nem „lefelé", hanem „felfelé" olvasandó.
Többszörös öröklés:
A többszörös öröklés lehetővé teszi objektum-osztályoknak attribútumok és szolgáltatások több (és nem csak egy) szuper-osztálytól való öröklését.
94
108.Ismertesse az objektum aggregációs modell feladatát, felépítését, jelölését az UML-ben!
Aggregációs modell: azt mutatja, hogy összetett osztályok hogyan állnak össze más osztályokból.
Az aggregációs modellek hasonlóak a szemantikus adatmodellek „tartalmaz" relációjához.
Felépítés és UML-jelölés:
* Az objektum-osztályokat téglalapok jelképezik, amelyben a név felül, a tulajdonságok középen, az operációk pedig az alsó részben helyezkednek el.
* Az objektumok közti relációkat (asszociációkat) az objektumokat összekötő vonalak jelképezik.
95
109.Milyen modelleket használunk a viselkedés modellezésére?
Viselkedési modellek: az objektumok közötti interakciókat mutatják be a rendszer valamely funkciója során, amelyet esettanulmány (use case) specifikál.
Modell:
Szekvencia-diagramok: az UML-ben az objektumok közötti interakciók modellezésére használjuk.
96
111.Mik az objektum-orientált tervezés elemei? Mivel foglalkozik az OOA, OOT és az OOP?
Objektum-orientált Analízis (OOA), Tervezés (OOT) és Programozás (OOP).
OOA: a felhasználói környezet modelljének kidolgozásával foglalkozik.
OOT: a követelményeket kielégítő rendszer modelljének kidolgozásával foglalkozik.
OOP: az OOT realizálásával foglalkozik egy OO nyelv (pl. Java, C++) segítségével.
97
112.Mik az OOT jellemzői, előnyei?
Az OOT jellemzői:
* Az objektumok a való világ entitásainak reprezentációi, amelyek önmagukat menedzselik.
* Az objektumok önállóak és saját, a külvilág számára közvetlenül nem látható állapottal rendelkeznek.
* A rendszer funkcionalitását objektumok szolgáltatásaiként reprezentáljuk.
* Közös adatterületek nem léteznek. Az objektumok üzenetekkel kommunikálnak.
* Az objektumok lehetnek elosztottak, végrehajtásuk lehet szekvenciális vagy párhuzamos.
Az OOT előnyei:
* Könnyű kezelhetőség. Az objektumok önálló entitásokként foghatók fel.
* Az objektumok potenciálisan újrafelhasználható komponensek.
* Sok rendszerben a való világ entitásai könnyen és értelemszerűen képezhetők le a rendszer objektumaira.
98
113.Mik az objektumok és az objektum-osztályok? UML jelölések.
Objektumok: a szoftver rendszer entitásai, amelyek a való világ és a rendszer entitásait reprezentálják.
Objektum-osztályok: objektumok sablonjai. Belőlük objektumok hozhatók létre.
Az objektum-osztályok más objektum-osztályoktól attribútumokat és szolgáltatásokat örökölhetnek.
UML-jelölés:
* Az objektum-osztályokat téglalapok jelképezik, amelyben a név felül, a tulajdonságok középen, az operációk pedig az alsó részben helyezkednek el.
99
114.Ismertesse az objektumok kommunikációjának elvi és gyakorlati lehetőségeit. Az üzenetek implementálásának lehetőségei.
Elvileg: az objektumok üzeneteken keresztül kommunikálnak.
Üzenetek:
* A hívó objektum által kért szolgáltatás neve.
* A szolgáltatás végrehajtásához szükséges információ másolata, valamint az eredmény tárolójának neve.
Gyakorlatban: az üzenteket gyakran eljárás-hívással implementáljuk:
* Név = eljárás neve.
* Információ = paraméter-lista.
100
115.Mi az általánosítás és az öröklés kapcsolata? UML jelölés.
Az öröklés szabályai, előnyei és problémái.
Az objektumok azon osztályok tagjai, amelyek az attribútumait és az operációt definiálják.
Az osztályok egy osztály-hierarchiába szervezhetők, ahol egy osztály (szuper-osztály) egy vagy több osztály (al-osztály) általánosítása lehet.
Az al-osztály örökli a szuper-osztály attribútumait és operációit, valamint saját metódusokat és attribútumokat adhat ezekhez.
Az UML-beli általánosítást az OO nyelvek öröklésként implementálják.
UML-jelölés:
* Az objektum-osztályokat téglalapok jelképezik, amelyben a név felül, a tulajdonságok középen, az operációk pedig az alsó részben helyezkednek el.
* Az objektum-osztályok közt alulról (alosztály) felfelé (szuperosztály vagy alosztály) nyilak jelölik az általánosítást.
Az öröklés előnyei:
* Egy absztrakciós mechanizmus, amely entitások osztályozására használható.
* Egy újrafelhasználási mechanizmus, amely a tervezés és programozás szintjén is használható.
* Az öröklési gráf alkalmazási környezetek és rendszerek szerveződéséről szolgáltat információt.
Az öröklés problémái:
* Az objektum-osztályok nem „önjáróak". A megértésükhöz szükséges a szuper-osztályuk ismerete is.
* A tervezők gyakran újrahasznosítják az analízis során készített öröklési gráfot.
Ez a hatékonyság kárára válhat.
* Az analízis, tervezés és implementáció során használt öröklési gráfok célja más és más, ezeket egymástól függetlenül kell kezelni.
101
117.Mik a konkurens objektumok?
Az objektumok önálló entitások, így alkalmasok párhuzamos implementációra.
Az objektum-kommunikáció üzenet-modelljét közvetlenül lehet implementálni, ha az objektumok egy elosztott rendszerben, különböző processzorokon futnak.
102
118.Mik a szerverek és az aktív objektumok főbb jellemzői? Az implementáció lehetőségei.
Szerverek: az objektumot párhuzamos folyamatként (szerver) implementáljuk, ahol az objektum operációi belépési pontok lesznek. Ha nincs hívás az objektumra, akkor az felfüggeszti magát és várakozik további szolgáltatás-hívásokra.
Aktív objektumok: az objektumot párhuzamos folyamatként implementáljuk. A belső állapotokat az objektum maga is megváltoztathatja, nem kell hozzá külső hívás.
Implementáció:
Az aktív objektumok attribútumait operációkkal is megváltoztathatjuk, de autonóm módon, belső műveletekkel ezt maguk is megtehetik.
103
119.Ismertese az objektum-orientált tervezési folyamat fő elemeit!
* A rendszer kontextusának és felhasználási módozatainak definiálása.
* A rendszer-architektúra tervezése.
* Az alapvető rendszerobjektumok meghatározása.
* A tervezési modellek kidolgozása.
* Az objektum interfészek specifikálása.
104
120.Mi a rendszer kontextusa és felhasználási módozatai? Hogyan modellezzük ezeket?
A fejlesztendő szoftver és külső környezete közti kapcsolatok feltérképezése.
* A rendszer kontextusa: statikus modell, amely leírja a környezetben levő más rendszereket.
Alrendszer (subsystem) modellek használhatók más rendszerek jelzésére.
* A rendszerhasználat modellje: dinamikus modell, amely a rendszer és környezetének interakcióját mutatja be. Use-case modellek használhatók az interakciók leírására.
Modellek:
Use-case modellek:
* Use-case modellek használatával a rendszer valamennyi interakciója leírandó.
* A use-case modellek a rendszer szolgáltatásait ellipszisek segítségével jelölik.
Az interakcióban résztvevő entitást pálcikaember jelzi.
105
121.Mi az architektúra tervezés? Milyen modelleket használhatunk?
A rendszer és környezete közötti interakciók megértése után ez az információ felhasználható a rendszer-architektúra tervezésére.
Egy architektúra-modell ne tartalmazzon több, mint 7 entitást.
106
122.Ismertesse az objektumok azonosítására használható módszereket!
* A rendszer természetes nyelvi leírásán végzett nyelvi elemzés.
* Az alkalmazási környezetbeli kézzelfogható dolgok alapján.
* Viselkedési megközelítés: mely objektumok mely viselkedésben vesznek részt.
* Szcenárió-alapú analízis: minden szcenárióban azonosítjuk az objektumokat, attribútumokat és a metódusokat.
107
123.Mi a tervezési modellek feladata? Mit írnak le a statikus és dinamikus modellek? Adjon példát lehetséges tervezési modellekre!
A tervezési modellek az objektumokat, objektum-osztályokat, valamint ezen entitások közötti kapcsolatokat írják le.
Statikus modellek: a rendszer statikus struktúráját írják le objektum-osztályok és relációik segítségével.
Dinamikus modellek: az objektumok közötti dinamikus interakciókat írják le.
Pl.:
* Alrendszer (sub-system) modellek: az objektumok koherens alrendszerekre való logikus csoportosítását adják.
* Szekvencia-diagramok: az objektumok közötti interakciók sorozatát írják le.
* Állapotgép-modellek: az egyes objektumok hogyan változtatják állapotukat eseményekre reagálva.
* Egyéb modellek: use-case modellek, aggregációs modellek, általánosítási modellek, stb...
108
124.Mi az objektum interfészek specifikációjának jelentősége?
Milyen módszerek alkalmazhatók interfészek definiálására?
Az objektum interfészek specifikációjának jelentősége: az objektumok és más komponensek párhuzamosan fejleszthetők legyenek.
Módszerek:
Az UML-ben osztály-diagramot használunk az interfészek specifikálására.
109
125.Miért előnyös az OOT a terv evolúciója szempontjából?
Az objektum-orientált tervezés nagy valószínűséggel leegyszerűsíti a rendszer evolúcióját.
110
126.Mik az interfész-tervezés fő emberi tényezői?
* Korlátozott rövidtávú memória: az emberek általában 7 információs egységet tudnak fejben tartani. Ha ennél többet ajánlunk fel, akkor nagyobb eséllyel vétenek hibát.
* Időnként hibázunk: amikor emberi hibák miatt rendszerhiba lép fel, a nem megfelelő riasztások és hibaüzenetek növelik a stresszt, ami újabb hibákhoz vezethet.
* Különbözőek vagyunk: az emberek egészen különböző képességekkel rendelkeznek. A tervezőnek nem szabad a saját képességeiből kiindulnia.
* Különböző interakciókat preferálunk: vannak, akik a képeket, mások a szöveges üzeneteket szeretik.
111
127.Mik a felhasználói interfészek fő tervezési elvei?
* A felhasználó ismeretei: az interfész felhasználó-orientált, és ne számítógép-orientált kifejezéseket és elveket alkalmazzon.
* Konzisztencia: a rendszer mutasson konzisztens képet. Az utasítások, menük legyenek ugyanolyan kinézetűek.
* Minimális meglepetés: ha egy utasítás ismert módon működik, akkor egy hasonló utasítás viselkedése megjósolható legyen.
* Helyrehozhatóság: a rendszer legyen a felhasználói hibák ellen valamelyest ellenálló, és adjon lehetőséget ezen hibák helyrehozására. Ezek lehetnek „vissza" (undo) jellegű funkciók, destruktív akciók előtt jóváhagyás kérése, „lágy" törlések, stb.
* Segítségnyújtás: legyen segítségnyújtási (help) rendszer, on-line kézikönyvek, stb.
* Különböző felhasználók: különféle típusú felhasználók számára is legyenek megfelelő interakciós eszközök. Pl. látáskárosultaknak a nagyobb betűméret.
112
130.Mik az analóg és digitális megjelenítés előnyei, mikor használjuk őket?
* Digitális prezentáció: kompakt: kis helyet igényel a képernyőn, a pontos értékek kijelezhetők.
* Analóg prezentáció: könnyebb egy pillantással az értékről benyomást szerezni, relatív értékek is mutathatók, könnyebb a kivételes adatok felismerése.
113
131.Mik a színek használatának fő szabályai a felhasználói interfészekben?
* A színek száma legyen limitált, használatuk visszafogott.
* Színek változása jelentheti a rendszer állapotának változását.
* A végrehajtandó feladat támogatása történhet színkódolással.
* A színkódolás legyen átgondolt és konzisztens.
* A színek párosítása óvatosan történjen.
114
132.Mik a hibaüzenetek használatának fő szabályai a felhasználói interfészekben?
* A hibaüzenetek tervezése nagyon fontos. Rossz hibaüzenetek hatására a felhasználó elutasíthatja a rendszer használatát.
* A hibaüzenet legyen udvarias, tömör, konzisztens és konstruktív.
* A felhasználó háttérismerete legyen a meghatározó tényező az üzenetek tervezésénél.
115
133.Ismertesse a felhasználói interfészek tervezésének folyamatát, annak 3 fő tevékenységét!
Iteratív eljárás, a fejlesztők és felhasználók szoros kapcsolatban vannak.
A 3 fő tevékenység:
* Felhasználók elemzése: Mit fognak a felhasználók a rendszerrel csinálni?
* Prototípus készítés: prototípusok kidolgozása, kísérletezés céljára.
* Interfész kiértékelés: a prototípusokkal felhasználók bevonásával kísérletek végzése.
116
134.Mik az interfész tervezés során alkalmazott elemzési technikák?
* Feladat elemzése: a feladat végrehajtásához szükséges lépések modellezése.
* Interjúk és kérdőívek: a felhasználók kikérdezése az általuk végzett munkáról.
* Etnográfia: a felhasználók munka közbeni megfigyelése.
117
135.Mi a felhasználói interfész prototípusok célja, illetve milyen fajtáik vannak? Rövid jellemzésük.
Cél: a felhasználó közvetlen tapasztalatokat gyűjtsön az interfészről.
Papír prototípus:
* Szcenáriók végrehajtása vázlatos (skicc) interfészeken.
* A storyboard technikával interakciók sorozata mutatható be.
* Papír prototípusok használatával a felhasználók reakció a javasolt tervvel kapcsolatban hatékonyan feltárhatók.
118
136.Hogyan lehet a felhasználói interfészek használhatóságát értékelni? Mik a főbb használhatósági jellemzők?
Egyszerű értékelési technikák:
* Kérdőívek a felhasználók számára.
* A rendszer használatáról videó-felvétel készítése, majd ennek kiértékelése.
* Kiegészítő kód: a felhasználás módjához és a felhasználói hibákhoz kapcsolódó információk gyűjtése.
* Kiegészítő kód: on-line felhasználói visszajelzések gyűjtése.
Használhatósági jellemzők:
* Tanulhatóság: Mennyi idő alatt lehet egy új felhasználó produktív a rendszer használatával?
* Működési sebesség: A rendszer válaszideje hogyan illeszkedik a felhasználó munkastílusába?
* Robusztusság: Mennyire toleráns a rendszer a felhasználói hibákkal szemben?
* Visszaállíthatóság: Milyen jól tud a rendszer a felhasználói hibákból talpra állni?
* Adaptálhatóság: Mennyire van a rendszer egy adott munkamodellhez kötve?
119
137.Mi a verifikáció és a validáció? Mi a célja?
Verifikáció: a szoftver teljesítse a specifikációt.
Validáció: a szoftver azt csinálja, amit a felhasználó tényleg akar.
Célja: a szoftver iránti bizalmi alapot teremtése: azaz a szoftver elég jó ahhoz, hogy ellássa feladatát.
120
138.Mi a statikus és dinamikus verifikációs módszerek, mi köztük a különbség? Mikor alkalmazhatók statikus, mikor dinamikus módszerek?
Statikus verifikáció: szoftver vizsgálatok: problémák feltárása a rendszer statikus reprezentációjának analízise segítségével. Kiegészíthető eszköz-alapú dokumentum- és kód- analízissel.
Dinamikus verifikáció: szoftver tesztelés: kísérletezés és a termék viselkedésének megfigyelése. A rendszert teszt-adatokkal futtatva működés közben figyeljük a viselkedését.
121
139.Mik a tesztelés típusai, mik ezek fő jellemzői?
* Hibatesztelés: a tesztek rendszerhibák feltárására.
* Validációs tesztelés: célja: annak bizonyítása, hogy a szoftver teljesíti a követelményeket.
122
141.Ismertesse a szoftvertesztelési terv struktúráját!
A tesztelő eljárás, Követelmények követhetősége, Tesztelt elemek, A tesztelés menetrendje, A tesztek rögzítésének eljárása, Hardver és szoftver szükségletek, Kényszerek.
123
143.Hogyan viszonyul egymáshoz a szoftver-vizsgálat és -tesztelés?
A vizsgálatok és a tesztelés egymást kiegészítő verifikációs technikák.
A V & V eljárás alatt mindkettő használata ajánlatos.
A vizsgálat ellenőrzi, hogy a specifikációnak megfelel-e, de azt nem, hogy a valós felhasználói igényeket kielégíti-e.
A vizsgálatok nem tudják ellenőrizni a nem-funkcionális jellemzőket, pl. teljesítmény, használhatóság, stb.
124
144.Milyen főbb szerepek fordulnak elő a szoftver-vizsgálat során?
Szerző vagy tulajdonos, Vizsgáló, Felolvasó, Írnok, Elnök vagy moderátor, Fő moderátor.
125
145.Mik az ellenőrző listák, hogyan alkalmazzuk a szoftver-vizsgálat során? Soroljon fel tipikus pontokat az ellenőrző listán!
A gyakori hibákat tartalmazó ellenőrző lista használandó a vizsgálat levezetésére.
A hiba-ellenőrző listák programnyelv-specifikusak és az adott programnyelv karakterisztikus hibáit tartalmazzák.
Ellenőrző lista pontjai:
Adathibák, Vezérlési hibák, I/O hibák, Interfész hibák, Tárolás-menedzsment hibák, Kivétel- kezelési hibák.
126
146.Hogyan működik az automatikus statikus analízis? Mire használható?
A statikus analizátorok a forrás kódok feldolgozására szolgáló szoftver eszközök.
A program szövegének elemzésével potenciális hibalehetőségek felfedezésére szolgálnak, amelyeket a V & V csoporttal tudatnak.
Lépései: vezérlés analízis, adathasználat analízis, interfész analízis, információ-folyam analízis, útvonal analízis.
127
147.Mikor és hogyan alkalmazhatók a verifikáció során a formális módszerek? Mik az előnyei és hátrányai?
Formális módszerek alkalmazhatók, ha a rendszer matematikai modellje adott.
Előnyei:
* A matematikai specifikáció elkészítéséhez a követelmények részletes elemzése szükséges, ami valószínűleg felfedi a hibákat.
* Implementációs hibákat még a tesztelés előtt fel tud fedni a program és a specifikáció együttes vizsgálatával.
Hátrányai:
* Speciális jelölésrendszer használata szükséges, amelyet az alkalmazási környezet szakértői nem értenek.
* A specifikáció kidolgozása nagyon drága. Még drágább bizonyítani, hogy a program megfelel a specifikációnak.
* Más V & V módszerek alkalmazásával is el lehet jutni ugyanolyan bizalmi szintre.
128
148.Mi a szoftverfejlesztés során alkalmazott tesztelési eljárások 2 fő típusa (fázisa)? Ismertesse ezeket röviden!
* Komponenstesztelés: programkomponensek egyedi tesztelése, általában a komponens fejlesztőjének feladata,
a tesztek a fejlesztő tapasztalatán alapulnak.
* Rendszertesztelés: komponensek rendszerbe vagy
alrendszerbe integrált csoportjainak tesztelése, egy független fejlesztő csoport feladata, a tesztek a rendszerspecifikáción alapulnak.
129
149.Mi a hibatesztelés és a validációs tesztelés célja?
Hibatesztelés célja: a rendszerben hibák keresése. Validációs tesztelés célja: a fejlesztők és megrendelő számára annak demonstrálása, hogy a szoftver teljesíti a követelményeket.
130
151.Ismertesse a tesztelés főbb vezérelveit!
* A menükön keresztül elérhető valamennyi funkciót le kell tesztelni.
* Az azonos menün keresztül elérhető funkciók kombinációit tesztelni kell.
* Ahol felhasználói bevitel van, minden funkciót ellenőrizni kell helyes és helytelen adatokkal.
131
152.Ismertesse a rendszertesztelés célját és főbb tulajdonságait!
Célja: a komponensek rendszerbe vagy alrendszerbe integrálásával foglalkozik.
Fázisai:
* Integrációs teszt: tesztelők használhatják a rendszer forráskódját. A rendszer a komponensek integrálása folyamán teszteljük.
* Végteszt: a tesztelők az átadandó teljes rendszert fekete dobozként tesztelik.
132
153.Ismertesse az integrációs tesztelés célját, megvalósíthatóságának 2 fő lehetőségét, valamint az inkrementális tesztelés menetét!
Integrációs tesztelés célja: a rendszer komponensekből áll, a tesztelés a komponensek interakciójából eredő problémákkal foglalkozik.
Típusai:
* Felülről lefelé (top-down) integrálás: a rendszer vázának felépítése, majd a komponensek beépítése.
* Alulról felfelé (bottom-up) integrálás: az infrastruktúra komponensek integrálása, majd a funkcionális komponensek hozzáadása.
Inkrementális tesztelés menete: ?
133
154.Mi a végteszt célja, menete és főbb tulajdonságai?
Célja: a gyártó bizalmi szintjének növelése abban, hogy a rendszer megfelel a követelményeknek.
A végteszt általában fekete doboz teszt:
* csak a specifikáción alapul, a tesztelők nem ismerik a rendszer implementációját.
Lásd: 155. kérdés ábrája.
134
156.Hogyan lehet a rendszer teljesítményét tesztelni? Ismertesse a stressz-tesztelés menetét! Mikor alkalmazzuk?
A teljesítmény tesztelése általában egy teszt-sorozattal történik, ahol a terhelést fokozatosan növeljük, amíg a rendszer teljesítménye már elfogadhatatlanná válik.
Stressz-tesztelés:
* A rendszert a tervezett értéknél jobban terheljük.
* A rendszer stresszelése gyakran fed fel hibákat.
* A stresszelés a hibás működés közbeni viselkedését is teszteli.
* A rendszernek nem szabad katasztrofálisan összeomlania.
* Teszteli az elfogadhatatlan szolgáltatás-kiesést vagy adatvesztést.
* Alkalmazása: különösen fontos elosztott rendszereknél, ahol a rendszer súlyosan degradálódhat, ha a hálózat túlterhelődik.
135
157.Mi a komponens tesztelés, főbb fajtái?
Komponens tesztelés: az egyes komponensek izolált tesztelésének folyamata.
Hibatesztelő folyamat.
Komponensek lehetnek:
* Egyedi függvények vagy objektumok metódusai.
* Objektum osztályok sok attribútummal és metódussal.
* Kompozit komponensek, amelyek szolgáltatásait interfészeken keresztül lehet elérni.
136
158.Mi az interfész-tesztelés szerepe és felhasználásának módja? Mik a tipikus
interfész-hibák?
Szerepe: az interfészek hibáinak, vagy az interfészekről alkotott hibás feltételezésekből eredő hibák felderítése.
Felhasználásának módja: az objektumokat interfészeikkel definiáljuk.
Tipikus interfész-hibák:
* Hibás interfész használat: a hívó komponens egy másik komponenst akar használni, de rosszul használja annak interfészét.
* Interfész félreértelmezés: a hívó komponens a hívott komponens viselkedéséről téves feltételezésekkel él.
* Időzítési hibák: a hívó és hívott komponensek más sebességgel működnek és így előfordulhat elavult adatok használata.
137
159.Mit jelent a követelmény alapú tesztelés?
Egyik alapelve, hogy a követelmények tesztelhetők legyenek.
Egy validációs tesztelési technika, ahol minden egyes követelményhez kidolgozunk az ellenőrző teszteket.
138
160.Ismertesse a partíciós tesztelés menetét!
A ki- és bemeneti adatok gyakran különböző osztályokba sorolhatók, ahol az osztályon belüli elemek „hasonlóak".
Ezen osztályok mindegyike egy ekvivalencia partíció, ahol a program ekvivalens módon viselkedik az osztály minden elemére.
Teszt esetek minden partícióból választandók.
139
161.Mit jelent a strukturális, vagy „fehér doboz" tesztelés?
Teszt esetek a program struktúrája alapján.
A program ismerete alapján újabb teszt esetek azonosítása.
Cél: valamennyi utasítás (de nem minden végrehajtási út kombináció) végrehajtása.
