projektmunka_szoftvertechnologia_coedu_kerdessor_nappali_levelezo_publikus_gyakorlo (1).pdf

Kérdés: Melyek a RUP modell fázisai? Elindítás, kidolgozás, megépítés, átmenet Kezdeményezés, tervezés, elkészítés, átadás Elindítás, tervezés, kifejtés, átadás Helyzetelemzés, tervezés, kidolgozás, átadás Kérdés: Mely modell fázisait foglalja magában a RUP modell 2. dimenziója? Vízesés modell...

Kérdés: Melyek a RUP modell fázisai? Elindítás, kidolgozás, megépítés, átmenet Kezdeményezés, tervezés, elkészítés, átadás Elindítás, tervezés, kifejtés, átadás Helyzetelemzés, tervezés, kidolgozás, átadás Kérdés: Mely modell fázisait foglalja magában a RUP modell 2. dimenziója? Vízesés modell Evolúciós modell Spirál modell V-modell Kérdés: Mi az a RUP? Egy specifikációs módszer. Egy zenei stílus. A Vízesés modell utolsó fázisa. Egy szoftverfejlesztési modell. Kérdés: Miért olyan fontos a követelményspecifikáció a RUP modellben? Azért, mert jó követelményspecifikációval a projekt végén sok prémiumra számíthatunk. Egyrészt azért fontos, hogy ne kelljen sokat kommunikálni a fejlesztőkkel, másrészt azért, hogy a fejlesztés többi fázisát ne kelljen elvégezni, mivel jó követelményspecifikáció esetén nincs szükség a fejlesztés többi fázisára. A számos előny közül kiemelendő, hogy ha a követelmények pontosan le vannak fektetve, akkor később a megrendelővel sem kell annyit egyeztetnünk, illetve a fejlesztés többi fázisát gyorsabban el tudjuk végezni, mivel letisztult, pontos kiindulási adataink vannak. Kérdés: Mely jellemző nem az agilis szoftverfejlesztés jellemzője? rugalmas jó követelményspecifikáció jó kommunikáció a megrendelővel, felhasználóval nagyon bonyolult szabályrendszerek Kérdés:Mely szavak jellemzik leginkább az agilis szoftverfejlesztést? fürge, rugalmas, hatékony, kommunikatív gyors, törtető, zárkózott, merev lassú, hatékony, kommunikatív, előre definiált fürge, előre definiált, korlátolt, hatékony Kérdés:Kik a scrum résztvevői? Product Owner, ScrumMaster, Team SrumTeam, Coach, Audience Kérdés: Kik a kiemelt szereplői egy szoftverprojektnek? team, projektvezető, projektmenedzser rendszergazda, oktató, felhasználó Kérdés: Egy szoftver projektben mi a feladata a projektvezetőnek? projekttervezés, felülvizsgálat, beszámoló projekt anyagi támogatása, kész projekt felülvizsgálata team munkájának gazdasági elemzése, tanácsadás a megrendelőnek Kérdés:Mely tervre nem igaz, hogy egy szoftverprojekt tervezésének fontos része? validációs terv konfigurációkezelési terv épületgépészeti terv karbantartási terv Kérdés:Mit nem tartalmaz a projektterv? bevezetés kockázatelemzés megrendelő fizetése projekt ütemterve Kérdés:Egy szoftverprojekt során mely nem szoftverkockázat? specifikáció késése méret alábecslése munkaerő stílusának megváltozása technológia megváltozása Kérdés: Egy szoftverprojekt esetében mely nem kockázati kategória? projektkockázat termékkockázat szomszédos kockázat üzleti kockázat Kérdés:Miért jobb a COCOMO Intermediate, mint a COCOMO Basic? Mert számol költségtényezőkkel is. Mert később dolgozták ki. Mert olcsóbb. Kérdés:Hány csoportra oszthatjuk a COCOMO Intermediate költségtényezőit? 3 6 4 5 Kérdés:Mely nem tartozik a COCOMO Intermediate személyi költségtényezői (personnelattributes) közé? applicationsexperience virtualmachineexperience communicationability software engineercapability Kérdés:A COCOMO2 mely modellre vonatkozik elsősorban? V-modell vízesés modell spirál modell evolúciós modell Kérdés:Mi az a CMM? Kormányzati projektre kifejlesztett módszer annak kiderítésére, hogy milyen eséllyel teljesül a projekt. Koordinált műszaki manufaktúra. Olyan módszer, mellyel pontosan meghatározható a projekt teljes költsége. Kérdés:Melyik a CMM utódja? CMM1 CMM2 CMMb CMMI Kérdés:Mely nem a CMMI fő iránya? development services hardware acquisition Kérdés: Melyek a CMMI érettségi szintjei? Initial, Managed, Defined, QuantitativelyManaged, Optimizing Initial, Intermediate, Defined, Created, Optimized Incomplete, Initial, Defined, Performed, Optimizing Kérdés: Mi a feladata a scrum-ban a Teamnek? Csapat alkotása, a szoftver elkészítése. Mindenkinek megvan a titulusa, eszerint végzi a feladatát. A projekt legvégéig fix tagsággal működik, és a szoftver tesztelése a legfontosabb feladata. Kérdés: Mely állítás nem igaz a product backlog-ról? A kívánt munkák listáját tartalmazza a projekten. Része a sprint backlog. A sprint burndown chart része. Kérdés: Mely állítás nem igaz a sprint-re? Közben a csapatot nem érheti külső hatás. A napi scrum meetinggel kezdődik. 2-4 hetes iterációkban történik. Pontosan egy van belőle egy projekt során. Kérdés:Mennyi ideig tart egy sprint? 2-4 hét 1-6 hónap 2 hét – 6 hónap 4-8 hét Kérdés: Mi történik a sprint planning során? Produckt backlog és sprint backlog elkészítése, a sprint céljának meghatározása. A daily scrum meeting témájának előkészítése. A szoftver elkészítése. Kérdés: Mi az a sprint burndown chart? Egy diagram, mely tartalmazza (naponta), hogy mennyi idő és mennyi elem van még hátra. Egy diagram, melyen lineárisan ábrázolják a projekt időbeosztását. Egy diagram, mely folytonosan lefelé halad a 0-ig. Kérdés: Mi az a release burndown chart? Diagram, melyen látható, hogy időben kész lesz-e a szoftver aktuális változata. Diagram, melyen láthatjuk a projekt teljes időbeosztását. Diagram, melyen 0-200 között láthatjuk a napi hátralévő feladatszámot. Kérdés: Mi jellemző a CMMI „Kezdeti ” érettségi szintére? A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek. A hangsúly a folyamatok tökéletesítésén van. A folyamatok mérhetőek és ellenőrzöttek. A folyamatok a szervezetre szabottak és biztonságosabbak. Kérdés: Mi jellemző a CMMI „Menedzselt” érettségi szintére? A folyamatok a projektre szabottabbak. A hangsúly a folyamatok tökéletesítésén van. A folyamatok mérhetőek és ellenőrzöttek. A folyamatok a szervezetre szabottak és biztonságosabbak. Kérdés: Mi jellemző a CMMI „Meghatározott” érettségi szintére? A folyamatok a szervezetre szabottak és biztonságosabbak. A hangsúly a folyamatok tökéletesítésén van. A folyamatok mérhetőek és ellenőrzöttek. A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek. Kérdés: Mi jellemző a CMMI „Optimalizált” érettségi szintére? A hangsúly a folyamatok tökéletesítésén van. A folyamatok mérhetőek és ellenőrzöttek. A folyamatok a szervezetre szabottak és biztonságosabbak. A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek. Kérdés: Mit mond ki a Moore-törvény? Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény másfél évenként megkétszereződik. Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény két évenként megkétszereződik. Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény másfél évenként megkétszereződik. Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény két évenként megkétszereződik. Kérdés: Mik egy hardver rendszer részei? Számítógép Számítógéphez csatlakozó perifériák Kommunikációs elemek A rendszer felépítését, összetételét leíró dokumentáció A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció A rendszer koncepcióját, tervét leíró fejlesztői dokumentáció A számítógépben található komponensek, egységek Kérdés: Mik egy szoftver rendszer részei? A számítógépen futó programok együttese A programok futtatásához szükséges konfigurációs adatok, fájlok együttese A rendszer felépítését, összetételét leíró rendszer-dokumentáció. A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció A számítógép tároló egységein található adat, információ A szoftverhez tartozó adattároló egység (pl.: CD, DVD) Kérdés: Az alábbiak közül melyik lehet egy szoftver termék? Generikus termék Genetikus termék Generális termék Custom product Egyik sem Kérdés: Mi a generikus termék jellemzői? Fejlesztő cég önálló terméke Fejlesztő cég saját erőből állítja elő Nyílt piacon értékesítik Felhasználói megrendelésre készül Megrendelő ötletei alapján készül Kérdés: Mi a generikus termék jellemzői? Fejlesztő cég saját tervek alapján készíti el Bárki megvásárolhatja Nyílt piacon nem kerül értékesítésre Megrendelő finanszírozza Adott ügyfél számára készül Kérdés: Mi a megrendeléses termék jellemzői? Felhasználói megrendelésre készül Felhasználó igényei alapján tervezik Szerződés alapján készül Nyílt piacon értékesítik Fejlesztő cég saját erőből állítja elő Fejlesztő cég önálló terméke Kérdés: Melyik az a szoftver termék, melynek specifikálását, tervezését, létrehozását a fejlesztő intézmény a piaci elvárások felmérése alapján, a várható felhasználói igények meghatározása révén végzi el? Generic product Generikus termék Megrendeléses termék Custom software Bespoken product Egyik sem Kérdés: Szoftver termékek esetén mit jelent a customization? Egy generikus szoftvert egy adott felhasználó igényeihez alakítva adnak el neki Adott felhasználó igényei alapján fejlesztenek számára egy egyedi szoftvert Olyan szoftverről van szó, melyet a felhasználó saját maga testre szabhat, igényeinek megfelelően A kifejezés nem értelmezett a szoftver termékek esetén Kérdés: Mit értünk az elvárásoknak megfelelő működésen? A szoftver teljesíti a felhasználói igényeket, elfogadható futási idő alatt, és elfogadható kényelmet biztosítva végzi el feladatát. A szoftver kielégíti a specifikációban lefektetett feltételeket, és hibafellépés nélkül végzi el feladatát. A szoftver működése során nem veszélyeztet emberi életet, nem okoz környezeti és gazdasági károkat. A szoftver az elvárt kimenettel szolgál adott bemenetek esetén. Kérdés: Egy szoftver termékre milyen tulajdonságoknak kell teljesülnie? Tesztelhető Újra-felhasználható Karbantartható Együttműködhető Biztonságos Hasznosítható Kérdés: Mit jelent egy szoftver termék esetén a hatékonyság? Kellő idő alatt teljesíti a számítási feladatát. Elfogadható a futási ideje. Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal. Hibafellépés nélkül hajtja végre előírt feladatát. Kérdés: Mit jelent egy szoftver termék esetén a megbízhatóság? Hibafellépés nélkül hajtja végre előírt feladatát. Kellő idő alatt teljesíti a számítási feladatát. Elfogadható a futási ideje. A hibákat felismeri és megfelelően kezeli. Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal. Kérdés: Mit jelent egy szoftver termék esetén a használhatóság? Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal. Kellő idő alatt teljesíti a számítási feladatát. Hibafellépés nélkül hajtja végre előírt feladatát. Elfogadható a futási ideje. Kérdés: Mit jelent egy szoftver termék esetén a módosíthatóság? Könnyen meg lehet változtatni, ha a követelmények változnak. Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek. A felhasználó igényei szerint változtathatja a szoftver összetételét, komponenseit. A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani. Kérdés: Mit jelent egy szoftver termék esetén a hordozhatóság? A lehető legkevesebb újraírás árán lehessen átvinni egy másik hardver-platformra. A lehető legkevesebb újraírás árán lehessen átvinni egy másik operációs rendszer alá. Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek, felhasználhatóak legyenek. A szoftver mobil informatikai eszközökön is futtatható legyen. Kérdés: Mit jelent egy szoftver termék esetén az újra-felhasználhatóság? Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek, felhasználhatóak legyenek. A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani. A felhasználó a szoftvert az eredeti felhasználási igényeken túlmenően más feladatok elvégzésére is fel tudja használni. Könnyen meg lehet változtatni, ha a követelmények változnak. Kérdés: Mit jelent egy szoftver termék esetén a karbantarthatóság? A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani. Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek, felhasználhatóak legyenek. Könnyen meg lehet változtatni, ha a követelmények változnak. Szoftver meghibásodás esetén hatékonyan lehet javítani, módosítani. Kérdés: Mi az úgynevezett Brooks-féle szabály? Ahhoz, hogy a kezdeti kétemberes fejlesztés ne csak a két ember számára legyen elfogadható, hanem széles körben, mások által is használható legyen, még további munkára, ráfordításra van szükség, ami az eredetinek kb. 8-9-szerese. Ahhoz, hogy a kezdeti néhány emberes fejlesztés ne csak egy szűk kör számára legyen elfogadható, hanem széles körben, mások által is használható legyen, még további munkára, ráfordításra van szükség, ami az eredetinek kb. 4-5-szöröse. Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény másfél évenként megkétszereződik Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény másfél évenként megkétszereződik. Kérdés: Mi az emberhónap? A projektek munkaráfordításának egy mérőszáma. Ezt a számot úgy kapjuk meg, hogy a projektben részt vevő emberek átlagos számát megszorozzuk a projekt teljes időtartamával. Egy szoftverfejlesztési mérőszám. Megadja, hogy egy adott fejlesztési projekt elvégzéséhez mennyi időre van szüksége a fejlesztőcsapatnak. Megadja, hogy a fejlesztő team egy tagjának mennyi idő szükséges a projekt feladat elvégzéséhez. Megadja, hogy a fejlesztő team havi lebontásban átlagosan hány fejlesztőt alkalmaz az adott projekt elvégzésére. Kérdés: Egy fejlesztési projekt esetén EH=112. Mennyi lehet E és H értéke? E=1, H=112 E=2, H=56 E=28, H=4 E=7, H=16 E=14, H=8 Kérdés: Egy szoftverfejlesztési projekt mikor nevezhető sikeresnek? Ha a kitűzött határidőn belül készül el Ha a fejlesztés a megállapított költségkereten belül valósul meg Ha az eredetileg specifikált működési jellemzők többsége teljesül Ha a felhasználó igényeket teljes mértékben kielégíti Ha az értékesítés során sikerül profitot termelni Kérdés: Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver alkalmazási területek közé? Rendszer-szoftverek Valós idejű szoftverek Üzleti célú szoftverek Rendszer közeli szoftverek Kérdés: Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver alkalmazási területek közé? Mérnöki és tudományos célú szoftverek Beágyazott szoftverek Felhasználói szoftverek Operációs rendszer szoftverek Kérdés: Mi a VIR? EIS Vezetői információs rendszer ERP Vállalati információs rendszer Vállalati irányítási rendszer Vezetői irányítási rendszer Kérdés: Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver alkalmazási területek közé? Személyi számítógépes szoftverek Mesterséges intelligencia szoftverek Irodai és üzleti szoftverek Tervező és grafikai szoftverek Kérdés: Mi igaz a VIR esetén? Elsősorban felső szintű döntéshozók, pénzügyi szakemberek és üzletemberek számára nyújt támogatást. Nem dolgozik bele a vállalati adatbázisba, onnan csak kiválasztja a „hasznos” adatokat. Egy vállalat összes üzleti tevékenységét lefedi, kiszolgálja. Óriási mennyiségű adat írását, olvasását, feldolgozását végzi. Elterjedt angol megnevezése az Enterprise Resource Planning System. Kérdés: Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések? Időbeliséghez igazodás, külső események felügyelete, vezérlése, időkereten belüli reagálás. Valós idejű szoftver Rendszer szoftver Mesterséges intelligencia szoftver Üzleti célú szoftver Kérdés: Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések? Nagy mennyiségű információ feldolgozás, komponens alapú komplex rendszer, minden komponensnek egyéni funkció. Üzleti célú szoftver Rendszer szoftver Mérnöki és tudományos célú szoftver Beágyazott szoftver Kérdés: Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések? Nagy mennyiségű számítási igény, nagy teljesítményű hardver, komplex matematikai műveletek. Mérnöki és tudományos célú szoftver Rendszer szoftver Mesterséges intelligencia szoftver Egyik sem Kérdés: Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések? Vezérlő eszköz vagy célberendezés működését segítik, teszik lehetővé. Beágyazott szoftver Mesterséges intelligencia szoftver Rendszer szoftver Egyik sem Kérdés: Honnan számítható egy szoftver életciklusa? Egy szoftver életciklusa a követelmények specifikálásával veszi kezdetét. Egy szoftver életciklusa akkor kezdődik, amikor a felhasználó használatba veszi az elkészült szoftvert. Egy szoftver életciklusa a fejlesztési folyamattal egy időben kezdődik. Egy szoftver életciklusa az üzembe helyezéssel indul. Kérdés: Mikor fejeződik be egy szoftver életciklusa? Amikor a szoftver elavulttá válik, használaton kívülre kerül. Amikor a szoftverfejlesztés lezárul, értékesíthetővé válik a szoftver. Egy szoftver életciklusa sosem zárul le, mert a szoftver nem öregszik és nem megy tönkre. Amikor a szoftvernek újabb kiadása kerül értékesítésre, ezáltal a régebbi verzió használaton kívülre kerül. Kérdés: Az alábbiak közül melyek szoftverfejlesztési modellek? Vízesés modell Evolúciós fejlesztés Inkrementális fejlesztés Spirál modell V-modell Generikus fejlesztés Dekrementális fejlesztés Iterációs fejlesztés Kérdés: Mely életciklus modell vázlatos diagramja látható a képen? Vízesés modell Lineáris ciklus V modell Inkrementális fejlesztés Prototípus-alapú fejlesztés Kérdés: Mely életciklus modell vázlatos diagramja látható a képen? Inkrementális fejlesztés Növekményes fejlesztés Prototípus-alapú fejlesztés Iterációs fejlesztés Vízesés modell Kérdés: Az alábbi állítások közül mely hamis? A V-modell leginkább a vállalati információs rendszerekhez alkalmas. A spirál modell a nem szigorúan specifikált kiinduláshoz alkalmazható. A spirál modell az erőforrások elosztására és a költségekre koncentrál. A V-modell a biztonsági követelmények teljesítéséhez alkalmazkodik Kérdés: Mi jellemezte egy szoftverfejlesztési folyamatot a szoftver-technológia kialakulásának kezdetén? Egymás után elvégzendő feladatok sorozatának definiálása. Egyes feladatok végrehajtására konkrét tevékenységek rendelése. Fejlesztési tevékenységek időrendbeli rendezése. Konkrét feladat megoldására alkalmas modell. Fejlesztési lépések halmazának definiálása. Fejlesztési lépések céljának meghatározása. Fejlesztési folyamat elvont, absztrakt definiálása. Általános fejlesztési modell. Kérdés: Mi jellemezi egy szoftverfejlesztési folyamatot a szoftver-technológia mai szemlélete szerint? Fejlesztési lépések halmazának definiálása. Fejlesztési lépések céljának meghatározása. Fejlesztési folyamat elvont, absztrakt definiálása. Általános fejlesztési modell. Egymás után elvégzendő feladatok sorozatának definiálása. Egyes feladatok végrehajtására konkrét tevékenységek rendelése. Fejlesztési tevékenységek időrendbeli rendezése. Konkrét feladat megoldására alkalmas modell. Kérdés: Milyen fázisok találhatóak a vízesés modellben? Követelmények elemzése és meghatározása Rendszertervezés és szoftvertervezés Implementáció és az egységek tesztelése Integrálás és rendszertesztelés Üzemeltetés és karbantartás Fejlesztési célok, követelmények meghatározása Modulok előállítása és tesztelése Felhasználók oktatása Kérdés: A vízesés modell fázisai közül melyik az, melyből bármelyik korábbi fázishoz visszatérhetünk? Üzemeltetés és karbantartás Rendszer validálás és bizonylatolás Integrálás és rendszertesztelés Implementáció és egységek tesztelése Kérdés: Hogyan szokás még nevezni a vízesés modellt? Lineáris ciklus Inkrementális modell Növekményes fejlesztés Evolúciós fejlesztés Prototípus alapú fejlesztés Kérdés: Mikor alkalmazható jól a vízesés modell? Ha a fejlesztési követelmények egyértelműen meg vannak határozva. Ha nem áll fent annak a veszélye, hogy a követelmények megváltoznak. Ha a fejlesztési követelmények kezdetben nincsenek egyértelműen meghatározva. Ha a fejlesztési követelmények a projekt során többször módosulnak. Kérdés: Ha egy rendszert nem lehet vagy nem érdemes pontosan specifikálni, akkor milyen szoftverfejlesztési modellt célszerű alkalmazni? Evolúciós fejlesztés Prototípus-alapú fejlesztés Inkrementális modell Spirál modell V modell Kérdés: Mi jellemző a lineáris ciklusra? Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak egyetlen „menetben” valósul meg. Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására. Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót eredményez. Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési ciklusokba, hurkokba rendezve. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel. Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat rendelik meg. Kérdés: Mi jellemző az evolúciós fejlesztésre? Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására. Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót eredményez. Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak egyetlen „menetben” valósul meg. Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési ciklusokba, hurkokba rendezve. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel. Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat rendelik meg. Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat rendelik meg. Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési ciklusokba, hurkokba rendezve. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel. Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására. Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót eredményez. Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak egyetlen „menetben” valósul meg. Kérdés: Prototípus alapú fejlesztés esetén melyik az a fázis, mely során visszaléphetünk a modell kezdeti fázisához? Prototípus megfelelőségének vizsgálata Rendszer specifikálása Rendszer tervezése Rendszer tesztelése és validálása Prototípus implementálása és tesztelése Kérdés: Mekkora rendszereknél célszerű alkalmazni az evolúciós fejlesztést? Kiss és közepes méretű rendszerek esetén, ahol nincs szükség több team-re. Nagy méretű rendszerek esetén, ahol több team munkájára van szükség. Kiss és nagy méretű fejlesztések esetén egyaránt jól használható. Kiss méretű, de több team együttes munkáját igénylő fejlesztéseknél. Kérdés: Mit nevezünk inkrementumnak? Növekményes fejlesztési modell esetén az egyes részfunkciókat megvalósító fejlesztési változatokat. Evolúciós fejlesztési modell esetén az egyes részfunkciókat megvalósító fejlesztési változatokat. Növekményes fejlesztési modell esetén a szoftver specifikációban lefektetett részfunkciókat. Evolúciós fejlesztési modell esetén a szoftver specifikációban lefektetett részfunkciókat. Egyik sem. Kérdés: Az alábbiak közül melyik igaz a növekményes fejlesztési modell esetén? Inkrementumokból integrálják össze a kész rendszert. Az egyes inkrementumokat külön fejlesztik le. A inkrementumok száma a rendszer moduljainak számától függ. Jellemző sajátossága a szekvencialitás. A rendszer validálása során bármely korábbi fázishoz visszaléphetünk. Kérdés: Inkrementális fejleszt esetén mely fázis során és hova léphetünk vissza? A rendszer teljességének vizsgálata során léphetünk vissza az inkrementum kifejlesztési fázis elé. A rendszer teljességének vizsgálata során léphetünk vissza a rendszer architektúra tervezési fázis elé. A rendszer validálása során léphetünk vissza az inkrementum validálási fázis elé. Az inkrementum integrálása során léphetünk vissza az inkrementum kifejlesztési fázis elé. A rendszer validálása során bármely korábbi fázishoz visszaléphetünk. Kérdés: Milyen előnyei vannak az inkrementális fejlesztésnek? A felhasználónak nem kell megvárnia, amíg a teljes végleges rendszert megkapja. Viszonylag alacsony a kockázata annak, hogy teljes projekt sikertelen lesz. A fontos szolgáltatások fogják a legtöbb tesztelést kapni. Szoros az inkrementumok közti kapcsolat és együttműködés. Az inkrementumok révén jól kezeli a nagy méretű részfunkciókat. A fejlesztés során előálló prototípusok révén jól tesztelhető a rendszer. Kérdés: Mi jellemző a spirál modellre? Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési ciklusokba. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel. Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására. Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót eredményez. Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat rendelik meg. Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak egyetlen „menetben” valósul meg. Kérdés: Spirál modell esetén mi történik a tervezési fázisban? A projekt teljes átvizsgálása, döntés további folytatásról. A felhasználói igények alapján meg kell tervezni a szoftver architektúrát. Az egyes szoftvermodulok implementálásához szükséges tervek előkészítése történik. Kockázatok azonosítása és csökkentése. Kérdés: Az alábbiak közül melyik igaz? A spirál modell fontos velejárója a kockázatok feltárása és csökkentése. Spirál modell esetén lehetséges az, hogy az egyik spirál-ciklust a másiktól eltérő modell használatával valósítsuk meg. Spirál modell esetén mindegyik ciklusban ugyanazt a modellt kell alkalmaznunk. Spirál modell esetén nem hangsúlyos a kockázatok elemzése és csökkentése. Kérdés: Milyen fejlesztési modellt vagy modelleket választana olyan feladat esetén, amit előzetesen pontosan ismer, a teljes felépítéssel együtt? Vízesés modell V modell Prototípus alapú fejlesztés Inkrementális fejlesztés Spirál modell Kérdés: Milyen fejlesztési modellt vagy modelleket választana olyan feladat esetén, ahol korai eredményt szeretnénk elérni a felhasználó megnyerése érdekében? Prototípus alapú fejlesztés Spirál modell Inkrementális modell V modell Vízesés modell Kérdés: Mi jellemzi a biztonságkritikus rendszert? Ne veszélyeztesse az emberi életet. Ne veszélyeztesse az egészséget. Ne okozzon gazdasági kárt. Ne okozzon környezeti kárt. Tipikusan ilyenek a banki szoftverek. Tipikusan ilyenek a vállalati számlázó szoftverek. Szoftver hiba esetén is képes végrehajtani a feladatát. Kérdés: Mi jellemző a hibatűrő rendszerekre? Hiba esetén is képes ellátni főbb funkcióit. Hiba esetén teljesítménye lecsökkenhet. Hiba esetén is ugyanolyan hatásfokkal képes működni, mint hibamentesen. Szoftver meghibásodás esetén is képes működni. Tervezésnél az a cél, hogy a szoftver minden körülmények között hibamentesen működjön. Kérdés: Mi a megbízhatóság? Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t] időintervallumban, feltéve, hogy a t0 = 0,7 ? Az informatikai rendszer a t időpontban legalább 0,7 valószínűséggel biztonságosan fog működni. Az informatikai rendszer a t időpontban legalább 0,7 valószínűséggel helyesen fog működik. Az informatikai rendszer t idő alatt legalább 0,7 valószínűséggel újra üzemképes állapotba hozható. Az informatikai rendszer a t időpontig legalább 0,7 valószínűséggel megbízhatóan fog működik. Kérdés: Mit jelent az M(t) >= 0,9 ? Az informatikai rendszer t idő alatt legalább 0,9 valószínűséggel újra üzemképes állapotba hozható. Az informatikai rendszer a t időpontban legalább 0,9 valószínűséggel biztonságosan fog működni. Az informatikai rendszer a t időpontban legalább 0,9 valószínűséggel helyesen fog működik. Az informatikai rendszer a t időpontig legalább 0,9 valószínűséggel megbízhatóan fog működik. Kérdés: Mely állítások igazak a BIST esetén? A built-in self-testing rövidítése. Az M(t) értékének magas szinten tartására használják. Az R(t) értékének magas szinten tartására használják. Arra szolgál, hogy egy informatikai rendszer könnyen tesztelhető legyen. Az S(t) értékének magas szinten tartására használják. Kérdés: Mi a verifikáció? Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy előállítási folyamatában. Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e mindazokat a felhasználói elvárásokat, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy előállítási folyamatában. A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból megfelel-e a felhasználói követelményeknek. A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból megfelel-e a specifikációban lefektetett követelményeknek. Kérdés: Mi a validáció? A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból megfelel-e a felhasználói követelményeknek. A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból megfelel-e a specifikációban lefektetett követelményeknek. Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e mindazokat a felhasználói elvárásokat, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy előállítási folyamatában. Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy előállítási folyamatában. Kérdés: Ha tökéletesen végrehajtjuk a verifikációs folyamatot, akkor az garantálja a végtermék tökéletes felhasználhatóságát? Nem. Amit garantálni lehet, az a kiindulási specifikációval való ekvivalencia teljesülése. Nem. Ha specifikálásban történt hiányosság vagy tévedés, a végtermék nem fog minden tekintetben megfelelni a felhasználási követelményeknek. Nem. A verifikációs folyamat tökéletes végrehajtása csak elméleti szinten lehetséges. Igen. A verifikáció során mindvégig az előzetesen lefektetett felhasználói követelményekhez kell igazodni. Igen. A verifikálásra csak a validálás után kerülhet sor, ami garantálja a tökéletes felhasználhatóságot. Kérdés: Biztonságkritikus rendszer esetén mit kell igazolni a validáció során? A funkcionális megfelelőséget. A teljesítményben való megfelelőséget. A biztonsági követelmények teljesülését. A felhasználói követelményeknek való megfelelőséget. A biztonsági előírásoknak való megfelelőséget. Kérdés: Az alábbiak közül melyik igaz? A verifikáció arra ad választ, hogy a termék előállítása helyesen történt-e. A validáció arra ad választ, hogy a helyes terméket állítottuk-e elő. A validáció arra ad választ, hogy a termék előállítása helyesen történt-e. A verifikáció arra ad választ, hogy a helyes terméket állítottuk-e elő. Kérdés: Mit fejez ki a V modell lefelé haladó ága? A tervezési és létrehozási folyamatot. A specifikációs és architektúrális folyamatot. A teszttervezési és implementációs folyamatot. A tesztelési és ellenőrzési folyamatot. Kérdés: Mit fejez ki a V modell felfelé haladó ága? A tesztelési és ellenőrzési folyamatot. A tervezési és létrehozási folyamatot. A specifikációs és architektúrális folyamatot. A teszttervezési és implementációs folyamatot. Kérdés: Az alábbiak közül melyek a V modell életciklusának állomásai? Követelmények specifikálása Hazárd- és kockázatanalízás Rendszer specifikálás Felhasználói igények felmérése Szoftver specifikálás Kérdés: Az alábbiak közül melyek a V modell életciklusának állomásai? Architektúra tervezés Modul tervezés Modulok előállítása és tesztelése Inkrementum kifejlesztése Specifikációnak való megfelelés vizsgálata Kérdés: Az alábbiak közül melyek a V modell életciklusának állomásai? Rendszer integrálása és tesztelése Rendszer verifikálása Rendszer validálása Inkrementumok tesztelése és integrálása Rendszer architektúra tesztelése Kérdés: Mi a V modell életciklusának befejező állomásai? Bizonylatolás, majd a rendszer üzemeltetése Rendszer verifikálása, majd validálása A felhasználók oktatása, végül a rendszer üzemeltetése Rendszer integrálása és tesztelése, végül a rendszer üzemeltetése Kérdés: V modell esetén mely fázis eredményeként áll elő a biztonsági követelmények dokumentációja? Hazárdok és kockázatok elemzése Követelmények specifikálása Architekturális tervezés A teljes rendszer-specifikáció A teljes rendszer validálása Kérdés: V modell esetén mely fázis eredményeként állnak elő a hardver és szoftver tervdokumentációk? Architekturális tervezés A teljes rendszer-specifikáció Követelmények specifikálása Modulokra bontás A teljes rendszer verifikálása Kérdés: V modell esetén az üzemeltetés és karbantartás fázisnak mi a bemeneti dokumentációja? A biztonsági követelmények dokumentációja A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A rendszer terve, és a teljes rendszer-specifikáció A modulok terve, és a teljes rendszer terve Kérdés: V modell esetén a bizonylatolás fázisnak mi a bemeneti dokumentációja? A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A biztonsági követelmények dokumentációja A modulok terve, és a teljes rendszer terve A teljes rendszer-specifikáció Kérdés: V modell esetén a teljes rendszer validálása fázisnak mi a bemeneti dokumentációja? A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A biztonsági követelmények dokumentációja A modulok terve, és a teljes rendszer terve A rendszer terve, és a teljes rendszer-specifikáció Kérdés: V modell esetén a teljes rendszer verifikálása fázisnak mi a bemeneti dokumentációja? A rendszer terve, és a teljes rendszer-specifikáció A biztonsági követelmények dokumentációja A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A modulok terve, és a teljes rendszer terve Kérdés: V modell esetén a szoftver-modulok összeintegrálása fázisnak mi a bemeneti dokumentációja? A modulok terve, és a teljes rendszer terve A biztonsági követelmények dokumentációja A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A rendszer terve, és a teljes rendszer-specifikáció Kérdés: V modell esetén a modulok elkészítése és tesztelése fázisnak mi a bemeneti dokumentációja? A modulok terve A modulok terve, és a teljes rendszer terve A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció A biztonsági követelmények dokumentációja Kérdés: Mi igaz az inkrementális tesztelésre? Egy kiindulási, minimális számú modulhoz egymás után illesztjük a bővítésként szolgáló modulokat. Minden egyes bővítés után külön teszteljük az addig összeállt komplexumot. Az újabb hibák egy-egy bővítés során léphetnek be nagy valószínűséggel. A szoftver moduljait külön-külön teszteljük, majd a már verifikált alegységekből építjük fel a szoftver komplexumot. Egyszerű a hibajavítás, mert a bővítés során megjelenő hibák az újonnan beépített modulban keresendők. A tesztesetek halmazát inkrementálisan növeljük a tesztelés során. Kérdés: Mi igaz a big bang tesztelésre? Az összes modult egyszerre rakjuk össze. Azon a feltevésen alapul, hogy az előzetesen már letesztelt modulok együtt is jól fognak működni. Több menetben hajtjuk végre a tesztelést. Hibák megtalálása egyszerűbb, mint az inkrementális tesztelés esetén. Olyan rendszerek esetén használjuk, ami nem igényli, hogy több modulra bontsuk szét. Kérdés: V modell esetén mi történik az architekturális tervezés fázisban? El kell dönteni, hogy mely funkciók legyenek megvalósítva hardver, és melyek szoftver által. Elő kell állítani a hardver és szoftver rendszerterveket. El kell dönteni, hogy a szoftver rendszert milyen funkciókra bontjuk fel és azok milyen környezetben kerülnek megvalósításra. Elő kell állítani a szoftver modulok tervdokumentációját. Kérdés: Mi a HW-SW co-design? Ebben a megközelítésben a tervezési folyamatnak csak egy későbbi szakaszában dől el a HW-SW- megosztás. A hardver és szoftver fejlesztés szétválasztására ad irányelveket. Ebben a megközelítésben mindvégig egységes alapokon történik a hardver és szoftver tervezés. Egy rendszerfejlesztési életciklus modellt definiál. Kérdés: Mi a hazárd? Olyan helyzet, amely valóságos vagy lehetséges veszélyt jelent az emberek vagy a környezet számára. Egy kockázathoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki, hogy milyen valószínűségű veszélyes következményei lehetnek egy kockázatnak. A szoftver vagy hardver rendszer olyan komponense, mely veszély és hiba forrása lehet. Olyan szituáció, mely gazdasági, környezeti, emberi károkat okozhat. Egyik sem. Kérdés: Mi a kockázat? Egy hazárdhoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki, hogy milyen valószínűségű veszélyes következményei lehetnek egy hazárdnak. Olyan helyzet, amely valóságos vagy lehetséges veszélyt jelent az emberek vagy a környezet számára. Olyan szituáció, mely gazdasági, környezeti, emberi károkat okozhat. A szoftver vagy hardver rendszer egy komponenséhez köthető valószínűségi alapú hibaforrás. Egyik sem. Kérdés: Mit nevezünk mérföldkőnek? Egy kiemelt teljesítési időpont egy projekt menetében. Az életciklus modellek egyes állomásait nevezzük mérföldkőnek. A mérföldkő a projektek kezdeti fázisára utal. Mérföldkő egy jól meghatározott tevékenység egy projekt menetében. Egyik sem. Kérdés: Fejlesztési projekt esetén mit jelent a függőség? Egy mérföldkőtől kiinduló tevékenységek csak akkor kezdődhetnek el, ha a mérföldkőbe befutó tevékenységek már befejeződtek. A szoftverrendszer egyes moduljai közti összefüggésre és kommunikációra utal. Meghatározza, hogy egy mérföldkő mikortól veheti kezdetét és milyen tevékenységektől függ. Megadja, hogy a szoftverrendszer moduljainak integrálása során mely modulokat és milyen sorrendben építsünk hozzá a rendszerhez. Kérdés: Hogyan ábrázoljuk a mérföldköveket? Lekerekített sarkú téglalap Lekerekített sarkú négyzet Ellipszis Téglalap Négyzet Kérdés: Mire szolgál a tevékenységek és a mérföldkövek grafikus ábrázolása? Időbeli összefüggések, időbeli kapcsolatok leírására. A rendszer modulok összeintegrálásának menetét határozza meg. A különböző életciklus modellek grafikus ábrázolására. Meghatározza a tevékenységek végrehajtásának sorrendjét. Kérdés: Mi igaz az alábbi jelölés esetén? T3, T6 (M3) Az M3 mérföldkő teljesüléséhez T3 és T6 tevékenységek teljesítése szükséges. Az M3 mérföldkőből kiinduló tevékenységekhez T6 teljesülése szükséges. Az M3 mérföldkőből kiinduló tevékenységekhez T3 és T6 tevékenységek teljesülése szükséges. T3 független tevékenység. T6 tevékenység M3 mérföldkő teljesülésétől függ. Kérdés: Mi igaz az ütemezési terv esetén? Felsoroljuk a tevékenységeket, meghatározzuk mindegyiknek az időtartamát. Megadjuk a mérföldköveket. Megadjuk a tevékenységek összefüggését. Grafikusan ábrázolhatjuk az ütemezési gráf segítségével. Megadja, hogy milyen modulokból épül fel a szoftver rendszer. Kérdés: Mivel ábrázolhatjuk grafikusan az ütemezési tervet? Tevékenységi diagram Tevékenységi hálózat Tevékenységi gráf Ütemezési gráf Egyik sem Kérdés: Mi igaz az alábbi tevékenységi diagram (részlet) esetén? A START állapotot pszeudó mérföldkőnek is nevezzük. M2 mérföldkő eléréséhez 24 időegységre van szükség, mert T2 és T3 tevékenységek összideje 24. T2 tevékenység elkezdéséhez 16 időegységre van szükség, mert T1 és M1 összideje 16. M2 mérföldkő eléréséhez szükséges időt úgy kapjuk, ha a tőle függő összes tevékenység és mérföldkő idejét összeadjuk úgy, hogy a mérföldkövek idejét negatívként értelmezzük. Kérdés: Mi igaz a projekt-ütemezési táblázat esetén? Tevékenységenként tartalmazza a tevékenységhez szükséges időt. Tevékenységenként tartalmazza a függőségeket, mely megadja a tevékenység megkezdéséhez szükséges mérföldkövet és a mérföldkő eléréséhez szükséges tevékenységeket. Mérföldkövenként tartalmazza a mérföldkő eléréséhez szükséges időt. Mérföldkövenként tartalmazza a mérföldkő eléréséhez szükséges tevékenységeket. Megadja a projekt tevékenységeinek időrendi lefutását. Kérdés: Mit nevezünk kritikus útnak? Az egymás után elvégzendő tevékenységek azon sorozata, amely meghatározza a projekt teljes időtartamát. Azon tevékenységek sorozata, melyek biztonsági szempontból kiemelt hangsúlyt kapnak a fejlesztés során. Időrendben elvégzendő tevékenységek olyan sorozata, melyek összideje a projekt teljesítéséhez szükséges minimális időt definiálják. A fejlesztés azon tevékenységeinek halmazát, melyek nagymértékben befolyásolják a projekt befejezéséhez szükséges időt. Kérdés: Mit nevezünk pszeudó-mérföldkőnek? Tevékenységi diagramon a START állapotot. Tevékenységi diagramon az END állapotot. Tevékenységi diagramon a nem valódi mérföldköveket. Tevékenységi diagramon azokat az állapotokat, melyek a fejlesztés sikeressége szempontjából minimális kockázatot jelentenek. Tevékenységi diagram tervezése során olyan mérföldkövek, melyek a végleges diagramon nem szerepelnek, csak a tervezést segítik. Tevékenységi diagramon az egyes tevékenységeket. Kérdés: Az alábbi tevékenység diagram részleten mire utal az END állapot melletti 60-as szám? Az END mérföldkő időpontja a kezdéstől számított 60. hét. A projekt a terv szerint 60 hétig fog tartani. A T7 tevékenység befejezéséhez 60 hétre van szükség. A T7 és T8 tevékenység együttes befejezéséhez 60 hétre van szükség. Kérdés: Mi látható az ábrán és mire szolgál? Az ábrán egy Gantt-diagram látható. A projekt ütemezési tervének grafikus megjelenésére szolgál. Az ábrán egy Venn-diagram látható. A projekt tevékenységeinek időbeli sorrendjének leírására szolgál. Az ábrán egy tevékenységi diagram látható. A projekt ütemezési tervében lefektetett tevékenységek és azok időbeli függőségeinek megjelenítésére szolgál. Az ábrán egy esemény diagram látható. Ezen az egyes tevékenységeket egy vízszintes szakaszon ábrázoljuk, ahol a szakaszok egymás alatt helyezkednek el, abban a sorrendben, ahogy a nekik megfelelő tevékenységek követik egymást. Kérdés: A tevékenységi diagram és a Gantt-diagram információ hordozás szempontjából egymással ekvivalens? Igen, mindkettő segítségével az ütemezési tervet ábrázolhatjuk. Igen, mindkettő segítségével a projekt életciklus modelljét ábrázolhatjuk. Igen, a két megnevezés ugyanarra a jelölésmódra utal. Nem, a Gantt-diagram nem ábrázolja a mérföldköveket, szemben az ütemezési diagrammal. Nem, az ütemezési diagram nem ábrázolja a párhuzamosan végzendő tevékenységeket, szemben a Gantt-diagrammal. Kérdés: Mi igaz a tartalékidő esetén? Angol megnevezése a slack time. Tartalék időnek nevezzük, amikor egy tevékenység befejezéséhez a szükséges időn felül további korlátozott idő is rendelkezésre áll úgy, hogy a projekt befejezési idejét nem befolyásolja. A tartalékidőt a Gantt-diagramon grafikusan ábrázoljuk. Angol megnevezése a spare time. A tartalékidőt a tevékenység diagramon grafikusan ábrázoljuk. Tartalékidőnek nevezzük azt, amikor egy tevékenységet az előzetes tervekben megszabott időkorlát alatt sikerül teljesíteni. Kérdés: Az alábbi diagram részlet esetén mely állítások igazak? T3 tevékenység tartalékideje 9 hét. T5 tevékenység tartalékideje 4 hét. T7 tevékenység megkezdéséhez T3, T4 és T5 tevékenységek befejezése szükséges. T1 tevékenység tartalékideje 4 hét. T3 tevékenység tartalékideje 3 hét. T5 tevékenység tartalékideje 8 hét. T5 tevékenység megkezdéséhez T3 és T4 tevékenységek megkezdése szükséges. Kérdés: Mely állítások igazak az alábbi diagram részlet esetén? T6 és T8 tevékenységek együttes tartalékideje 6 hét. T6 tevékenység tartalékideje 6 hét. T8 tevékenység megkezdéséhez T7 tevékenység megkezdése szükséges. T8 tevékenység tartalékideje 6 hét. T7 tevékenység csak T6 tevékenységgel egy időben indítható. Kérdés: Az alábbiak közül melyek nevezhetőek modulnak? Szubrutin Procedúra Függvény Metódus Osztály Kérdés: Mit fejez ki az alábbi egyenlőtlenség? C(f1) > C(f2) Az f1 feladat bonyolultsága nagyobb, mint az f2 feladat bonyolultsága. Az f1 probléma megoldására fordítandó erőfeszítés nagyobb, mint az f2 probléma megoldására fordítandó erőfeszítés. Az f1 forráskód hossza nagyobb, mint az f2 forráskód hossza. Az f1 modul funkciópontja nagyobb, mint az f2 modul funkciópontja. Kérdés: Mi következik a C(f1) > C(f2) egyenlőtlenségből? E(f1) > E(f2) f1 < f2 E(f1) < E(f2) E(f1) = E(f2) C(f1+f2) > C(f1) + C(f2) E(f1+f2) > E(f1) + E(f2) Kérdés: Mi következik a C(f1+f2) > C(f1) + C(f2) egyenlőtlenségből? E(f1+f2) > E(f1) + E(f2) E(f1+f2) < E(f1) + E(f2) C(f1) > C(f2) C(f1) < C(f2) E(f1) > E(f2) E(f1) < E(f2) Kérdés: Milyen következtetést vonhatunk le a C(f1+f2) > C(f1) + C(f2) és E(f1+f2) > E(f1) + E(f2) egyenlőtlenségekből? Könnyebb megoldani egy komplex feladatot úgy, hogy kezelhető részekre bontjuk, és a részfeladatokat külön-külön oldjuk meg. A szoftver modulok integrálása után nagymértékben megnőhet a rendszer komplexitása. Nem elegendő a szoftver modulok önálló tesztelése, a teljes rendszert is validálni kell, mert a rendszer integrálása után további, eddig felfedetlen hibák jöhetnek elő. A szoftver rendszer költsége nagymértékben növekedhet az integrálási folyamat során. Kérdés: Mely állítások igazak az alábbiak közül? Minél több modulra bontjuk a szoftvert, annál kisebb erőfeszítés kell egy-egy modul kifejlesztéséhez. Az integrálási költség a modulok számának növekedésével exponenciálisan növekszik. Az integrálási költség a modulok számának növekedésével lineárisan növekszik. Minél több modulra bontjuk a szoftvert, annál több erőfeszítés kell egy-egy modul kifejlesztéséhez. Az integrálási költség a modulok számának növekedésével logaritmikusan növekszik. Kérdés: Mi állapítható meg az alábbi ábráról? Az 1. görbe mutatja az integrálási költséget. A 2. görbe mutatja a fejlesztési költséget. A 3. görbe mutatja a teljes szoftver költséget. Az M érték megadja, hogy optimális esetben hány modulra bontsuk a szoftvert. A 3. görbe mutatja a projekt maximális költségét. A 2. görbe mutatja az integrálási költséget. Az 1. görbe mutatja a fejlesztési költséget. Az M értéke megadja az optimális fejlesztési ráfordítást. Kérdés: A ráfordítási költségek számítása esetén mi igaz az M értékre? Megadja az optimális modulszámot. Értéke nagy ráfordítás árán számolható ki. Megadja a teljes szoftverköltséget. Értéke hatékonyan számolható. Megadja az optimális ráfordítási költséget. Kérdés: Ráfordítási költségek esetén minek az ismeretében határozhatjuk meg (közelítőleg) M értékét? Integrálási költség Fejlesztési költség Teljes szoftver költség Tesztelési költség M értékét nem lehet előzetes számításokkal megbecsülni. Kérdés: Mely állítás igaz az alábbi ábra esetén? „a” fan-in értéke 1. „g” fan-out értéke 1. „F” fan-in értéke 0. „d” fan-in értéke 2. „e” fan-out értéke 4. „i” fan-in értéke 7. „h” fan-in értéke 3. Kérdés: Mely állítás igaz az alábbi ábra esetén? Az „r” modulnak a legnagyobb a fan-in értéke. Az „m” modulnak a legnagyobb a fan-out értéke. A „n” modul fan-in értéke 3. Az „i” modulnak a legnagyobb a fan-out értéke. Az „m” modulnak a legnagyobb a fan-in értéke. Kérdés: Mely állítás igaz a szoftver hívási gráf esetén? A modulokat téglalapok formájában ábrázoljuk. Mindegyik modul hívhat más modulokat. Mindegyik modult hívhatja más modul. A modulok közti hívást nyilak segítségével ábrázoljuk. Egy modul tartalmazhat más modulokat. Kérdés: Mely állítás igaz az alábbi ábra esetén? Az „m-p-r” egy hívási lánc. A „b-h” egy hívási lánc Az „i-f-d-a” egy hívási lánc A gráf hívási mélysége 4. A „k” modul hívási szélessége 5. Kérdés: Milyen jellemző tulajdonságai vannak egy hívási gráfnak? Hívási lánc Hívási út hossza Hívási magasság Hívási mélység hossza Hívási kör Kérdés: Milyen jellemző tulajdonságai vannak egy hívási gráfnak? Hívási mélység Hívási szint Hívási szélesség Hívási távolság Hívási kör Kérdés: Mely állítás igaz az alábbi ábra esetén? M=18 H=22 S=40 W=7 S=396 S=29 S=126 Kérdés:Hívási gráf esetén mi határozza meg a rendszerméretet? Modulok száma Hívások száma Rendszer mélysége Rendszer szélessége Hívási mélység Hívási szélesség Hívási szint Kérdés: Az alábbiak közül melyek a teljes rendszerre vonatkozó mérőszámok? Code length Line of code Function point Card és Glass mérőszámai Henry és Kafura mérőszámai Kérdés: Az alábbiak közül melyek a forráskódra vonatkozó mérőszámok? Halstead-számok McCabe-féle szám KLOC Henry és Kafura mérőszámai Function point Kérdés: Az alábbiak közül melyek az architektúrára vonatkozó mérőszámok? Card és Glass mérőszámai Henry és Kafura mérőszámai MLOC Line of Code Halstead-számok Kérdés: Az alábbi állítások közül melyek igazak? A KLOC a teljes rendszerre vonatkozik. A Halstead-számok a forráskódra vonatkoznak. Henry és Kafura mérőszámai a teljes rendszerre vonatkoznak. A McCabe-féle szám a forráskódra vonatkozik. Card és Glass mérőszámai a teljes rendszerre vonatkoznak. Kérdés: Az alábbiak közül melyek mérőszámok? Funkció-orientált szám McCabe-féle szám Henry és Glass mérőszámai Kafura-féle mérőszámok Constructive Model of Cost Kérdés: Mit ad meg a LOC? A forráskód sorainak a számát. A forráskód utasításainak a számát. A forráskódban szereplő logikai elágazások számát. A forráskódban szereplő különálló blokkok számát. A forráskód karaktereinek számát. Kérdés: Mely állítás igaz az alábbiak közül? A LOC a Line of Code rövidítése. A LOC megadja a forráskód sorainak a számát. A LOC a teljes rendszerre vonatkozó mérőszám. A LOC megadja a forráskód parancsainak számát. A LOC a List of Commands rövidítése. A LOC a forráskódra vonatkozó mérőszám. Kérdés: Funkciópont számítás esetén milyen működési részterületekkel dolgozunk? Felhasználói bemenetek száma. Felhasználói kimenetek száma. Szoftver interakciók száma. Kezelt memóriaterület mérete. Szoftver modulok száma. Kérdés: Funkciópont számítás esetén milyen működési részterületekkel dolgozunk? Felhasználói lekérdezések száma. A kezelt fájlok száma. Külső interfészek száma. Felhasznált osztályok száma. Modul kapcsolatok száma. Kérdés: Az alábbiak közül melyek igazak? A funkciópont funkció-orientált szám. A funkciópont a teljes rendszerre vonatkozó szám. A funkciópont számítás során a fun-in és fun-out értékeket vesszük alapul. A funkciópont a forráskódra vonatkozó szám. A funkciópont számítás során 4 meghatározott működési részterületet veszünk alapul. Kérdés: Az alábbiak közül melyek igazak? Funkciópont számításnál 5 meghatározott működési részterületet veszünk alapul. Egy szoftverhez több funkciópont tartozik. Egy szoftverhez egy meghatározott funkciópont tartozik. Funkciópont számítás során tetszés szerint súlyozzuk a részterületeket. Minden szoftverhez 5 funkciópont tartozik. Kérdés: Egy szoftverre vonatkozó funkciók száma és azok súlyértékei láthatóak pontosvesszővel tagolva, ahol az első érték a funkció száma, második a súlyérték. Milyen funkciópontokkal rendelkezik a szoftver? 2;1 3;2 1;1 4;2 2;5 Egyik sem, az adatok hibásak. 2, 6, 1, 8, 10, 27 2, 6, 1, 8, 10, 960 3, 5, 2, 6, 10, 26 3, 5, 2, 6, 10, 26, 1800 Kérdés: Milyen alapszámok találhatóak Halstead mérőszám rendszerében? n1: a programban található különböző műveletek (operátorok), ill. műveleti jelek száma. n2: a programban található különböző operandusok száma. n1: a programban található különböző utasítások száma. n2: a programban található különböző műveletek (operátorok), ill. műveleti jelek száma. n1: a programban található logikai elágazások száma. Kérdés: Milyen alapszámok találhatóak Halstead mérőszám rendszerében? N1: az összes előforduló műveletek, ill. műveleti jelek száma a programban. N2: az összes előforduló operandusok száma a programban. N1: az összes előforduló logikai elágazás a programban. N2: az összes előforduló utasítás a programban. N1: az összes előforduló vezérlési szerkezet a programban. Kérdés: Az alábbiak közül melyek igazak? A Halstead-féle mérőszámok a forráskódra vonatkoznak. Halstead 4 alapszámot használ a mérőszám rendszerében. A Halstead-féle mérőszámok a teljes rendszer összetettségének mérésére szolgálnak. Halstead az utasítások számából határozza meg mérőszámát. Halstead a logikai elágazások számából határozza meg mérőszámát. Kérdés: Az alábbiak közül melyek igazak? Halstead 3 mérőszámot definiált. Halstead mérőszámai a modulok forráskódjára vonatkozik. A Halstead-féle mérőszámot a teljes rendszerre nézve is értelmezhetjük. A Halstead-féle mérőszámok a forráskódban szereplő logikai elágazásokra épülnek. Halstead 4 mérőszámot definiált. Kérdés: Hogyan számítható a forráskód becsült hossza Halstead mérőszáma alapján? N(b) = n1 * log2 n1 + n2 * log2 n2 N(b) = N * log2 (n1 + n2) N(b) = N1 + N2 N(b) = (N1 + N2) * log2 (n1 + n2) N(b) = log2 n1 * log2 n2 Kérdés: Hogyan számítható a forráskód aktuális hossza Halstead mérőszáma alapján? N = N1 + N2 N = n1 * log2 n1 + n2 * log2 n2 N = log2 n1 * log2 n2 N = (N1 + N2) * log2 (n1 + n2) N = N(b) * log2 (n1 + n2) Kérdés: Hogyan számítható a program tárgykódjának volumene Halstead mérőszáma alapján? V = N * log2 (n1 + n2) V = N1 + N2 V = n1 * log2 n1 + n2 * log2 n2 V = log2 n1 * log2 n2 V = (n1 + n2) * log2 (n1 + n2) Kérdés: Halstead mérőszámai közül mit fejez ki a „V” értéke? Az elkészült program bonyolultságát. A programozó szellemi ráfordítását. A program tárgykódjának számított volumenét. A forráskód becsült hosszát. A szoftver rendszer becsült méretét. Kérdés: Hogyan számolható MC értéke? MC = D + 1 MC = n1 * log2 n1 + n2 * log2 n2 MC = fan-out(i)^2 MC = S(i) + D(i) MC = L(i) * (fan-in(i) + fan-out(i))^2 Kérdés: Az alábbiak közül mely igaz? A McCabe-féle szám a forráskódra vonatkozik. A McCabe-féle szám a logikai döntések számától függ. A McCabe-féle szám a program különböző utasítás-végrehajtási lehetőségeinek a számát adja meg. A McCabe-féle szám az architektúrára vonatkozik. A McCabe-féle szám a forráskód hosszától függ. Kérdés: Milyen mérőszámokat vezetett be Card és Glass? Strukturális komplexitás Adat-komplexitás Információ-komplexitás Logikai komplexitás Erőforrás komplexitás Kérdés: Milyen mérőszámokat vezetett be Card és Glass? Modul-komplexitás Architekturális komplexitás Rendszer komplexitás Logikai komplexitás Teljes szoftver komplexitás Kérdés: Card és Glass mérőszámai esetén mi az S(i) érték? S(i) = fan-out(i)^2 S(i) = v(i) / (fan-out(i) + 1) S(i) = C(i) + D(i) S(i) = fan-in(i) / fan-out(i)^2 S(i) = C(1) + C(2) + C(3) + … + C(M-1) + C(M) Kérdés: Card és Glass mérőszámai esetén mi a D(i) érték? D(i) = v(i) / (fan-out(i) + 1) D(i) = C(1) + C(2) + C(3) + … + C(M-1) + C(M) D(i) = C(i) + S(i) D(i) = fan-out(i)^2 D(i) = fan-in(i) / fan-out(i)^2 Kérdés: Card és Glass mérőszámai esetén mi a C(i) érték? C(i) = S(i) + D(i) C(i) = D(1) + D(2) + D(3) + … + D(M-1) + D(M) C(i) = v(i) / (fan-out(i) + 1) C(i) = fan-in(i) / fan-out(i)^2 C(i) = fan-out(i)^2 Kérdés: Card és Glass mérőszámai esetén mi az AC érték? AC = C(1) + C(2) + C(3) + … + C(M-1) + C(M) AC = D(1) + D(2) + D(3) + … + D(M-1) + D(M) AC = S(1) + S(2) + S(3) + … + S(M-1) + S(M) AC = C(1) * C(2) * C(3) * … * C(M-1) * C(M) AC = D(1) * D(2) * D(3) * … * D(M-1) * D(M) AC = S(1) * S(2) * S(3) * … * S(M-1) * S(M) Kérdés: Card és Glass mérőszámai esetén mi a v(i) érték? Az i-edik modul be- és kimeneti hívási paramétereinek száma. Az i-edik modul forráskódjának mérete. Az i-edik modul logikai elágazásainak száma. Az i-edik modul adat-komplexitásának a mérete. Az i-edik modul változóinak száma. Kérdés: Egy szoftver modul szétágazásainak száma 3, input és output változóinak együttes darabszáma 8. Mekkora a modul strukturális komplexitása? 9 3 4 2 A megadott információból nem meghatározható. Kérdés: Egy szoftver modul szétágazásainak száma 3, input és output változóinak együttes darabszáma 8. Mekkora a modul adat-komplexitása? 2 9 3 4 A megadott információból nem meghatározható. Kérdés: Egy szoftver modul strukturális komplexitása 9, adat-komplexitása 2, input és output változóinak együttes darabszáma 8. Mekkora a modul-komplexitása? 11 18 7 9 A megadott információból nem meghatározható. Kérdés: Az alábbi ábra esetén mi lehet a koordináta tengelyek neve? Vízszintes tengely: architekturális komplexitás, függőleges tengely: Hiba / 1 KLOC Vízszintes tengely: architekturális komplexitás, függőleges tengely: adat-komplexitás Vízszintes tengely: teljes szoftver komplexitás, függőleges tengely: Hiba / 1 KLOC Vízszintes tengely: teljes szoftver komplexitás, függőleges tengely: adat-komplexitás Vízszintes tengely: architekturális komplexitás, függőleges tengely: modul-kompexitás Vízszintes tengely: teljes szoftver komplexitás, függőleges tengely: modul-komplexitás Kérdés: Card és Glass kutatásaik eredményeként milyen kapcsolatot vélt felfedezni az architekturális komplexitás és a szoftver hibák között? A két mérték között lineáris kapcsolat van. A két mérték között exponenciális kapcsolat van. A két mérték között logaritmikus kapcsolat van. A két mérték között nem találtak összefüggést. A kutatást nem Card és Glass végezte. Kérdés: Az alábbiak közül mely állítás igaz? Card és Glass mérőszámai nem veszik figyelembe az összeágazásokat. Henry és Kafura mérőszámai figyelembe veszik az összeágazásokat. Card és Glass mérőszámai figyelembe veszik a szétágazásokat. Henry és Kafura mérőszámai figyelembe veszik a szétágazásokat. Card és Glass mérőszámai figyelembe veszik az összeágazásokat. Henry és Kafura mérőszámai nem veszik figyelembe az összeágazásokat. Card és Glass mérőszámai nem veszik figyelembe a szétágazásokat. Henry és Kafura mérőszámai nem veszik figyelembe a szétágazásokat. Kérdés: Miként definiálta Henry és Kafura a komplexitási mérőszámot? HKM(i) = L(i) * (fan-in(i) + fan-out(i))^2 HKM(i) = fan-in(i) / fan-out(i)^2 HKM(i) = fan-in(i) + fan-out(i) HKM(i) =fan-in(i)^2 * fan-out(i)^2 HKM(i) = v(i) / (fan-out(i) + 1) Kérdés: Henry és Kafura mérőszámában mi az L(i) érték? Az i-edik modul forráskódjának hossza. Az i-edik modul felhasználói be- és kimeneteinek száma. Az i-edik modul fan-in és fan-out értékeinek összege. Az i-edik modul forráskódjában szereplő logikai elágazások száma. Kérdés: McCabe miként definiálta a teljes rendszer komplexitását? McCabe nem definiálta a teljes rendszer komplexitását. MC = MC(1) + MC (2) + MC (3) + … + MC (M-1) + MC (M) AC = C(1) + C(2) + C(3) + … + C(M-1) + C(M) AC = AC(1) + AC(2) + AC(3) + … + AC(M-1) + AC(M) Kérdés: Az alábbiak közül mely igaz? A HKM az architektúrára vonatkozik. A HKM az összeágazások és a szétágazások számát is figyelembe veszi. A HKM megadja a teljes rendszer komplexitást. A HKM növekedése az integrálási és tesztelési költségek növekedésével jár. A HKM csak az összeágazásokat veszi figyelembe. A HKM csak a szétágazásokat veszi figyelembe. A HKM a teljes rendszerre vonatkozik. Kérdés: Egy szoftver projekt tervének milyen fő összetevői vannak? A fejlesztés célja. Rendelkezésre álló erőforrások. Rendelkezésre áll pénzügyi források. Fejlesztési életciklus modellek. Szoftver modulok terve. Fejlesztési és felhasználói dokumentációk. Kérdés: Mi a Rayleigh-függvény? Megadja a szükséges emberi erőforrást az idő függvényében. Megadja a szükséges emberi erőforrást az projekt méretének függvényében. Megadja a szükséges pénzügyi erőforrást az idő függvényében. Megadja a szükséges pénzügyi erőforrást a projekt méretének függvényében. Kérdés: Minek a becslésére lehet alkalmas a Rayleigh-eloszlás? Emberi ráfordítás Utazás Számítógép felhasználás Szoftver eszközök felhasználása Irodai eszközök felhasználása Szoftver költségek Fejlesztési idő Kérdés: Az alábbiak közül melyek igazak? A Rayleigh-eloszlás az emberi ráfordítást határozza meg az idő függvényében. A Rayleigh-eloszlást RC(t)-vel jelöljük, ahol t az idő, RC pedig a Rayleigh Consumption rövidítése. A Rayleigh-eloszlásban az időnek nullától nagyobb értéket kell felvennie. A Rayleigh-eloszlás függvényében található „k” konstans egy a projektre jellemző érték, egy kritikus pontot határoz meg a függvényben. A Rayleigh-eloszlás függvényében található „v” konstans egy a projektre jellemző érték, a szoftver volumenéről ad információt. Kérdés: Mi az RC(t)? RC(t) = t / (k^2) * e^(-t^2 / (2 * k^2)) RC(t) = (k^2) / t * e^(t^2 / (2 * -k^2)) RC(t) = v(t) / (fan-out(t) + 1) RC(t) = v(t) / (fan-out(t) * fan-in(t))^2 Kérdés: Hogyan nevezné el az egyes tengelyeket? Mit jelöl a „k” érték? Vízszintes tengely: idő, függőleges tengely: emberi ráfordítás A „k” érték egy a projektre jellemző konstans tulajdonság, „k” időpontban lesz legnagyobba projekt erőforrásigénye. Vízszintes tengely: idő, függőleges tengely: anyagi ráfordítás Vízszintes tengely: költség, függőleges tengely: emberi ráfordítás A „k” érték egy a projektre jellemző konstans tulajdonság, azt az időpontot jelenti, amikor előreláthatólag kritikus fejlesztési fázishoz érkezik a projekt. A „k” érték egy a projektre jellemző konstans tulajdonság, azt a költséghatárt adja meg, mely alatt a projekt még nyereséges lehet. Kérdés: Mi az AVC? Kódsorok átlagos száma funkciópontonként. Parancsok átlagos száma funkciópontonként. Funkciópontok átlagos száma kódsoronként. Funkciópontok átlagos száma parancsonként. Modulok átlagos száma projektenként. Kérdés: Mely állítások igazak az alábbi képlet esetén? Ráfordítás = A * W * Méret^B Az „A” egy konstans tényező, amelynek értéke függ a fejlesztendő szoftver jellegétől, típusától, bonyolultságától. A „Méret” a szoftverre vonatkozik. Lehet utasításszám, a kódsorok száma, vagy a rendszer összesített funkciópontja. A „W” a projektben résztvevő személyek átlagos száma. A „B” kitevő értéke általában 3 és 15 közé eső szám, a projekt bonyolultságától függően. Az egyenlet megadja a teljes szoftver projekt emberi ráfordítását. Kérdés: Mi igaz az alábbi kifejezés esetén? 4E → 2H, 8E → 4H, 6E → 3H A projekt időtartama 11 hónap. A projekt időtartama 58 hónap A projekt időtartama 58 hét. A projekt időtartama 11 hét. A projekt időtartama 4 hónap. A projekt időtartama 4 hét. Kérdés: Az alábbi esetben mennyi LSZ értéke? 5E → 2H, 9E → 1H, 3E → 2H 5E 15E 5H 15H Kérdés: Mi az LSZ értéke? (E_1 * H_1 + E_2 * H_2 + … + E_n * H_n) / (H_1 + H_2 + … + H_n) (H_1 + H_2 + … + H_n) / (E_1 * H_1 + E_2 * H_2 + … + E_n * H_n) (E_1 * H_1 + E_2 * H_2 + … + E_n * H_n) / (H_1 * H_2 * … * H_n) (E_1 * H_1 + E_2 * H_2 + … + E_n * H_n) / (E_1 + E_2 + … + E_n) (E_1 + E_2 + … + E_n) / (E_1 * H_1 + E_2 * H_2 + … + E_n * H_n) Kérdés: Mi az NH értéke? H_1 + H_2 + … + H_n E_1 + E_2 + … + E_n H_1 * H_2 * … * H_n E_1 * E_2 * … * E_n EH_1 + EH_2 + … + EH_n EH_1 * EH_2 * … * EH_n Kérdés: Egy projekt esetén LSZ = 5E. Mely projekt megoszlás esetén igaz ez? 7E → 1H, 4E → 2H 5E → 2H, 9E → 1H, 3E → 2H 2E → 1H, 3E → 2H 8E → 1H, 2E → 2H 2E → 3H, 4E → 1H, 4E → 1H Kérdés: Az alábbiak közül melyik lehet az emberhónap a COCOMO-modell esetén? EH = 2,4 * KLOC^1,05 EH = 3 * KLOC^1,2 EH = 2,5 * KLOC^0,38 EH = 1,12 * KLOC^2,5 Kérdés: A COCOMO-modell alapján miként kaphatjuk meg az naptári hónap értékét? NH = c * EH^d NH = c * a^d * KLOC^(b*d) NH = a * KLOC^b NH = c^d * MLOC^d NH = c * (a * KLOC^d)^b Kérdés: Boehm a modelljében milyen kategóriákba sorolta a szoftvereket? Normál szoftverek Összetett szoftverek Beágyazott szoftverek Rendszer szoftverek Üzleti célú szoftverek Mesterséges intelligencia szoftverek Kérdés: Az alábbi ábra esetén milyen címkéket írni a számokkal jelzett helyekre? 1: NH, 2: EH, 3: KLOC 1: EH, 2: NH, 3: KLOC 1: NH, 2: LSZ, 3: KLOC 1: RC, 2: EH, 3: Idő 1: RC, 2: NH, 3: Idő Kérdés: A COCOMO-modell alapján miként kaphatjuk meg az átlagos ráfordítási létszámot? LSZ = (a * KLOC^b) / (c * a^d * KLOC^(b*d)) LSZ = a^(1 - d) / c * KLOC^(b*(1 - d)) LSZ = c * a^d * KLOC^(b*d) LSZ = a * KLOC^b LSZ = c * (a * KLOC^b)^d Kérdés: Boehm modelljében mi az alapvető különbség a normál és az összetett szoftver között? A normális szoftver nem függ a környezettől, nincsenek kapcsolatai, míg az összetett szoftver környezetfüggő, külső kapcsolatokkal rendelkezik. A normál szoftver komplexitása alacsony, jellemzően 1-2 modulból tevődik össze, ezzel szemben az összetett szoftver sok modulos, jellemzően nagy volumenű fejlesztés. A normál szoftver külső interfészek segítségével kommunikál külső hardver eszközökkel, míg az összetett szoftver magába a célhardverbe integrálva működik. Boehm modelljében nem szerepel normál szoftver. Kérdés: Mely állítás igaz a COCOMO-modell esetén? Az EH görbéje gyorsabban növekszik, mint a kódméret. Az NH görbe azt tükrözi, hogy a fejlesztés kezdeti szakaszában több idő kell a kódoláshoz. Ha ismerjük EH értékét és tisztázott, hogy hány ember vesz részt a szoftver-projektben, akkor NH értéke jól becsülhető. Az EH görbe a projekt későbbi szakaszában egyre lassabban növekszik, ami arra utal, hogy a szoftver befejezéséhez egyre kevesebb plusz idő szükséges. AZ EH és NH értéke függ a kódmérettől és a projektben résztvevő emberek számától. Kérdés: Mi a hibamodell? Azon szoftver-hibák halmaza, amelyeknek a felfedésére irányul a teszttervezés. A szoftver bemeneti adatokkal való sorozatos ellátása és a kimeneti válaszadatok megfigyelése. Bemeneti adatok olyan rendezett sorozata, melynek hatására az adott hibát tartalmazó szoftver a legutolsó adatkombinációra a helyestől eltérő (hibás) kimeneti adatkombinációval válaszol. Ebben a modellben egy adott program (szoftver) az összes lehetséges bemeneti adatból előállítja az összes lehetséges kimeneti adatot. Kérdés: Mi a tesztelés? A szoftver bemeneti adatokkal való sorozatos ellátása és a kimeneti válaszadatok megfigyelése. Bemeneti adatok olyan rendezett sorozata, melynek hatására az adott hibát tartalmazó szoftver a legutolsó adatkombinációra a helyestől eltérő (hibás) kimeneti adatkombinációval válaszol. Ebben a modellben egy adott program (szoftver) az összes lehetséges bemeneti adatból előállítja az összes lehetséges kimeneti adatot. Azon szoftver-hibák halmaza, amelyeknek a felfedésére irányul a teszttervezés. Kérdés: Mit írna a számokkal jelzett helyekre? 1: szoftver, 2: hibás működést okozó bemenetek, 3: hibás kimenetek, 4: bemenetek, 5: kimenetek 1: tesztmodell, 2: detektálható hiba, 3: detektált hibák, 4: tesztkészlet, 5: kimenetek 1: interfész, 2: hívó szoftver funkció, 3: fogadó szoftver funkció, 4: szoftver modul, 5: szoftver modul 1: hibamodell, 2: egy hiba tesztje, 3: detektálható hiba, 4: tesztkészlet, 5: tesztmodell Kérdés: Mely állítás hamis? A tesztelés az a folyamat, amikor egy szoftver detektálható hibák okát keressük. A hibamodell megadja a szoftverben található hibákat. A szoftver hibák mindig kihatással vannak a szoftver működésére. Egy hibáról akkor mondjuk, hogy detektálható, ha legalább egy tesztje létezik. Kérdés: Mi a fault coverage? Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeket a tesztkészlet detektálni tud. Teszteknek olyan összessége, amely a szoftver mindegyik előre feltételezett és detektálható hibájának tesztjét magában foglalja. A bemeneti tesztsorozat és az elvárt válaszjelek meghatározása egy előre feltételezett hibahalmazra nézve. Bemeneti adatok olyan rendezett sorozata, melynek hatására az adott hibát tartalmazó szoftver a legutolsó adatkombinációra a helyestől eltérő (hibás) kimeneti adatkombinációval válaszol. Kérdés: Mely állítás igaz? A fault coverage esetén a cél a 100%-os lefedés. A tesztkészlet esetén a cél a 100%-os lefedés. A tesztkészlet lefedettsége 100%-os. A fault coverage lefedettsége 100%-os. Kérdés: Egy megrendelő olyan szoftvert szeretne, aminek segítségével tetszőleges háromszög és tetszőleges négyszög területét tudja kiszámolni. Ezen megrendelés esetén mely állítások bizonyulnak igaznak? Specifikációs hiba, ha a szoftver csak háromszögek területét képes kiszámítani. Specifikációs hiba, ha a szoftver képes kiszámolni a négyszögek kerületét. Programozási hiba, ha a szoftver bizonyos háromszögek esetén hibás kimenetet ad. Specifikációs hiba, ha a szoftver negatív értékeket is elfogad bemenetként. Specifikációs hiba, ha a szoftver csak egész értékeket kezel. Programozási hiba, ha a szoftver nem képes kiszámolni egy tetszőleges deltoid területét. Kérdés: A szoftverfejlesztés minőségének javítására irányuló hibaelemzésnek mi az utolsó három lépése és milyen sorrendben követik egymást? 4. Mindegyik kategóriához meghatározzák a teljes javítási költséget. 5. A kapott adatok alapján megvizsgálják azokat a kategóriákat, amelyek a cég számára a legnagyobb költséget okozták. 6. Terveket dolgoznak ki arra vonatkozóan, hogy miként módosítsák azokat a folyamatokat, amelyek a leginkább költséges kategóriákra vezettek. 4. Megállapítják az egyes kategóriákba eső hibák számát, és a kategóriákat sorba rendezik, csökkenő sorrendben. 5. Mindegyik kategóriához meghatározzák a teljes javítási költséget. 6. Feljegyzik az egyes hibák kijavítására fordított költséget. Kérdés: Hogyan hívhatjuk még a fekete doboz tesztelést? Funkcionális tesztelés Vasdoboz tesztelés Iron-box testing Black-box testing Glass-box testing White-box testing Kérdés: Hogyan hívhatjuk még a fehér doboz tesztelést? Strukturális tesztelés White-box testing Iron-box testing Sand-box testing Glasses-box testing Kérdés: Az alábbiak közül mely állítás igaz? Funkcionális tesztelés esetén a szoftvert bemeneti értékekkel látjuk el és figyeljük a kapott kimeneti értékeket. Funkcionális tesztelés esetén a szoftvert a külső viselkedésében vizsgáljuk. Funkcionális tesztelés esetén a szoftver összes specifikált funkciójának vizsgálata a cél. Funkcionális tesztelés esetén a szoftver modulok (funkciók) tárgykódjának helyességét vizsgáljuk. Funkcionális tesztelés esetén a szoftver kódjának logikai felépítését vizsgáljuk. Kérdés: Az alábbiak közül mely állítás igaz? Strukturális tesztelés esetén a szoftver forráskódját vizsgáljuk. Strukturális tesztelés esetén a szoftver belső működésének a végigkövetése a cél. Strukturális tesztelés esetén a szoftvert bemeneti értékekkel látjuk el és figyeljük a kapott kimeneti értékeket. Strukturális tesztelés esetén a szoftver összes specifikált funkciójának vizsgálata a cél. Strukturális tesztelés esetén a szoftver modulok minél több bemenettel való ellátása a cél. Kérdés: Mely tesztelési módszer vázlatos diagramja látható a képen? Funkcionális tesztelés Black-box testing Iron-box testing Glass-box testing Sand-box testing Kérdés: Mely tesztelési módszer vázlatos diagramja látható a képen? Strukturális tesztelés Üvegdoboz tesztelés White-box testing Iron-box testing Sand-box testing Kérdés: Az alábbi ábra esetén miként nevezné el a függőleges tengelyt? További hibák létezésének valószínűsége. További hibák száma. Szoftver modulok száma. Modul komplexitás mértéke. Kódméret KLOC-ban. Kérdés: Tegyük fel, hogy egy szoftver két modulból épül fel: A és B modul. Az A modulban eddig két hibát találtunk, a B modulban pedig nyolcat. Glenford Myers megfogalmazása szerint mely állít helyes? Ha a B modult még nem vizsgáltuk meg alaposan, akkor nagyobb valószínűséggel találunk a B modulban hibát, mint az A modulban. Mivel az A modulban lényegesen kevesebb hibát detektáltunk, mint a B modulban, ezért nagyobb a valószínűsége, hogy az A modulban további hibákat találunk. A hibák felfedésével egyre kisebb a további hibát felfedésének a valószínűsége, ezért az A modulban nagyobb valószínűséggel találunk még hibát. Pusztán a már detektált hibák számából nem lehet becslést adni a szoftver modulokban található felfedetlen hibák számára. Ha ugyanakkora energia befektetéssel a B modulban több hibát találtunk, akkor valószínűleg az A modul már elég alaposan letesztelt, így a további hibák valószínűleg a B modulban lesznek. Kérdés: Az integrációs tesztelésnek milyen megoldásai léteznek? Együttes tesztelés Big bang testing Inkrementális tesztelés Strukturális tesztelés Funkcionális tesztelés Iron-box testing Kérdés: Mit jelent egy modul izolált tesztelése? A modult a környezetéből kiragadva, függőségeit helyettesítve teszteljük. A modult mindentől függetlenül, önmagában teszteljük. A modult oly módon teszteljük, hogy annak forráskódját a tesztelés során teljes mértékben bejárjuk. A tesztelés során csak a bemeneti értékekre adott kimeneti értékeket vesszük figyelembe. Kérdés: Az alábbi ábra esetén miként nevezné el a tesztelt modult hívó modult, és a tesztelt modul által hívott modulokat? A tesztelt modult a meghajtó modul hívja. A tesztelt modul a csonk modulokat hívja. A tesztelt modult a fő modul hívja. A tesztelt modul az izolált modulokat hívja. A tesztelt modult a szülő modul hívja. Kérdés: Mi igaz a meghajtó modul esetén? Egy modul izolált ellenőrzése során használjuk. A tesztelendő modult meghívó modult helyettesítjük vele. A tesztelendő modul információt szolgáltat a meghajtó modul számára. Együttes tesztelés során, azon belül a hívási hierarchia szerinti vizsgálatnál használjuk. A tesztelendő modult helyettesítjük vele. A strukturális tesztelés során használjuk. Kérdés: Mi igaz a csonk modul esetén? Inkrementális tesztelés során, azon belül a hívási hierarchia szerinti vizsgálatnál használjuk. A tesztelendő modul által meghívót modulokat helyettesítjük vele. Egy modul izolált ellenőrzése során használjuk. Azokat a modulokat hívjuk így, melyek a végleges rendszerben nem fognak szerepelni, csak a tesztelés során használtuk fel, egy másik modul vizsgálata során. A Funkcionális tesztelés során használjuk. A tesztelendő modult helyettesítjük vele. Kérdés: Mely állítás igaz? A csonk modulnak az esetek többségében valamilyen számítást is kell végeznie, mielőtt visszaadná a vezérlést a hívó félnek. Előfordulhat, hogy a csonk modulok hívása több szinten keresztül zajlik. Érdemes külön meghajtó modult írni a fehér és fekete dobozos tesztelés esetén. Egy meghajtó modulnak kettős feladata van: meghívja a tesztelendő modult és ellátja vezérlési paraméterekkel. A csonk modulnak elegendő csupán visszaadnia a vezérlést a hívó fél számára, ezzel tesztelhető, hogy megfelelően működik kapcsolatok. Kérdés: Mely állítás igaz? Az együttes tesztelést célszerű használni, ha a rendszer működése jól áttekinthető. Az együttes tesztelést célszerű használni, ha a fejlesztés magas minőségi szinten, a hibaelkerülési elvek messzemenő betartásával ment végbe. Az együttes tesztelés hátránya a hibalokalizálás nehéz kivitelezhetősége. Az együttes tesztelést a gyakorlatban nem alkalmazzuk, csupán szemléltető eszközként használjuk a big bang káros következményeinek bemutatására. Az együttes tesztelést csak olyan esetben célszerű használni, ha a modulok kellő körültekintéssel lettek tesztelve, beleértve a modulok kapcsolatát megvalósító interfészeket is. Kérdés: Egy inkrementális tesztelés első három fázisa látható. Mi mondható el róla? 1) {A, B} modulok: T1, T2, T3 tesztek. 2) {A, B, C} modulok: T1, T2, T3, T4 tesztek. 3) {A, B, C, D} modulok: T1, T2, T3, T4, T5 tesztek. Ezt a tesztelési módszert regresszív tesztelésnek nevezzük. Ezt a tesztelési módszert regressziós tesztelésnek nevezzük. Ezt a tesztelési módszert visszaható tesztelésnek nevezzük. Ezt a tesztelési módszert architekturális tesztelésnek nevezzük. Ezt a tesztelési módszert rekurzív tesztelésnek nevezzük. Kérdés: Vegyük az alábbi inkrementális tesztelés első kettő fázisát. Tegyük fel, hogy az első menetben az A és a B modulok tesztelésére szolgáló T1 teszt sikeresen lezajlott, nem talált hibát. Előfordulhat, hogy a második menetben T1 mégis talál hibát? 1) {A, B} modulok: T1 teszt. 2) {A, B, C} modulok: T1, T2, T3, T4 tesztek. Igen, a beépülő C modul kölcsönhatásai végett újabb hibák kerülhetnek felszínre az A és B modulban. Igen, a beépülő C modul szintén tartalmazhat hibákat, amiket kimutathat a T1 teszt. Nem, a második menetben T1 teszt nem kerül végrehajtásra, csak az újonnan belépő T2, T3 és T4 tesztekkel vizsgálunk. Attól függ, hogy a beépítésre került C modul milyen kapcsolatban áll az A és a B modulokkal. Nem, mert a T1 teszt kizárólag az A és a B modul kapcsolatát vizsgálja, ezért a további modulok beépítése nincs kihatással. Kérdés: Előfordulhat, hogy tesztelés során nincs szükség meghajtó modulokra csak csonk modulokra? Igen, top-down integrálás esetén az elkészült és letesztelt modulok használhatóak meghajtóként. Igen, ha az tesztelt modul működése egyértelműen specifikált, akkor elhagyható a meghajtó modul. Igen, ha strukturális tesztelést használunk, elegendő csak csonk modulokat készíteni. Nem, meghajtó modulra mindig szükség van. Csak olyan fordulhat elő, hogy további csonkok nem szükségesek. Nem, a meghajtó és csonk modulokra egyaránt szükség van, hogy a tesztelendő modul teljes környezetet helyettesíteni tudjuk. Kérdés: Előfordulhat, hogy tesztelés során nincs szükség csonk modulokra csak meghajtó modulokra? Igen, bottom-up integrálás esetén az elkészült és letesztelt modulok használhatóak csonkként. Igen, ha az tesztelt modul működése egyértelműen specifikált, akkor elhagyható a csonk modul. Igen, ha strukturális tesztelést használunk, elegendő csak meghajtó modulokat készíteni. Nem, csonk modulra mindig szükség van. Csak olyan fordulhat elő, hogy további meghajtók nem szükségesek. Nem, a meghajtó és csonk modulokra egyaránt szükség van, hogy a tesztelendő modul teljes környezetet helyettesíteni tudjuk. Kérdés: Mi igaz az alábbi jelölés esetén? MH(2) = {A, B, CS(E), CS(C), CS(D)} Top-down tesztelésről van szó. Az integrálási folyamatban eddig két lépést tettünk meg. Az adott fázisban három csonk modul található. Az adott fázisig az A modul már biztosan le lett tesztelve. Az adott fázisban kettő meghajtó modul található. Bottom-up tesztelésről van szó. Kérdés:Top-down módszer esetén hány lépésben célszerű összeintegrálni az alábbi rendszert? 5 6 3 4 2 Kérdés: Bottom-up módszer esetén hány lépésben célszerű összeintegrálni az alábbi rendszert? 5 6 3 4 2 Kérdés: Mi igaz az alábbi jelölés esetén? MH(4) = {E, B, M(B)} Bottom-up tesztelésről van szó. Az adott fázisban egy meghajtó modul található. Az adott fázisban E modul már biztosan le lett tesztelve. Hibás a jelölés, mert a B modul már szerepel a halmazban, ezért nincs szükség M(B)-re. Az integrálási folyamatban eddig három lépést tettünk meg. Top-down tesztelésről van szó. Kérdés: Mikor érdemes a bottom-up építkezést használni inkrementális tesztelés esetén? Ha a komolyabb hibák lent keletkeznek a hierarchiában. Ha a komolyabb hibák fent keletkeznek a hierarchiában. Ha a modulok túlnyomó többsége a hierarchia tetején található. Ha a modulok túlnyomó többsége a hierarchia alján található. Nem érdemes a top-down építkezést használni, mert jellemzően bonyolultabb, mint a bottom-up. Kérdés: Mi a szendvics tesztelés? A top-down és bottom-up megközelítés egyszerre történő alkalmazása. Az összes modul egy menetben történő, együttes tesztelése. A modulok izolált módon történő tesztelése. A modulok véletlenszerű tesztelése és integrálása. Inkrementális tesztelés esetén a lentről felfelé történő tesztelési módszer. Kérdés: Az alábbiak közül mely igaz? Együttes tesztelésnél a modulokat izolált módon kell tesztelni. Inkrementális tesztelés esetén nincs szükség meghajtó és csonk modulok együttes alkalmazására. Együttes tesztelés esetén beszélhetünk top-down és bottm-up megközelítésről. Együttes tesztelés esetén kevesebb segédprogram megírására van szükség, mint inkrementális tesztelés esetén. Inkrementális tesztelésnél a modulokat izolált módon kell tesztelni. Kérdés: Az alábbiak közül mely igaz? A modulok közti interfészek hibái korábban kiderülnek az inkrementális tesztelésénél, mint az együttes tesztelés esetén. Az inkrementális tesztelésnél könnyebb lokalizálni a hibákat, mint az együttes tesztelésnél. Együttes tesztelés esetén lehetséges párhuzamosítani a teszteléseket. Az inkrementális tesztelésnél minden modulhoz el kell készíteni annak környezetét meghajtó és csonk modulok formájában. Ha egy hibát észlelünk az együttes tesztelés esetén, az mindig az új modulban vagy annak valamely kapcsolatában gyökeredzik. Kérdés: Egy készülő operációs rendszert szeretnénk tesztelni inkrementális módszerrel. Milyen megközelítésben lenne célszerű elvégezni a tesztelést és miért? A rendszert bottom-up módszerrel célszerű tesztelni, mert az operációs rendszerek tipikusan réteg szervezésű szoftverek. A rendszert top-down módszerrel célszerű tesztelni, mert az operációs rendszerek komplexitása jellemzően a hierarchia alsóbb rétegeibe szerveződik. A rendszert big bang módszerrel célszerű tesztelni, mert így a hibák jelentős hányada könnyen lokalizálható. A rendszert szendvics módszerrel célszerű tesztelni, mert így a tesztelés könnyen párhuzamosítható, amit egy ilyen volumenű szoftver tesztelése egyértelműen megkíván. Kérdés: Mi a komponens alapú fejlesztés? Egy olyan folyamat, amelyben egymástól független komponenseket tervezünk be és integrálunk egy közös szoftver rendszerbe. Egy olyan szoftver fejlesztési megközelítés, ahol olyan újra felhasználható modulokat gyártunk, melyek különböző rendszerekbe beépíthetőek. Komponens alapú fejlesztés során a szoftver rendszert funkciók szerinti modulokra bontjuk, és az egyes modulokat önállóan fejlesztjük le. Ebben a megközelítésben a szoftver rendszert nem egy menetben készítjük el, hanem úgynevezett komponenseket írunk iteratív módon. Kérdés: Mi jellemzi a komponens alapú fejlesztést? A komponensek az interfészükkel vannak specifikálva. Minden komponens tartalmaz interfészt. A komponensek szabványa előírja, hogy miként kell kommunikálni a komponenseknek. A komponensek szabványosítva vannak, mely előírja a programozási nyelvüket is. A komponensek middleware szoftverek segítségével kommunikálnak egymással. Kérdés: Mi igaz a middleware esetén? Egymástól független elemek együttműködésére használjuk. Egy middleware például a CORBA. Egy middleware például az EJB. Arra használjuk, hogy egy régi technológiával készült szoftver komponens kapcsolatba tudjon lépni modernebb komponensekkel is. A szoftver komponensek között helyezkedik el, másik megnevezése az interfész. Kérdés: Ian Sommerville szerint milyen tulajdonságokkal kell rendelkeznie egy szoftver komponensnek? Szabványosított Független Beépíthető Módosítható Hatékony Mozgatható Kérdés: Ian Sommerville szerint milyen tulajdonságokkal kell rendelkeznie egy szoftver komponensnek? Telepíthető Dokumentált Újra-felhasználható Tesztelhető Karbantartható Kérdés: Mit írna a betűkkel jelzett helyekre? A: komponens, B: igénylési interfész, C: szolgáltatási interfész A: interfész, B: bemeneti kapcsolatok, C: kimeneti kapcsolatok A: middleware, B: igénylő komponens, C: kiszolgáló komponens A: modul, B: fan-in, C: fan-out Kérdés: Mi igaz az alábbi ábra esetén? Az ábrán komponensek és interfészeik viszonya látható. Az ábrán 6 szolgáltatási interfész látható. Az ábrán 5 fan-in látható. Az ábrán 5 szolgáltatási interfész látható Az ábrán szoftver modulok és kapcsolataik látható. A kettes számú szoftver modul két bemeneti adatot vár. Kérdés: Mi igaz a szolgáltatási interfész esetén? Lényegében ez a komponens API-ja. A komponens által nyújtott szolgáltatásokat definiálja. A komponens által felhasznált szolgáltatásokat definiálja. Jele egy zárt félkör. Jele egy nyitott félkör. Kérdés: Mi igaz az igénylési interfész esetén? A komponens által fogadott és használt szolgáltatásokat definiálja. OO-megközelítésben az objektumok azon metódusait definiálja, amelyeket a komponenst használó szoftver hívni tud. A komponenstől igényelhető szolgáltatásokat definiálja. Jele egy kör. Jele egy zárt félkör. Kérdés: Az alábbiak közül mely igaz? A komponensek azonnal elindíthatóak, nem kell őket együttesen lefordítani. A komponensek nem definiálnak adattípust. A komponensek megvalósítása ismeretlen is lehet. A komponensek forráskódja mindig rendelkezésre áll. A komponensek azonnal futtathatóak, de ha együttesen szeretnénk őket használni, akkor újra fordítás szükséges. Kérdés: Az alábbiak közül mely igaz? A komponensek nyelvtől függetlenek. A komponensek szabványosítva vannak. Komponensek esetén biztosan rendelkezésre áll a forráskód. A komponensek tetszőleges módon, megkötés nélkül megvalósíthatóak. Csak ugyanazon nyelven írt komponensek tudnak együttműködni. Kérdés: Mi igaz a legacy systems esetén? Általában fontos üzleti funkciót látnak el. Régi technológiával készültek. Jól bevált megoldásokat valósítanak meg. Fejlesztő vállalat fő szoftver terméke. Külső vállalat által készített szoftver komponens. Kérdés: Mi igaz a csomagoló program esetén? A csomagoló program egy interfész. A csomagoló program feladata, hogy a régi szoftver összes funkcióját közvetítse. A csomagoló program feladata, hogy egy korábban írt szoftvert új funkciókkal lásson el. Angol megnevezése a boxing-application. Angol megnevezése a warper. Kérdés: Komponens alapú fejlesztés esetén mi a fejlesztési modell első három lépése és azok sorrendje? 1. A rendszerkövetelmények meghatározása 2. A számításba vehető komponensek azonosítása 3. A követelmények módosítása a megtalált komponensekhez igazodva 1. Felhasználó követelmények felmérése 2. Rendszertervezés 3. A számításba vehető komponensek azonosítása Kérdés: Komponens alapú fejlesztés esetén mi a fejlesztési modell második három lépése és azok sorrendje? 4. Architekturális tervezés 5. A számításba vehető komponensek azonosítása 6. A komponensek egybeépítése, a teljes szoftver rendszer létrehozása 4. Komponensek tervezése 5. Rendszer integrálása és validálása 6. Rendszer üzemeltetés és karbantartás Kérdés: Mely fejlesztési modell vázlatos diagramja látható a képen? Komponens alapú fejlesztés Inkrementális fejlesztés Vízesés modell Prototípus alapú fejlesztés V-modell Kérdés: Az alábbiak közül mely igaz a komponens alapú fejlesztés esetén? Komponens alapú fejlesztés esetén előfordulhat, hogy egy komponenst nekünk kell elkészítenünk. Az architekturális tervezés után előfordulhat, hogy bizonyos komponensek nem illenek a rendszerbe. A követelményeket a fejlesztés során már nem változtatjuk. Előfordulhat, hogy még a komponensek azonosítása előtt vissza kell lépni a fejlesztés kezdeti szakaszához. Komponens alapú fejlesztés esetén mindig csak előre gyártott szoftver komponensekből építkezünk. Kérdés: Komponens alapú fejlesztés esetén mely fázisokban mely lépései zajlanak a komponensek azonosításának? A második fázisban történik a komponensek keresése és kiválasztása, az ötödik fázisban történik a komponensek validálása. A második fázisban történik a komponensek keresése, az ötödik fázisban történik a komponensek kiválasztása és validálása. A harmadik fázisban történik a komponensek keresése és kiválasztása, a negyedik fázisban történik a komponensek validálása. A harmadik fázisban történik a komponensek keresése, a negyedik fázisban történik a komponensek kiválasztása és validálása. Kérdés: Mi a software maintenance? Az üzembe helyezést követően, a normál felhasználás alatt elvégzendő szoftver-változtatások folyamata. A szoftver validálása során elvégzendő hibajavítási folyamat. A szoftver új funkciókkal való bővítési folyamata. Szoftver meghibásodás esetén elvégzendő folyamat. A szoftver üzembe helyezését megelőző, a teljes rendszert érintő validációs folyamat. Kérdés: A szoftver-karbantartásnak milyen típusai vannak? Javító karbantartás Adaptív karbantartás Kibővítő karbantartás Módosító karbantartás Tervezési karbantartás Kódolási karbantartás Kérdés: Mi az SMI? Egy karbantartási mérőszám. A szoftver érettségi foka. Komponens alapú fejlesztést megvalósító programozási nyelv. Komponens alapú fejlesztési irányelv. Forráskódra vonatkozó mérőszám. Kérdés: Egy szoftver esetén SMI = 1,2. Milyen értékekkel kaphattuk ezt? Egyik sem. M = 1,2; F(vált) = 0; F(új) = 0; F(tör) = 0 M = 1; F(vált) = 0,1; F(új) = 0,1; F(tör) = 0 M = 0,6; F(vált) = 0; F(új) = 0; F(tör) = 2 Kérdés: Az alábbiak közül mi igaz a szoftver érettségi indexe esetén? Értékének kiszámításához négy paraméter szükséges. A szoftver érettségi fokának értéke nem lehet egynél nagyobb. Ha egy szoftveren változtatást