„Szoftvertechnológia - Igaz/Hamis” változatai közötti eltérés

	Kvízek használata, fejlesztése.
Statisztika
Átlagteljesítmény	-
Eddigi kérdések	0
Kapott pontok	0
Alapbeállított pontozás	(-)
	-
Beállítások
Minden kérdés látszik	-
Véletlenszerű sorrend	-
	-

A lap jelenlegi, 2023. november 6., 00:17-kori változata

← Vissza az előző oldalra – Szoftvertechnológia

Kikérdező a tárgyhonlapon lévő igaz/hamis kérdésekhez + Wikin fenn található vizsgákból.

Tartalomjegyzék

1 A "Ez jó szoftver?" kérdés a validációhoz kapcsolódik.
2 A "Jó ez a szoftver?" kérdés a verifikációhoz kapcsolódik.
3 A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.
4 A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.
5 A CMM egy szervezet által készített összes szoftver minőségét értékeli.
6 A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.
7 A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.
8 A CMMI (Capability Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni.
9 A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 2-es érettségi szinten kötelező.
10 A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
11 A CMMI 3-as szintjétől a szoftverfejlesztési folyamat tevékenységei dokumentáltak, szabványosítva vannak, és a szervezet szabványos szoftverfejlesztési folyamatává integrálták őket.
12 A CMMI 5-ös szintjétől a termelési folyamatok méréseiből számszerűsíthető visszacsatolások segítik a folyamatos folyamat-fejlesztést, amiben új, innovatív elemeket is felhasználnak.
13 A CMMI előírja, hogy a funkcionális követelményeket egy szoftverre vonatkozóan UML jelölésrendszert használó Use-case modellekkel kell leírni.
14 A CMMI előírja, hogy a nemfunkcionális követelményeket egy szoftverre vonatkozóan az ISO 9126 / ISO 25000 szabvány szerint kell meghatározni.
15 A CMMI előírja, hogy a termék méréséhez a GQM paradigmát kell használni.
16 A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.
17 A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.
18 A CMMI modell alkalmazása során elfogadható, hogy a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
19 A CMMI modell folytonos nézetének (a folytonos CMMI-modellnek) előnye, hogy a szervezetek saját szükségleteiknek és követelményeiknek megfelelő folyamatokat tudják kiválasztani és továbbfejleszteni.
20 A CMMI modellben 4-es érettségi szinten az összes, 4-es érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie.
21 A CMMI modellben 5-ös érettségi szinten az összes 5-ös érettségi szinten kötelező folyamatnak legalább 5-ös képességi szintűnek kell lennie.
22 A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek.
23 A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.
24 A COSMIC agilis szoftverfejlesztési módszertan.
25 A COSMIC projekttervezési és követési eszköz.
26 A Continuous Integration projekttervezési és követési eszköz.
27 A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.
28 A DD-path tesztelési technika követelményspecifikáción alapul.
29 A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.
30 A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.
31 A GQM (Goal-Question-Metric) a QIP (Quality Improvement Paradigm) egyik eszköze.
32 A GQM paradigma a kód minőségének mérésére nem alkalmazható.
33 A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.
34 A GQM paradigma tesztelési folyamatok mérésére nem alkalmazható.
35 A GUI tervezése során figyelni kell a felhasználók sokféleségére.
36 A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter.
37 A Követelménymenedzsment (REQM) folyamat a CMMI modell 4-es érettségi szintjén (ML4) jelenik meg.
38 A PRINCE a RUP továbbfejlesztett változata.
39 A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.
40 A Projekt tervezés (PPL) folyamat a CMMI modell 3-as érettségi szintjén jelenik meg.
41 A RUP agilis szoftverfejlesztési életciklus modell.
42 A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Collaboration-Transition.
43 A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Construction-Transition.
44 A RUP előírja, hogy a szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan, mert ez mindig a felhasználók feladata.
45 A RUP nem agilis fejlesztési módszertan.
46 A RUP nem tartalmaz projektirányítási eljárásokat.
47 A RUP szekvenciális szoftverfejlesztési módszertan.
48 A SPICE modell 6 képességi szintet határoz meg egy folyamat esetében.
49 A SPICE modell 6 érettségi szintet határoz meg egy szoftverfejlesztő cég számára, 0-tól 5-ig, így a szoftverfejlesztő cégek érettsége összemérhető.
50 A SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig.
51 A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni.
52 A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.
53 A Scrum szekvenciális szoftverfejlesztési életciklus modell.
54 A Scrum szerint a cég vezetői „Csirkék”.
55 A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.
56 A TSP projekttervezési és követési eszköz.
57 A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik.
58 A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik.
59 A V-modell a vízesés-modellből kialakított iteratív modell.
60 A V-modell az agilis fejlesztésből kialakult életciklus modell, melyet a RUP is alkalmaz.
61 A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük.
62 A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.
63 A V-modellben megjelenik a dinamikus teszt.
64 A V-modellben megjelenik a regressziós teszt.
65 A V-modellben megjelenik a stressz teszt.
66 A bejelentkező képernyőn nem kell megadni a felhasználó keresztnevét, csak a vezetéknevét. (Webes alkalmazás nemfunkcionális követelménye)
67 A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.
68 A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye)
69 A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.
70 A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.
71 A csapat sebessége projekttervezési és követési eszköz.
72 A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.
73 A dinamikus teszt explicit módon megjelenik a CMMI modellben.
74 A dinamikus tesztelés alapulhat követelményspecifikáción és a kód belső szerkezetén is.
75 A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.
76 A fehér doboz teszt megjelenik explicit módon a V-modellben.
77 A fehér-doboz tesztelés a kód belső szerkezetén alapul.
78 A fehér-doboz tesztelési technika követelményspecifikáción alapul.
79 A fehérdoboz tesztelés alapja az UML diagramok.
80 A felülvizsgálat, átvizsgálás, review, audit dinamikus verifikációs technikák.
81 A for (X x : c) típusú (foreach) ciklusban a c változóval referált objektum meg kell valósítsa a java.util.Collection interfészt.
82 A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél.
83 A határérték analízis a kód belső szerkezetén alapul.
84 A határérték tesztelés és az ekvivalencia particionálás funkcionális tesztelési technikák, a követelményspecifikáción alapszanak.
85 A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
86 A jó szoftver esetében a rövid válaszidő és a folyamatos rendelkezésre állás mindig alapkövetelmény.
87 A jó szoftver esetében a rövid válaszidő és a megfelelő felhasználói dokumentáció mindig alapkövetelmény.
88 A jó szoftvertervező nem vizsgál meg több alternatívát egy rendszer tervezése során, mert tapasztalatai alapján ismeri a legjobbat, és azt választja.
89 A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.
90 A keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
91 A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket minimálisra csökkentsük.
92 A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket nullára csökkentsük.
93 A kockázatmenedzsment lényege, hogy a megjelenő problémákat felmerülésük után a lehető legrövidebb időn belül megoldjuk.
94 A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulására felkészüljünk, és ezáltal hatásukat minimálisra csökkentsük.
95 A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulását teljesen megakadályozzuk, és ezáltal hatásukat nullára csökkentsük.
96 A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)
97 A konfigurációkezelésre időt kell tervezni a projektben.
98 A konfigurációkezelésre nem kell időt tervezni a projektben.
99 A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik, mely egy projekttervezési és követési eszköz.
100 A kötegelt feldolgozás (batch) az adatfolyam (pipes and filters) architektúratípushoz illeszkedik.
101 A követelményeket a kódban is pontosan be kell tudni azonosítani. Ennek egyik módja, hogy a kódrészletekbe kommentként beírjuk a vonatkozó követelményeket.
102 A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.
103 A követelménymenedzsment egyik feladata a követelmények változásának követése.
104 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A beszállókártyát ki lehet nyomtatni.
105 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik.
106 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön.
107 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell.
108 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie.
109 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal.
110 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni.
111 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni.
112 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie.
113 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra.
114 A megbízhatósági követelmények nemfunkcionális követelmények.
115 A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.
116 A moderálás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
117 A mérséklés, a megegyezés, a csökkentés és az elkerülés lehetséges intézkedések a kockázat elhárítására.
118 A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
119 A nem definiált láthatóságú attribútum publikusnak számít. (UML2)
120 A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).
121 A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).
122 A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.
123 A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.
124 A posztkondíciók biztosítása a hívott metódus feladata.
125 A prekondíciók biztosítása a hívott metódus feladata.
126 A primitív típusokhoz tartozó csomagoló osztályok (wrapper classes) nem változtathatók (immutable).
127 A progressziós teszt explicit módon megjelenik a CMMI modellben.
128 A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák, ha az a vízesés modellt követi.
129 A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák.
130 A projekt olyan tevékenységsorozat, amely korlátos (többek között) a készülő szoftver válaszidejére vonatkozóan.
131 A projekt olyan tevékenységsorozat, amely korlátos (többek között) a minőségre vonatkozóan.
132 A projekt olyan tevékenységsorozat, amely nem korlátos (többek között) a minőségre vonatkozóan.
133 A projekt tervben a kritikus úton levő tevékenységek hossza nem változtatható meg anélkül, hogy ez a projekt teljes átfutását befolyásolná.
134 A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.
135 A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka nem egyenlő 0-val.
136 A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.
137 A projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.
138 A projektben csak fejlesztési tevékenységeket (mint: követelményspecifikáció, design, kódolás, tesztelés) kell megtervezni idő, költség és erőforrás szempontjából.
139 A projektben időt kell tervezni a mérések és elemzések végzésére is.
140 A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
141 A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
142 A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.
143 A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.
144 A refaktorálás az, amikor a szoftvert úgy fejlesztjük tovább, hogy a belső viselkedés változatlan marad, de külső szerkezet megújul.
145 A regressziós teszt explicit módon megjelenik a CMMI modellben.
146 A rendszer architektúrája befolyásolja a rendszer hibatűrését, rendelkezésre állását, robusztusságát. Az alkalmazás számára választott szerkezet ezért nemfunkcionális rendszerkövetelményektől is függhet.
147 A rendszernek 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye)
148 A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. (Webes alkalmazás nemfunkcionális követelménye)
149 A rendszernek a hét minden napján, 0-24 óra között működnie kell. (Webes alkalmazás nemfunkcionális követelménye)
150 A rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye)
151 A rendszertervezés során alapvetően a rendszer statikus és dinamikus nézetét írjuk le.
152 A rendszerteszt a specifikáció ellenőrzésére irányul.
153 A rövid válaszidő minden szoftver esetében alapkövetelmény.
154 A rövid válaszidő nem minden szoftver esetében alapkövetelmény.
155 A scrum csapatban – naponta többször cserélődő – párokban programoznak.
156 A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.
157 A sikeres teszteseteket nem szükséges dokumentálni, ha agilisan dolgozunk.
158 A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.
159 A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.
160 A strukturális tesztelés előnye, hogy pontos méréseket tesz lehetővé a teszt lefedettséggel kapcsolatban.
161 A strukturális tesztelés esetében a teszteseteket a követelmények alapján hozzuk létre.
162 A strukturális tesztelés nem feltételezi a kód futtatását.
163 A strukturális teszt explicit módon megjelenik a CMMI modellben.
164 A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett.
165 A szoftver az elkészült forráskódot jelenti.
166 A szoftver implementálása nem csak a kódolást jelenti.
167 A szoftver implementálása pontosan a kódolást jelenti.
168 A szoftver jó minősége pontosan a jó teszteléssel biztosítható.
169 A szoftver jó minősége pontosan a jó és rendszeres auditokkal biztosítható.
170 A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
171 A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
172 A szoftver minőségét pontosan a kód jó minősége jelenti.
173 A szoftver tesztelése nem csak a kód futtatását jelenti.
174 A szoftverfejlesztés spirális modelljének 1. Szektorában a megoldandó feladat a fejlesztés és validálás.
175 A szoftverfejlesztés spirális modelljének 2. Szektorában a megoldandó feladat a kockázat elemzése.
176 A szoftverfejlesztés spirális modelljének 3. Szektorában a megoldandó feladat a célok kijelölés.
177 A szoftverfejlesztés spirális modelljének 4. Szektorában a megoldandó feladat az új fázis tervezése.
178 A szoftverfejlesztés vízesésmodellje szerint a fejlesztésnek eslő fázisa a követelmény.
179 A szoftverfejlesztésnél a Specifikáció célja "a követelményeket kielégítő rendszer magas absztrakciós szintű formális leírása”.
180 A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata.
181 A szoftverspecifikálást a követelmény előzi meg.
182 A szoftverspecifikálást a tervezés követi.
183 A szoftvertermék minőségét nem lehet egységesen meghatározni; minőségi profilt kell kialakítani az egyes esetek sajátosságait figyelembe véve.
184 A szoftvertermék tartalmazza a felhasználói adatokat.
185 A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.
186 A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni.
187 A tanonckodás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
188 A tanúsítás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
189 A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
190 A tapasztalt szoftvertervezőnek nem kell több alternatívát megvizsgálnia egy rendszer tervezése során, mert mindig a legjobbat fogja választani.
191 A tervezést az implementáció követi.
192 A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
193 A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
194 A tesztelés a kulcsfontosságú fejlesztések után kezdődik.
195 A tesztelés a szoftver minőségének biztosítására szolgáló egyetlen lehetséges módszer, mert csak a tesztelés teszi lehetővé minőségi jellemzők mérését.
196 A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.
197 A tesztelés pontosan a hibakeresést és hibajavítást jelenti.
198 A tesztelés pontosan a tesztek futtatását jelenti, de nem azonos a hibakereséssel.
199 A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.
200 A tesztelés statikus verifikációs technika.
201 A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
202 A tesztelési folyamatokat leíró TMMI modell szerkezete teljesen megegyezik a CMMI modell szerkezetével.
203 A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
204 A teszteseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat.
205 A tulajdonos jó szerepkör típus szoftver átvizsgálásakor.
206 A tényleges és az elvárt eredmények összehasonlítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
207 A use-case diagramon nem szerepelhet függőség (dependency).
208 A use-case diagramon szereplő asszociációnak is van multiplicitása.
209 A use-case leírás és az adatfolyamábra egyenértékű. (UML2)
210 A use-case leírásban szerepelhetnek az elő- és utófeltételek is.
211 A validáció explicit módon megjelenik a CMMI modellben.
212 A validálás a követelmények ellenőrzésére irányul.
213 A verifikáció explicit módon megjelenik a CMMI modellben.
214 A válaszidőnek mindig 2 sec alatt kell lennie. (Webes alkalmazás nemfunkcionális követelménye.)
215 A válaszidőre vonatkozó követelményt nemfunkcionális követelményként szoktuk kezelni.
216 A vízesés modell és a V-modell iteratív életciklus modellek.
217 A vízesés modell és a V-modell szekvenciális életciklus modellek.
218 A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk.
219 A “projekt terv” pontosan a tevékenységek hálódiagramját vagy sávdiagramját jelenti.
220 A “sprint review” eredménye a product backlog új változata.
221 A “tesztelési terv” pontosan a tesztesetek leírását jelenti.
222 A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike.
223 A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.
224 A „félig kész munka” a szoftverben a Hét Pazarlás egyike.
225 A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike.
226 A „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszteseteket rendszeresen felül kell vizsgálni és módosítani kell.
227 A „féregírtó paradoxon” a „Hét Pazarlás” egyike.
228 A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.
229 A „tesztvezérelt fejlesztés” során cél, hogy minden funkcióra már az implementálása előtt elkészüljenek a tesztesetek.
230 Abstract osztálynak lehet final metódusa.
231 Agilis fejlesztés esetében semmit sem kell dokumentálni, lényeg, hogy a kód legyen minél előbb kész.
232 Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.
233 Agilis környezetben a készülő kód méretét nem lehet becsülni.
234 Agilis környezetben a készülő kód méretét nem lehet mérni.
235 Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog.
236 Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
237 Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz.
238 Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el.
239 Agilis projektben Burn Down Chart-tal lehet a projekt előrehaladását követni.
240 Agilis projektben a követelményeket a kódban nem kell tudni beazonosítani, mert a követelmények gyakran változnak.
241 Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni, és annak szerves része is.
242 Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket.
243 Agilis szoftverfejlesztésnél előfordulhat, hogy a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy).
244 Agilisan dolgozó cégnél a CMMI nem alkalmazható.
245 Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni.
246 Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást eredményez.
247 Az EF (Experience Factory) a QIP (Quality Improvement Paradigm) egyik eszköze.
248 Az Extreme Programming szerinti életciklusban a User Story központi helyen van.
249 Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni.
250 Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás.
251 Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
252 Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik.
253 Az ISO 9001 alapú audit a kód minőségét vizsgálja.
254 Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.
255 Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie.
256 Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel.
257 Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél.
258 Az ISO 9001 szabvány és a TMMI modell együttesen is alkalmazható egy agilisan működő szoftvercégnél.
259 Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le.
260 Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.
261 Az adott helyzetben legmegfelelőbb tesztelési technikák kiválasztása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
262 Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
263 Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2)
264 Az aktor és a use-case is classifier (osztályszerű).
265 Az asszociáció, a kompozíció, a függőség és a specializáció közül a specializáció a leggyengébb. (UML2)
266 Az egyenrangú szemle (Peer review) az egyetlen (statikus) tesztelési technika, amelyet a CMMI modell név szerint említ a VER (Verifikáció) folyamat sajátos céljaként.
267 Az egyetlen agilis projekt menedzsment eszköz a Scrum.
268 Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez.
269 Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”.
270 Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést.
271 Az elnök jó szerepkör típus szoftver átvizsgálásakor.
272 Az implementáció a kódoláson kívül egyéb elemeket is tartalmaz, például a műszaki dokumentáció elkészítését és a változásmenedzsmentet.
273 Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.
274 Az iteratív és inkrementális fejlesztések egyik előnye, hogy a felhasználói visszajelzések viszonylag korán megjelennek a fejlesztési folyamatban.
275 Az iteratív és inkrementális fejlesztések hátránya, hogy a felhasználói visszajelzések későn jelennek meg a fejlesztési folyamatban.
276 Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)
277 Az Önt alkalmazó cég műszaki igazgatója azt a feladatot adta Önnek, hogy irányítsa egy idősek számára készülő, kulturális híreket megjelenítő rendszer tervezését. Az adatokat a hasonló, mobil platformokon futó alkalmazásukból vegye át. Elmondja még, hogy vegye figyelembe az időskorúak gyenge látását, lassú reakcióidejét és azt, hogy a kezük gyakran nem tudja pontosan végezni a finom mozgásokat. Milyen alapelveket kell Önnek alkalmaznia a GUI tervezés során?
278 Az öröklés alkalmazásával általában csökken a forráskódban az alternatívák (case és if szerkezetek) száma.
279 Az útvonal alapú tesztelés a kód belső szerkezetén (white box) alapul.
280 Az „elkerülés”, „csökkentés”, „kompenzálás” és „megegyezés” olyan lehetséges intézkedések, amelyekkel a kockázat nullára csökkenthető egy projektben.
281 Az, hogy a szabványos folyamatokat dokumentáltak, a CMMI modellben legkorábban a 3-as érettségi szintre jellemző.
282 Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
283 Béta-teszt megjelenik explicit módon a V-modellben.
284 Catch blokkjában lehet újonnan létrehozott kivételt dobni.
285 Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg.
286 Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.
287 Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát.
288 Egy interfészben csak operációk deklarálhatóak, attribútumok nem.
289 Egy metódust el lehet látni egyszerre abstract és final módosítóval is.
290 Egy objektum notifyAll() metódusának meghívásakor a végrehajtó szál kilép az objektum monitorából.
291 Egy objektum referenciáját tartalmazó változón csak olyan metódus hívható meg, amilyen a változó statikus típusában is szerepel.
292 Egy objektum wait() metódusának meghívásakor a végrehajtó szálnak nem kell az objektum monitorában tartózkodnia.
293 Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa.
294 Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája.
295 Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)
296 Egy projekt hálódiagramjában a kritikus úton azok a tevékenységek helyezkednek el, amelyeknek teljes időjátéka nem 0.
297 Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.
298 Egy projekt lehet agilis, ha a projekt elején van egy két hónapos időszak, amikor a felhasználói követelményeket nagyon pontosan dokumentálják.
299 Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Boardról készült fotókkal dokumentálják, mely egy projekttervezési és követési eszköz.
300 Egy projekt lehet agilis, ha a projekt előrehaladását a falra ragasztott cédulákkal követik, és az ezekről készült fotókkal dokumentálják.
301 Egy projekt lehet agilis, ha a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy).
302 Egy projekt lehet agilis, ha a projektben szigorúan követik a RUP (Rational Unified Process) előírásait az életciklusra vonatkozóan.
303 Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
304 Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
305 Egy projekt lehet agilis, ha a „szoftvertervezés” (mint műszaki, mérnöki munka) és a „projekttervezés” (mint menedzsment feladat) élesen elkülönül egymástól.
306 Egy projekt lehet agilis, ha előfordul, hogy a teszteseteket hamarabb írják meg, mint a kódot.
307 Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.
308 Egy tevékenység teljes időjátéka az adott tevékenység legkésőbbi kezdésének és legkorábbi kezdésének különbségeként számolható ki.
309 Egy változó dinamikus típusa nem lehet absztrakt osztály.
310 Egy állapotdiagramnak (state chart) csak akkor lehet két vagy több végállapota, ha a modelben párhuzamos régiók vannak.
311 Előfordul, hogy naponta akár több build is készül.
312 Előfordulhat, hogy két szál (T1 és T2) ugyanazon objektum ugyanazon synchronized metódusát futtatva T1 T2 sorrendben lép be, de T2 T1 sorrendben lép ki.
313 Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni.
314 Final metódus nem módosíthatja az attribútumok értékét.
315 Final metódusban használható a this változó.
316 Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak.
317 Garvin ötféle szoftverminőségi definíciója között van termék alapú és folyamat alapú definíció is.
318 Generikus osztály példányosításakor lehet másik generikus osztály a paraméter.
319 Ha CMMI modellt alkalmazunk, a cég érettségi szintjét és a folyamatok képességi szintjét is vizsgálnunk kell.
320 Ha SPICE modellt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy a kockázatokat azonosítsuk, mert ezzel a modell egy külön folyamata foglalkozik.
321 Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
322 Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni.
323 Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni.
324 Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni.
325 Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni.
326 Ha egy szál véget ért, akkor start() metódushívással újraindítható.
327 Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk.
328 Határérték tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre.
329 Integrációs teszt megjelenik explicit módon a V-modellben.
330 Kommunikációs diagramon nem ábrázolható a párhuzamosság.
331 Konfigurációs elemeket nem csak a kód esetében, hanem a szoftverfejlesztés során végrehajtott összes tevékenység munkatermékeinek esetében azonosítani kell.
332 Konfigurációs elemeket nemcsak a kódra, hanem a szoftverfejlesztési projekt során készülő összes munkatermékre azonosítani kell.
333 Konstruktornak nem lehet láthatósága.
334 Késedelmes sprint esetén a csapatot új emberekkel bővítik.
335 Késedelmes sprint esetén a csapatot új emberekkel bővítik.
336 Két interfész csak akkor valósítható meg egy osztályban, ha az interfészeknek nincsen közös metódusa.
337 Lehet olyan private tag, aminek többször is lehet értéket adni.
338 Milyen elemek lehetnek egy adatfolyamábrán, beleértve a (context) diagramot is?
339 Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye)
340 Nem a validációs tesztelés célja megmutatni, hogy a szoftver megfelel a követelményeinek, vagy ez az, amit a vásárló szeretne.
341 Primitív típus is lehet generikus osztály template-paramétere.
342 Primitív típus tömbje is a primitív típusok közé számít.
343 Private tag nem szerializálódik.
344 Privát metódust csak privát metódusból lehet hívni.
345 Sprint közben folytonosan követik a felhasználó igényeinek változását.
346 Statikus metódus nem dobhat kivételt.
347 Statikus metódusban használható a this változó.
348 Statikus tag nem szerializálódik.
349 Strukturális tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre.
350 Subversionben update-kor változhat a munkapéldány.
351 Subversionben update-kor változhat a repository.
352 Synchronized módosítójú metódusban nem lehet wait() metódust hívni.
353 Szerializálás körkörös hivatkozású adatszerkezeten (pl. Gyűrű) kivételt dob.
354 Szoftverfejlesztésnél az architekturális tervezéskor a rendszer fő komponenseinek azonosítását és a közöttük fennálló együttműködéseket definiáljuk.
355 Unit teszt megjelenik explicit módon a V-modellben.
356 Általában a szoftverfejlesztési életciklusban először a statikus tesztelés, majd a strukturális tesztelés, végül a funkcionális tesztelés technikái jutnak szerephez.
357 Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival.
358 Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest.
359 Az ekvivalencia particionális fehérdoboz tesztelési technika.
360 A Konfigurációmenedzsment (CM) folyamat a CMMI modell 2-es érettségi szintjén jelenik meg (ML2).
361 A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka = 0.
362 A SPICE modell lépcsős folyamatfejlesztési modell.
363 A szekvenciális életciklus modelll szerint minden fejlesztési fázis az előző fázis eredményeire alapul; a fázisok időben egymás után következnek.
364 Nemfunkcionális követelményeket a CMMI 2-es érettségi szintjén levő cégnél nem lehet meghatározni.
365 Az útvonal alapú tesztelés és az adatfolyam alapú tesztelés a strukturális tesztelés két alapvető megközelítése.
366 A feketedoboz tesztelés a függyvényelmélet elemeit használja.

A "Ez jó szoftver?" kérdés a validációhoz kapcsolódik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A "Jó ez a szoftver?" kérdés a verifikációhoz kapcsolódik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMM egy szervezet által készített összes szoftver minőségét értékeli.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI (Capability Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 2-es érettségi szinten kötelező.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI 3-as szintjétől a szoftverfejlesztési folyamat tevékenységei dokumentáltak, szabványosítva vannak, és a szervezet szabványos szoftverfejlesztési folyamatává integrálták őket.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI 5-ös szintjétől a termelési folyamatok méréseiből számszerűsíthető visszacsatolások segítik a folyamatos folyamat-fejlesztést, amiben új, innovatív elemeket is felhasználnak.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI előírja, hogy a funkcionális követelményeket egy szoftverre vonatkozóan UML jelölésrendszert használó Use-case modellekkel kell leírni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI előírja, hogy a nemfunkcionális követelményeket egy szoftverre vonatkozóan az ISO 9126 / ISO 25000 szabvány szerint kell meghatározni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI előírja, hogy a termék méréséhez a GQM paradigmát kell használni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI modell alkalmazása során elfogadható, hogy a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI modell folytonos nézetének (a folytonos CMMI-modellnek) előnye, hogy a szervezetek saját szükségleteiknek és követelményeiknek megfelelő folyamatokat tudják kiválasztani és továbbfejleszteni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A CMMI modellben 4-es érettségi szinten az összes, 4-es érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI modellben 5-ös érettségi szinten az összes 5-ös érettségi szinten kötelező folyamatnak legalább 5-ös képességi szintűnek kell lennie.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A COSMIC agilis szoftverfejlesztési módszertan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A COSMIC projekttervezési és követési eszköz.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Continuous Integration projekttervezési és követési eszköz.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A DD-path tesztelési technika követelményspecifikáción alapul.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A GQM (Goal-Question-Metric) a QIP (Quality Improvement Paradigm) egyik eszköze.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A GQM paradigma a kód minőségének mérésére nem alkalmazható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A GQM paradigma tesztelési folyamatok mérésére nem alkalmazható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A GUI tervezése során figyelni kell a felhasználók sokféleségére.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A Követelménymenedzsment (REQM) folyamat a CMMI modell 4-es érettségi szintjén (ML4) jelenik meg.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A PRINCE a RUP továbbfejlesztett változata.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A Projekt tervezés (PPL) folyamat a CMMI modell 3-as érettségi szintjén jelenik meg.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A RUP agilis szoftverfejlesztési életciklus modell.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Collaboration-Transition.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Construction-Transition.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A RUP előírja, hogy a szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan, mert ez mindig a felhasználók feladata.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A RUP nem agilis fejlesztési módszertan.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A RUP nem tartalmaz projektirányítási eljárásokat.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A RUP szekvenciális szoftverfejlesztési módszertan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A SPICE modell 6 képességi szintet határoz meg egy folyamat esetében.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A SPICE modell 6 érettségi szintet határoz meg egy szoftverfejlesztő cég számára, 0-tól 5-ig, így a szoftverfejlesztő cégek érettsége összemérhető.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Scrum szekvenciális szoftverfejlesztési életciklus modell.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Scrum szerint a cég vezetői „Csirkék”.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A TSP projekttervezési és követési eszköz.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A V-modell a vízesés-modellből kialakított iteratív modell.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A V-modell az agilis fejlesztésből kialakult életciklus modell, melyet a RUP is alkalmaz.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A V-modellben megjelenik a dinamikus teszt.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A V-modellben megjelenik a regressziós teszt.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A V-modellben megjelenik a stressz teszt.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A bejelentkező képernyőn nem kell megadni a felhasználó keresztnevét, csak a vezetéknevét. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A csapat sebessége projekttervezési és követési eszköz.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A dinamikus teszt explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A dinamikus tesztelés alapulhat követelményspecifikáción és a kód belső szerkezetén is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A fehér doboz teszt megjelenik explicit módon a V-modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A fehér-doboz tesztelés a kód belső szerkezetén alapul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A fehér-doboz tesztelési technika követelményspecifikáción alapul.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A fehérdoboz tesztelés alapja az UML diagramok.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A felülvizsgálat, átvizsgálás, review, audit dinamikus verifikációs technikák.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A for (X x : c) típusú (foreach) ciklusban a c változóval referált objektum meg kell valósítsa a java.util.Collection interfészt.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A határérték analízis a kód belső szerkezetén alapul.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A határérték tesztelés és az ekvivalencia particionálás funkcionális tesztelési technikák, a követelményspecifikáción alapszanak.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A jó szoftver esetében a rövid válaszidő és a folyamatos rendelkezésre állás mindig alapkövetelmény.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A jó szoftver esetében a rövid válaszidő és a megfelelő felhasználói dokumentáció mindig alapkövetelmény.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A jó szoftvertervező nem vizsgál meg több alternatívát egy rendszer tervezése során, mert tapasztalatai alapján ismeri a legjobbat, és azt választja.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket minimálisra csökkentsük.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket nullára csökkentsük.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A kockázatmenedzsment lényege, hogy a megjelenő problémákat felmerülésük után a lehető legrövidebb időn belül megoldjuk.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulására felkészüljünk, és ezáltal hatásukat minimálisra csökkentsük.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulását teljesen megakadályozzuk, és ezáltal hatásukat nullára csökkentsük.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A konfigurációkezelésre időt kell tervezni a projektben.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A konfigurációkezelésre nem kell időt tervezni a projektben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik, mely egy projekttervezési és követési eszköz.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A kötegelt feldolgozás (batch) az adatfolyam (pipes and filters) architektúratípushoz illeszkedik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A követelményeket a kódban is pontosan be kell tudni azonosítani. Ennek egyik módja, hogy a kódrészletekbe kommentként beírjuk a vonatkozó követelményeket.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A követelménymenedzsment egyik feladata a követelmények változásának követése.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A beszállókártyát ki lehet nyomtatni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A megbízhatósági követelmények nemfunkcionális követelmények.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A moderálás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A mérséklés, a megegyezés, a csökkentés és az elkerülés lehetséges intézkedések a kockázat elhárítására.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A nem definiált láthatóságú attribútum publikusnak számít. (UML2)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A posztkondíciók biztosítása a hívott metódus feladata.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A prekondíciók biztosítása a hívott metódus feladata.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A primitív típusokhoz tartozó csomagoló osztályok (wrapper classes) nem változtathatók (immutable).

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A progressziós teszt explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák, ha az a vízesés modellt követi.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projekt olyan tevékenységsorozat, amely korlátos (többek között) a készülő szoftver válaszidejére vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projekt olyan tevékenységsorozat, amely korlátos (többek között) a minőségre vonatkozóan.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projekt olyan tevékenységsorozat, amely nem korlátos (többek között) a minőségre vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projekt tervben a kritikus úton levő tevékenységek hossza nem változtatható meg anélkül, hogy ez a projekt teljes átfutását befolyásolná.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka nem egyenlő 0-val.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projektben csak fejlesztési tevékenységeket (mint: követelményspecifikáció, design, kódolás, tesztelés) kell megtervezni idő, költség és erőforrás szempontjából.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projektben időt kell tervezni a mérések és elemzések végzésére is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A refaktorálás az, amikor a szoftvert úgy fejlesztjük tovább, hogy a belső viselkedés változatlan marad, de külső szerkezet megújul.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A regressziós teszt explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A rendszer architektúrája befolyásolja a rendszer hibatűrését, rendelkezésre állását, robusztusságát. Az alkalmazás számára választott szerkezet ezért nemfunkcionális rendszerkövetelményektől is függhet.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszernek 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszernek a hét minden napján, 0-24 óra között működnie kell. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszertervezés során alapvetően a rendszer statikus és dinamikus nézetét írjuk le.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rendszerteszt a specifikáció ellenőrzésére irányul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A rövid válaszidő minden szoftver esetében alapkövetelmény.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A rövid válaszidő nem minden szoftver esetében alapkövetelmény.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A scrum csapatban – naponta többször cserélődő – párokban programoznak.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A sikeres teszteseteket nem szükséges dokumentálni, ha agilisan dolgozunk.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A strukturális tesztelés előnye, hogy pontos méréseket tesz lehetővé a teszt lefedettséggel kapcsolatban.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A strukturális tesztelés esetében a teszteseteket a követelmények alapján hozzuk létre.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A strukturális tesztelés nem feltételezi a kód futtatását.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A strukturális teszt explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftver az elkészült forráskódot jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftver implementálása nem csak a kódolást jelenti.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftver implementálása pontosan a kódolást jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftver jó minősége pontosan a jó teszteléssel biztosítható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftver jó minősége pontosan a jó és rendszeres auditokkal biztosítható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftver minőségét pontosan a kód jó minősége jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftver tesztelése nem csak a kód futtatását jelenti.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztés spirális modelljének 1. Szektorában a megoldandó feladat a fejlesztés és validálás.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztés spirális modelljének 2. Szektorában a megoldandó feladat a kockázat elemzése.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztés spirális modelljének 3. Szektorában a megoldandó feladat a célok kijelölés.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztés spirális modelljének 4. Szektorában a megoldandó feladat az új fázis tervezése.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztés vízesésmodellje szerint a fejlesztésnek eslő fázisa a követelmény.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftverfejlesztésnél a Specifikáció célja "a követelményeket kielégítő rendszer magas absztrakciós szintű formális leírása”.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szoftverspecifikálást a követelmény előzi meg.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftverspecifikálást a tervezés követi.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftvertermék minőségét nem lehet egységesen meghatározni; minőségi profilt kell kialakítani az egyes esetek sajátosságait figyelembe véve.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftvertermék tartalmazza a felhasználói adatokat.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tanonckodás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A tanúsítás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tapasztalt szoftvertervezőnek nem kell több alternatívát megvizsgálnia egy rendszer tervezése során, mert mindig a legjobbat fogja választani.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tervezést az implementáció követi.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelés a kulcsfontosságú fejlesztések után kezdődik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelés a szoftver minőségének biztosítására szolgáló egyetlen lehetséges módszer, mert csak a tesztelés teszi lehetővé minőségi jellemzők mérését.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A tesztelés pontosan a hibakeresést és hibajavítást jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelés pontosan a tesztek futtatását jelenti, de nem azonos a hibakereséssel.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A tesztelés statikus verifikációs technika.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tesztelési folyamatokat leíró TMMI modell szerkezete teljesen megegyezik a CMMI modell szerkezetével.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A teszteseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A tulajdonos jó szerepkör típus szoftver átvizsgálásakor.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A tényleges és az elvárt eredmények összehasonlítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A use-case diagramon nem szerepelhet függőség (dependency).

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A use-case diagramon szereplő asszociációnak is van multiplicitása.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A use-case leírás és az adatfolyamábra egyenértékű. (UML2)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A use-case leírásban szerepelhetnek az elő- és utófeltételek is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A validáció explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A validálás a követelmények ellenőrzésére irányul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A verifikáció explicit módon megjelenik a CMMI modellben.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A válaszidőnek mindig 2 sec alatt kell lennie. (Webes alkalmazás nemfunkcionális követelménye.)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A válaszidőre vonatkozó követelményt nemfunkcionális követelményként szoktuk kezelni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A vízesés modell és a V-modell iteratív életciklus modellek.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A vízesés modell és a V-modell szekvenciális életciklus modellek.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A “projekt terv” pontosan a tevékenységek hálódiagramját vagy sávdiagramját jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A “sprint review” eredménye a product backlog új változata.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A “tesztelési terv” pontosan a tesztesetek leírását jelenti.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „félig kész munka” a szoftverben a Hét Pazarlás egyike.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszteseteket rendszeresen felül kell vizsgálni és módosítani kell.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A „féregírtó paradoxon” a „Hét Pazarlás” egyike.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A „tesztvezérelt fejlesztés” során cél, hogy minden funkcióra már az implementálása előtt elkészüljenek a tesztesetek.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Abstract osztálynak lehet final metódusa.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis fejlesztés esetében semmit sem kell dokumentálni, lényeg, hogy a kód legyen minél előbb kész.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis környezetben a készülő kód méretét nem lehet becsülni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis környezetben a készülő kód méretét nem lehet mérni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis projektben Burn Down Chart-tal lehet a projekt előrehaladását követni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis projektben a követelményeket a kódban nem kell tudni beazonosítani, mert a követelmények gyakran változnak.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni, és annak szerves része is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilis szoftverfejlesztésnél előfordulhat, hogy a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy).

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Agilisan dolgozó cégnél a CMMI nem alkalmazható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást eredményez.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az EF (Experience Factory) a QIP (Quality Improvement Paradigm) egyik eszköze.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az Extreme Programming szerinti életciklusban a User Story központi helyen van.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO 9001 alapú audit a kód minőségét vizsgálja.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO 9001 szabvány és a TMMI modell együttesen is alkalmazható egy agilisan működő szoftvercégnél.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az adott helyzetben legmegfelelőbb tesztelési technikák kiválasztása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az aktor és a use-case is classifier (osztályszerű).

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az asszociáció, a kompozíció, a függőség és a specializáció közül a specializáció a leggyengébb. (UML2)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az egyenrangú szemle (Peer review) az egyetlen (statikus) tesztelési technika, amelyet a CMMI modell név szerint említ a VER (Verifikáció) folyamat sajátos céljaként.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az egyetlen agilis projekt menedzsment eszköz a Scrum.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az elnök jó szerepkör típus szoftver átvizsgálásakor.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az implementáció a kódoláson kívül egyéb elemeket is tartalmaz, például a műszaki dokumentáció elkészítését és a változásmenedzsmentet.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az iteratív és inkrementális fejlesztések egyik előnye, hogy a felhasználói visszajelzések viszonylag korán megjelennek a fejlesztési folyamatban.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az iteratív és inkrementális fejlesztések hátránya, hogy a felhasználói visszajelzések későn jelennek meg a fejlesztési folyamatban.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az Önt alkalmazó cég műszaki igazgatója azt a feladatot adta Önnek, hogy irányítsa egy idősek számára készülő, kulturális híreket megjelenítő rendszer tervezését. Az adatokat a hasonló, mobil platformokon futó alkalmazásukból vegye át. Elmondja még, hogy vegye figyelembe az időskorúak gyenge látását, lassú reakcióidejét és azt, hogy a kezük gyakran nem tudja pontosan végezni a finom mozgásokat. Milyen alapelveket kell Önnek alkalmaznia a GUI tervezés során?

Típus: több. Válasz: 2,5. Pontozás: -.

A rövid válaszidőt.
A könnyű tanulhatóságot.
Demeter törvényét az architektúra tervezésekor.
Kohéziót elvét az objektumok meghatározásakor.
A felhasználói sokféleséget.
Az adatvesztés minimalizálását.

Az öröklés alkalmazásával általában csökken a forráskódban az alternatívák (case és if szerkezetek) száma.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az útvonal alapú tesztelés a kód belső szerkezetén (white box) alapul.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az „elkerülés”, „csökkentés”, „kompenzálás” és „megegyezés” olyan lehetséges intézkedések, amelyekkel a kockázat nullára csökkenthető egy projektben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az, hogy a szabványos folyamatokat dokumentáltak, a CMMI modellben legkorábban a 3-as érettségi szintre jellemző.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Béta-teszt megjelenik explicit módon a V-modellben.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Catch blokkjában lehet újonnan létrehozott kivételt dobni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy interfészben csak operációk deklarálhatóak, attribútumok nem.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy metódust el lehet látni egyszerre abstract és final módosítóval is.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy objektum notifyAll() metódusának meghívásakor a végrehajtó szál kilép az objektum monitorából.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy objektum referenciáját tartalmazó változón csak olyan metódus hívható meg, amilyen a változó statikus típusában is szerepel.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy objektum wait() metódusának meghívásakor a végrehajtó szálnak nem kell az objektum monitorában tartózkodnia.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt hálódiagramjában a kritikus úton azok a tevékenységek helyezkednek el, amelyeknek teljes időjátéka nem 0.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projekt elején van egy két hónapos időszak, amikor a felhasználói követelményeket nagyon pontosan dokumentálják.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Boardról készült fotókkal dokumentálják, mely egy projekttervezési és követési eszköz.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projekt előrehaladását a falra ragasztott cédulákkal követik, és az ezekről készült fotókkal dokumentálják.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy).

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projektben szigorúan követik a RUP (Rational Unified Process) előírásait az életciklusra vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha a „szoftvertervezés” (mint műszaki, mérnöki munka) és a „projekttervezés” (mint menedzsment feladat) élesen elkülönül egymástól.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha előfordul, hogy a teszteseteket hamarabb írják meg, mint a kódot.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy tevékenység teljes időjátéka az adott tevékenység legkésőbbi kezdésének és legkorábbi kezdésének különbségeként számolható ki.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy változó dinamikus típusa nem lehet absztrakt osztály.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Egy állapotdiagramnak (state chart) csak akkor lehet két vagy több végállapota, ha a modelben párhuzamos régiók vannak.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Előfordul, hogy naponta akár több build is készül.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Előfordulhat, hogy két szál (T1 és T2) ugyanazon objektum ugyanazon synchronized metódusát futtatva T1 T2 sorrendben lép be, de T2 T1 sorrendben lép ki.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Final metódus nem módosíthatja az attribútumok értékét.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Final metódusban használható a this változó.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Garvin ötféle szoftverminőségi definíciója között van termék alapú és folyamat alapú definíció is.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Generikus osztály példányosításakor lehet másik generikus osztály a paraméter.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Ha CMMI modellt alkalmazunk, a cég érettségi szintjét és a folyamatok képességi szintjét is vizsgálnunk kell.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Ha SPICE modellt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy a kockázatokat azonosítsuk, mert ezzel a modell egy külön folyamata foglalkozik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Ha egy szál véget ért, akkor start() metódushívással újraindítható.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Határérték tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Integrációs teszt megjelenik explicit módon a V-modellben.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Kommunikációs diagramon nem ábrázolható a párhuzamosság.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Konfigurációs elemeket nem csak a kód esetében, hanem a szoftverfejlesztés során végrehajtott összes tevékenység munkatermékeinek esetében azonosítani kell.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Konfigurációs elemeket nemcsak a kódra, hanem a szoftverfejlesztési projekt során készülő összes munkatermékre azonosítani kell.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Konstruktornak nem lehet láthatósága.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Késedelmes sprint esetén a csapatot új emberekkel bővítik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Késedelmes sprint esetén a csapatot új emberekkel bővítik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Két interfész csak akkor valósítható meg egy osztályban, ha az interfészeknek nincsen közös metódusa.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Lehet olyan private tag, aminek többször is lehet értéket adni.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Milyen elemek lehetnek egy adatfolyamábrán, beleértve a (context) diagramot is?

Típus: több. Válasz: 1,2,3,4. Pontozás: -.

Terminátor
Procesz
Adatfolyam
Adattár

Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye)

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Nem a validációs tesztelés célja megmutatni, hogy a szoftver megfelel a követelményeinek, vagy ez az, amit a vásárló szeretne.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Primitív típus is lehet generikus osztály template-paramétere.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Primitív típus tömbje is a primitív típusok közé számít.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Private tag nem szerializálódik.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Privát metódust csak privát metódusból lehet hívni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Sprint közben folytonosan követik a felhasználó igényeinek változását.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Statikus metódus nem dobhat kivételt.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Statikus metódusban használható a this változó.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Statikus tag nem szerializálódik.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Strukturális tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Subversionben update-kor változhat a munkapéldány.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Subversionben update-kor változhat a repository.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Synchronized módosítójú metódusban nem lehet wait() metódust hívni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Szerializálás körkörös hivatkozású adatszerkezeten (pl. Gyűrű) kivételt dob.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Szoftverfejlesztésnél az architekturális tervezéskor a rendszer fő komponenseinek azonosítását és a közöttük fennálló együttműködéseket definiáljuk.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Unit teszt megjelenik explicit módon a V-modellben.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Általában a szoftverfejlesztési életciklusban először a statikus tesztelés, majd a strukturális tesztelés, végül a funkcionális tesztelés technikái jutnak szerephez.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Az ekvivalencia particionális fehérdoboz tesztelési technika.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A Konfigurációmenedzsment (CM) folyamat a CMMI modell 2-es érettségi szintjén jelenik meg (ML2).

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka = 0.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A SPICE modell lépcsős folyamatfejlesztési modell.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

A szekvenciális életciklus modelll szerint minden fejlesztési fázis az előző fázis eredményeire alapul; a fázisok időben egymás után következnek.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

Nemfunkcionális követelményeket a CMMI 2-es érettségi szintjén levő cégnél nem lehet meghatározni.

Típus: egy. Válasz: 2. Pontozás: -.

Igaz
Hamis

Az útvonal alapú tesztelés és az adatfolyam alapú tesztelés a strukturális tesztelés két alapvető megközelítése.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

A feketedoboz tesztelés a függyvényelmélet elemeit használja.

Típus: egy. Válasz: 1. Pontozás: -.

Igaz
Hamis

← Vissza az előző oldalra – Szoftvertechnológia

@@ 1. sor: / 1. sor: @@
 {{Vissza|Szoftvertechnológia}}
-''Kikérdező a tárgyhonlapon lévő "Szoftvertechológia feldatok" pdf-ben lévő kérdésekhez''
+''Kikérdező a tárgyhonlapon lévő igaz/hamis kérdésekhez + Wikin fenn található vizsgákból.''
-{{Kvízoldal
+{{kvízoldal|cím=Szoftvertechnológia Igaz/Hamis|pontozás=-}}
-|cím=Szoftvertechnológia Igaz/Hamis
-|pontozás=-}}
+== A "Ez jó szoftver?" kérdés a validációhoz kapcsolódik. ==
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra.==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A "Jó ez a szoftver?" kérdés a verifikációhoz kapcsolódik. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.==
+== A CMM egy szervezet által készített összes szoftver minőségét értékeli. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha  azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.==
+== A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.==
+== A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI (Capability Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 2-es érettségi szinten kötelező. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.==
+== A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI 3-as szintjétől a szoftverfejlesztési folyamat tevékenységei dokumentáltak, szabványosítva vannak, és a szervezet szabványos szoftverfejlesztési folyamatává integrálták őket. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI 5-ös szintjétől a termelési folyamatok méréseiből számszerűsíthető visszacsatolások segítik a folyamatos folyamat-fejlesztést, amiben új, innovatív elemeket is felhasználnak. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az ekvivalencia osztály alapú tesztelés a kód belső szerkezetén alapul.==
+== A CMMI előírja, hogy a funkcionális követelményeket egy szoftverre vonatkozóan UML jelölésrendszert használó Use-case modellekkel kell leírni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Subversion-ben update-kor változhat a munkapéldány.==
+== A CMMI előírja, hogy a nemfunkcionális követelményeket egy szoftverre vonatkozóan az ISO 9126 / ISO 25000 szabvány szerint kell meghatározni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI előírja, hogy a termék méréséhez a GQM paradigmát kell használni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A GUI tervezése során figyelni kell a felhasználók sokféleségére.==
+== A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI modell alkalmazása során elfogadható, hogy a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.==
+== A CMMI modell folytonos nézetének (a folytonos CMMI-modellnek) előnye, hogy a szervezetek saját szükségleteiknek és követelményeiknek megfelelő folyamatokat tudják kiválasztani és továbbfejleszteni. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.==
+== A CMMI modellben 4-es érettségi szinten az összes, 4-es érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI modellben 5-ös érettségi szinten az összes 5-ös érettségi szinten kötelező folyamatnak legalább 5-ös képességi szintűnek kell lennie. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.==
+== A COSMIC agilis szoftverfejlesztési módszertan. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A COSMIC projekttervezési és követési eszköz. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A Continuous Integration projekttervezési és követési eszköz. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A DD-path tesztelési technika követelményspecifikáción alapul. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.==
+== A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A GQM (Goal-Question-Metric) a QIP (Quality Improvement Paradigm) egyik eszköze. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A GQM paradigma a kód minőségének mérésére nem alkalmazható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A GQM paradigma az emberi erőforrások mérésére nem alkalmazható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A GQM paradigma tesztelési folyamatok mérésére nem alkalmazható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A GUI tervezése során figyelni kell a felhasználók sokféleségére. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A Követelménymenedzsment (REQM) folyamat a CMMI modell 4-es érettségi szintjén (ML4) jelenik meg. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A PRINCE a RUP továbbfejlesztett változata. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.==
+== A Projekt tervezés (PPL) folyamat a CMMI modell 3-as érettségi szintjén jelenik meg. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A RUP agilis szoftverfejlesztési életciklus modell. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Collaboration-Transition. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A RUP egyik fázisai közé tartozik a IECT, azaz Inception-Elaboration-Construction-Transition. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie.==
+== A RUP előírja, hogy a szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan, mert ez mindig a felhasználók feladata. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A RUP nem agilis fejlesztési módszertan. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projekt tervben a kritikus úton levő tevékenységek hossza megváltoztatható anélkül, hogy ez a projekt teljes átfutását befolyásolná.==
+== A RUP nem tartalmaz projektirányítási eljárásokat. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A RUP szekvenciális szoftverfejlesztési módszertan. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.==
+== A SPICE modell 6 képességi szintet határoz meg egy folyamat esetében. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.==
+== A SPICE modell 6 érettségi szintet határoz meg egy szoftverfejlesztő cég számára, 0-tól 5-ig, így a szoftverfejlesztő cégek érettsége összemérhető. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.==
+== A SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A rövid válaszidő minden szoftver esetében alapkövetelmény.==
+== A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az iteratív és inkrementális fejlesztések hátránya, hogy a felhasználói visszajelzések későn jelennek meg a fejlesztési folyamatban.==
+== A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.==
+== A Scrum szekvenciális szoftverfejlesztési életciklus modell. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha  a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.==
+== A Scrum szerint a cég vezetői „Csirkék”. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A konfigurációkezelésre nem kell időt tervezni a projektben.==
+== A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A TSP projekttervezési és követési eszköz. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az útvonal alapú tesztelés a kód belső szerkezetén alapul.==
+== A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Késedelmes sprint esetén a csapatot új emberekkel bővítik.==
+== A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A V-modell a vízesés-modellből kialakított iteratív modell. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A V-modell az agilis fejlesztésből kialakult életciklus modell, melyet a RUP is alkalmaz. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A vízesés modell és a V-modell szekvenciális életciklus modellek.==
+== A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.==
+== A V-modellben megjelenik a dinamikus teszt. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== A V-modellben megjelenik a regressziós teszt. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Integrációs teszt megjelenik explicit módon a V-modellben.==
+== A V-modellben megjelenik a stressz teszt. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A bejelentkező képernyőn nem kell megadni a felhasználó keresztnevét, csak a vezetéknevét. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A csapat sebessége projekttervezési és követési eszköz. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A jó szoftvertervező nem vizsgál meg több alternatívát egy rendszer tervezése során, mert tapasztalatai alapján ismeri a legjobbat, és azt választja.==
+== A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A dinamikus teszt explicit módon megjelenik a CMMI modellben. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.==
+== A dinamikus tesztelés alapulhat követelményspecifikáción és a kód belső szerkezetén is. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projekt előrehaladását a falra ragasztott cédulákkal követik, és az ezekről készült fotókkal dokumentálják.==
+== A döntési tábla alapú tesztelési technika követelményspecifikáción alapul. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.==
+== A fehér doboz teszt megjelenik explicit módon a V-modellben. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== A fehér-doboz tesztelés a kód belső szerkezetén alapul. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A fehér-doboz tesztelési technika követelményspecifikáción alapul. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A fehérdoboz tesztelés alapja az UML diagramok. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.==
+== A felülvizsgálat, átvizsgálás, review, audit dinamikus verifikációs technikák. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A for (X x : c) típusú (foreach) ciklusban a c változóval referált objektum meg kell valósítsa a java.util.Collection interfészt. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.==
+== A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.==
+== A határérték analízis a kód belső szerkezetén alapul. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A határérték tesztelés és az ekvivalencia particionálás funkcionális tesztelési technikák, a követelményspecifikáción alapszanak. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftvertermék minőségét nem lehet egységesen meghatározni; minőségi profilt kell kialakítani az egyes esetek sajátosságait figyelembe véve.==
+== A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI modellben 4-es érettségi szinten az összes, 4-as érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie.==
+== A jó szoftver esetében a rövid válaszidő és a folyamatos rendelkezésre állás mindig alapkövetelmény. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A jó szoftver esetében a rövid válaszidő és a megfelelő felhasználói dokumentáció mindig alapkövetelmény. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha előfordul, hogy a teszt eseteket hamarabb írják meg, mint a kódot.==
+== A jó szoftvertervező nem vizsgál meg több alternatívát egy rendszer tervezése során, mert tapasztalatai alapján ismeri a legjobbat, és azt választja. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Béta-teszt megjelenik explicit módon a V-modellben.==
+== A keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.==
+== A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket minimálisra csökkentsük. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az ekvivalencia osztály alapú tesztelési technika követelményspecifikáción alapul.==
+== A kockázatmenedzsment célja, hogy a kockázatokat azonosítva előfordulási valószínűségüket nullára csökkentsük. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A kockázatmenedzsment lényege, hogy a megjelenő problémákat felmerülésük után a lehető legrövidebb időn belül megoldjuk. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulására felkészüljünk, és ezáltal hatásukat minimálisra csökkentsük. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.==
+== A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulását teljesen megakadályozzuk, és ezáltal hatásukat nullára csökkentsük. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A határérték analízis a kód belső szerkezetén alapul.==
+== A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A konfigurációkezelésre időt kell tervezni a projektben. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A konfigurációkezelésre nem kell időt tervezni a projektben. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik, mely egy projekttervezési és követési eszköz. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A kötegelt feldolgozás (batch) az adatfolyam (pipes and filters) architektúratípushoz illeszkedik. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A követelményeket a kódban is pontosan be kell tudni azonosítani. Ennek egyik módja, hogy a kódrészletekbe kommentként beírjuk a vonatkozó követelményeket. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A követelménymenedzsment egyik feladata a követelmények változásának követése. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A beszállókártyát ki lehet nyomtatni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A kódminőséget a V-modellben a refaktorálás (refactoring) tevékenység hivatott növelni.==
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell.==
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az asszociáció, a kompozíció, a függőség és a specializáció közül a specializáció a leggyengébb. (UML2)==
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.==
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.==
+== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nemfunkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A válaszidőre vonatkozó követelményt nem-funkcionális követelményként szoktuk kezelni.==
+== A megbízhatósági követelmények nemfunkcionális követelmények. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.==
+== A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A moderálás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A mérséklés, a megegyezés, a csökkentés és az elkerülés lehetséges intézkedések a kockázat elhárítására. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftvertermék tartalmazza a felhasználói adatokat.==
+== A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A nem definiált láthatóságú attribútum publikusnak számít. (UML2) ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling). ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion). ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.==
+== A posztkondíciók biztosítása a hívott metódus feladata. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A tesztelés során készülő dokumentumokat nem kell verziókövetésnek alávetni.==
+== A prekondíciók biztosítása a hívott metódus feladata. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.==
+== A primitív típusokhoz tartozó csomagoló osztályok (wrapper classes) nem változtathatók (immutable). ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni.==
+== A progressziós teszt explicit módon megjelenik a CMMI modellben. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A fehér-doboz tesztelés a kód belső szerkezetén alapul.==
+== A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák, ha az a vízesés modellt követi. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)==
+== A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt olyan tevékenységsorozat, amely korlátos (többek között) a készülő szoftver válaszidejére vonatkozóan. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt olyan tevékenységsorozat, amely korlátos (többek között) a minőségre vonatkozóan. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).==
+== A projekt olyan tevékenységsorozat, amely nem korlátos (többek között) a minőségre vonatkozóan. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt tervben a kritikus úton levő tevékenységek hossza nem változtatható meg anélkül, hogy ez a projekt teljes átfutását befolyásolná. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka nem egyenlő 0-val. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben csak fejlesztési tevékenységeket (mint: követelményspecifikáció, design, kódolás, tesztelés) kell megtervezni idő, költség és erőforrás szempontjából. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben időt kell tervezni a mérések és elemzések végzésére is. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A refaktorálás az, amikor a szoftvert úgy fejlesztjük tovább, hogy a belső viselkedés változatlan marad, de külső szerkezet megújul. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A regressziós teszt explicit módon megjelenik a CMMI modellben. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszer architektúrája befolyásolja a rendszer hibatűrését, rendelkezésre állását, robusztusságát. Az alkalmazás számára választott szerkezet ezért nemfunkcionális rendszerkövetelményektől is függhet. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszernek 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszernek a hét minden napján, 0-24 óra között működnie kell. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszertervezés során alapvetően a rendszer statikus és dinamikus nézetét írjuk le. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rendszerteszt a specifikáció ellenőrzésére irányul. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A rövid válaszidő minden szoftver esetében alapkövetelmény. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A rövid válaszidő nem minden szoftver esetében alapkövetelmény. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A scrum csapatban – naponta többször cserélődő – párokban programoznak. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A sikeres teszteseteket nem szükséges dokumentálni, ha agilisan dolgozunk. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A strukturális tesztelés előnye, hogy pontos méréseket tesz lehetővé a teszt lefedettséggel kapcsolatban. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A strukturális tesztelés esetében a teszteseteket a követelmények alapján hozzuk létre. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A strukturális tesztelés nem feltételezi a kód futtatását. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A strukturális teszt explicit módon megjelenik a CMMI modellben. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A projektben csak fejlesztési tevékenységeket (mint: követelményspecifikáció, design, kódolás, tesztelés) kell megtervezni idő, költség és erőforrás szempontjából.==
+== A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftver az elkészült forráskódot jelenti. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A “sprint review” eredménye a product backlog új változata.==
+== A szoftver implementálása nem csak a kódolást jelenti. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Ha ISO 25000 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.==
+== A szoftver implementálása pontosan a kódolást jelenti. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftver jó minősége pontosan a jó teszteléssel biztosítható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftver jó minősége pontosan a jó és rendszeres auditokkal biztosítható. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A rövid válaszidő nem minden szoftver esetében alapkövetelmény.==
+== A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMM egy szervezet által készített összes szoftver minőségét értékeli.==
+== A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftver minőségét pontosan a kód jó minősége jelenti. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy tevékenység teljes időjátéka az adott tevékenység legkésőbbi kezdésének és legkorábbi kezdésének különbségeként számolható ki.==
+== A szoftver tesztelése nem csak a kód futtatását jelenti. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftver implementálása pontosan a kódolást jelenti.==
+== A szoftverfejlesztés spirális modelljének 1. Szektorában a megoldandó feladat a fejlesztés és validálás. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== A szoftverfejlesztés spirális modelljének 2. Szektorában a megoldandó feladat a kockázat elemzése. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftverfejlesztés spirális modelljének 3. Szektorában a megoldandó feladat a célok kijelölés. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Subversion-ben update-kor változhat a repository.==
+== A szoftverfejlesztés spirális modelljének 4. Szektorában a megoldandó feladat az új fázis tervezése. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftverfejlesztés vízesésmodellje szerint a fejlesztésnek eslő fázisa a követelmény. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftverfejlesztésnél a Specifikáció célja "a követelményeket kielégítő rendszer magas absztrakciós szintű formális leírása”. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A projektet indító szervezet Lean filozófiát alkalmaz.==
+== A szoftverspecifikálást a követelmény előzi meg. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A szoftverspecifikálást a tervezés követi. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.==
+== A szoftvertermék minőségét nem lehet egységesen meghatározni; minőségi profilt kell kialakítani az egyes esetek sajátosságait figyelembe véve. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.==
+== A szoftvertermék tartalmazza a felhasználói adatokat. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.==
+== A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Agilis projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.==
+== A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).==
+== A tanonckodás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A tanúsítás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.==
+== A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.==
+== A tapasztalt szoftvertervezőnek nem kell több alternatívát megvizsgálnia egy rendszer tervezése során, mert mindig a legjobbat fogja választani. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projekt elején van egy két hónapos időszak, amikor a felhasználói követelményeket nagyon pontosan dokumentálják.==
+== A tervezést az implementáció követi. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftvertermék nem tartalmazza a felhasználói adatokat, mert azokat a felhasználók gyakran megváltoztatják.==
+== A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a „szoftvertervezés” (mint műszaki, mérnöki munka) és a „projekttervezés” (mint menedzsment feladat) élesen elkülönül egymástól.==
+== A tesztelés a kulcsfontosságú fejlesztések után kezdődik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A nem definiált láthatóságú attribútum publikusnak számít. (UML2)==
+== A tesztelés a szoftver minőségének biztosítására szolgáló egyetlen lehetséges módszer, mert csak a tesztelés teszi lehetővé minőségi jellemzők mérését. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)==
+== A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A konfigurációkezelésre időt kell tervezni a projektben.==
+== A tesztelés pontosan a hibakeresést és hibajavítást jelenti. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A tesztelés pontosan a tesztek futtatását jelenti, de nem azonos a hibakereséssel. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A tesztelés statikus verifikációs technika. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A tesztelési folyamatokat leíró TMMI modell szerkezete teljesen megegyezik a CMMI modell szerkezetével. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.==
+== A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Unit teszt megjelenik explicit módon a V-modellben.==
+== A teszteseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A tulajdonos jó szerepkör típus szoftver átvizsgálásakor. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projektvezetői szerepkört a „Scrum master” látja el.==
+== A tényleges és az elvárt eredmények összehasonlítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Konfigurációs elemeket nem csak a kód esetében, hanem a szoftverfejlesztés során végrehajtott összes tevékenység munkatermékeinek esetében azonosítani kell.==
+== A use-case diagramon nem szerepelhet függőség (dependency). ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A use-case diagramon szereplő asszociációnak is van multiplicitása. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Agilis környezetben a készülő kód méretét nem lehet becsülni.==
+== A use-case leírás és az adatfolyamábra egyenértékű. (UML2) ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.==
+== A use-case leírásban szerepelhetnek az elő- és utófeltételek is. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A validáció explicit módon megjelenik a CMMI modellben. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák, ha az a vízesés modellt követi.==
+== A validálás a követelmények ellenőrzésére irányul. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A DD-path tesztelési technika követelményspecifikáción alapul.==
+== A verifikáció explicit módon megjelenik a CMMI modellben. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A válaszidőnek mindig 2 sec alatt kell lennie. (Webes alkalmazás nemfunkcionális követelménye.) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A válaszidőre vonatkozó követelményt nemfunkcionális követelményként szoktuk kezelni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A vízesés modell és a V-modell iteratív életciklus modellek. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A fehér-doboz tesztelési technika követelményspecifikáción alapul.==
+== A vízesés modell és a V-modell szekvenciális életciklus modellek. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A “projekt terv” pontosan a tevékenységek hálódiagramját vagy sávdiagramját jelenti. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== A “sprint review” eredménye a product backlog új változata. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A “tesztelési terv” pontosan a tesztesetek leírását jelenti. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A határérték analízis tesztelési technika követelményspecifikáción alapul.==
+== A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie.==
+== A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.==
+== A „félig kész munka” a szoftverben a Hét Pazarlás egyike. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszteseteket rendszeresen felül kell vizsgálni és módosítani kell. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Garvin 5-féle definíciót adott a szoftverminőségre.==
+== A „féregírtó paradoxon” a „Hét Pazarlás” egyike. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulására felkészüljünk, és ezáltal hatásukat minimálisra csökkentsük.==
+== A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.==
+== A „tesztvezérelt fejlesztés” során cél, hogy minden funkcióra már az implementálása előtt elkészüljenek a tesztesetek. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.==
+== Abstract osztálynak lehet final metódusa. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.==
+== Agilis fejlesztés esetében semmit sem kell dokumentálni, lényeg, hogy a kód legyen minél előbb kész. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projektben szigorúan követik a RUP (Rational Unified Process) előírásait az életciklusra vonatkozóan.==
+== Agilis környezetben a készülő kód méretét nem lehet becsülni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis környezetben a készülő kód méretét nem lehet mérni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.==
+== Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.==
+== Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A követelménymenedzsment egyik feladata a követelmények változásának követése.==
+== Agilis projektben Burn Down Chart-tal lehet a projekt előrehaladását követni. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftver implementálása nem csak a kódolást jelenti.==
+== Agilis projektben a követelményeket a kódban nem kell tudni beazonosítani, mert a követelmények gyakran változnak. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni, és annak szerves része is. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.==
+== Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilis szoftverfejlesztésnél előfordulhat, hogy a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy). ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Ha Scrum-ot alkalmazunk, nem lehet kritikus utat számolni.==
+== Agilisan dolgozó cégnél a CMMI nem alkalmazható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást eredményez. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.==
+== Az EF (Experience Factory) a QIP (Quality Improvement Paradigm) egyik eszköze. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulását teljesen megakadályozzuk, és ezáltal hatásukat nullára csökkentsük.==
+== Az Extreme Programming szerinti életciklusban a User Story központi helyen van. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.==
+== Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A projektben időt kell tervezni a mérések és elemzések végzésére is.==
+== Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2)==
+== Az ISO 9001 alapú audit a kód minőségét vizsgálja. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A COSMIC agilis szoftverfejlesztési módszertan.==
+== Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A tényleges és az elvárt eredmények összehasonlítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ISO 9001 szabvány és a TMMI modell együttesen is alkalmazható egy agilisan működő szoftvercégnél. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.==
+== Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A kódot össze kell tudni rendelni a követelményekkel, a design elemekkel és a tesztesetekkel is.==
+== Az adott helyzetben legmegfelelőbb tesztelési technikák kiválasztása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2) ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Az aktor és a use-case is classifier (osztályszerű). ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az adott helyzetben legmegfelelőbb tesztelési technikák kiválasztása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== Az asszociáció, a kompozíció, a függőség és a specializáció közül a specializáció a leggyengébb. (UML2) ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az egyenrangú szemle (Peer review) az egyetlen tesztelési technika, amelyet a CMMI modell név szerint említ a VER (Verifikáció) folyamat sajátos céljaként.==
+== Az egyenrangú szemle (Peer review) az egyetlen (statikus) tesztelési technika, amelyet a CMMI modell név szerint említ a VER (Verifikáció) folyamat sajátos céljaként. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek.==
+== Az egyetlen agilis projekt menedzsment eszköz a Scrum. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A beszállókártyát ki lehet nyomtatni.==
+== Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az elnök jó szerepkör típus szoftver átvizsgálásakor. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az implementáció a kódoláson kívül egyéb elemeket is tartalmaz, például a műszaki dokumentáció elkészítését és a változásmenedzsmentet. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.==
+== Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az iteratív és inkrementális fejlesztések egyik előnye, hogy a felhasználói visszajelzések viszonylag korán megjelennek a fejlesztési folyamatban. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az iteratív és inkrementális fejlesztések hátránya, hogy a felhasználói visszajelzések későn jelennek meg a fejlesztési folyamatban. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A use-case leírás és az adatfolyamábra egyenértékű. (UML2)==
+== Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az Önt alkalmazó cég műszaki igazgatója azt a feladatot adta Önnek, hogy irányítsa egy idősek számára készülő, kulturális híreket megjelenítő rendszer tervezését. Az adatokat a hasonló, mobil platformokon futó alkalmazásukból vegye át. Elmondja még, hogy vegye figyelembe az időskorúak gyenge látását, lassú reakcióidejét és azt, hogy a kezük gyakran nem tudja pontosan végezni a finom mozgásokat. Milyen alapelveket kell Önnek alkalmaznia a GUI tervezés során? ==
+{{kvízkérdés|típus=több|válasz=2,5|pontozás=-}}
+# A rövid válaszidőt.
+# A könnyű tanulhatóságot.
+# Demeter törvényét az architektúra tervezésekor.
+# Kohéziót elvét az objektumok meghatározásakor.
+# A felhasználói sokféleséget.
+# Az adatvesztés minimalizálását.
+== Az öröklés alkalmazásával általában csökken a forráskódban az alternatívák (case és if szerkezetek) száma. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az útvonal alapú tesztelés a kód belső szerkezetén (white box) alapul. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az „elkerülés”, „csökkentés”, „kompenzálás” és „megegyezés” olyan lehetséges intézkedések, amelyekkel a kockázat nullára csökkenthető egy projektben. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Az, hogy a szabványos folyamatokat dokumentáltak, a CMMI modellben legkorábban a 3-as érettségi szintre jellemző. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Agilis környezetben a készülő kód méretét nem lehet mérni.==
+== Béta-teszt megjelenik explicit módon a V-modellben. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Általában a szoftverfejlesztési életciklusban először a statikus tesztelés, majd a strukturális tesztelés, végül a funkcionális tesztelés technikái jutnak szerephez.==
+== Catch blokkjában lehet újonnan létrehozott kivételt dobni. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik.==
+== Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A tapasztalt szoftvertervezőnek nem kell több alternatívát megvizsgálnia egy rendszer tervezése során, mert mindig a legjobbat fogja választani.==
+== Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy interfészben csak operációk deklarálhatóak, attribútumok nem. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni.==
+== Egy metódust el lehet látni egyszerre abstract és final módosítóval is. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.==
+== Egy objektum notifyAll() metódusának meghívásakor a végrehajtó szál kilép az objektum monitorából. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.==
+== Egy objektum referenciáját tartalmazó változón csak olyan metódus hívható meg, amilyen a változó statikus típusában is szerepel. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy objektum wait() metódusának meghívásakor a végrehajtó szálnak nem kell az objektum monitorában tartózkodnia. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az egyetlen agilis projekt menedzsment eszköz a Scrum.==
+== Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A tesztelés a kulcsfontosságú fejlesztések után kezdődik.==
+== Egy osztálynak több egymástól független ősosztálya is lehet. (UML2) ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt hálódiagramjában a kritikus úton azok a tevékenységek helyezkednek el, amelyeknek teljes időjátéka nem 0. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Döntési tábla alapú teszt megjelenik explicit módon a V-modellben.==
+== Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt lehet agilis, ha a projekt elején van egy két hónapos időszak, amikor a felhasználói követelményeket nagyon pontosan dokumentálják. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal.==
+== Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Boardról készült fotókkal dokumentálják, mely egy projekttervezési és követési eszköz. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Az ISO 9001 alapú audit a kód minőségét vizsgálja.==
+== Egy projekt lehet agilis, ha a projekt előrehaladását a falra ragasztott cédulákkal követik, és az ezekről készült fotókkal dokumentálják. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt lehet agilis, ha a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. Tesztelő és fejlesztő lehet ugyanaz a személy). ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt lehet agilis, ha a projektben szigorúan követik a RUP (Rational Unified Process) előírásait az életciklusra vonatkozóan. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.==
+== Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata.==
+== Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt lehet agilis, ha a „szoftvertervezés” (mint műszaki, mérnöki munka) és a „projekttervezés” (mint menedzsment feladat) élesen elkülönül egymástól. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== Egy projekt lehet agilis, ha előfordul, hogy a teszteseteket hamarabb írják meg, mint a kódot. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy tevékenység teljes időjátéka az adott tevékenység legkésőbbi kezdésének és legkorábbi kezdésének különbségeként számolható ki. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy változó dinamikus típusa nem lehet absztrakt osztály. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Egy állapotdiagramnak (state chart) csak akkor lehet két vagy több végállapota, ha a modelben párhuzamos régiók vannak. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.==
+== Előfordul, hogy naponta akár több build is készül. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Előfordulhat, hogy két szál (T1 és T2) ugyanazon objektum ugyanazon synchronized metódusát futtatva T1 T2 sorrendben lép be, de T2 T1 sorrendben lép ki. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Ha ISO 9001 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.==
+== Final metódus nem módosíthatja az attribútumok értékét. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.==
+== Final metódusban használható a this változó. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Garvin ötféle szoftverminőségi definíciója között van termék alapú és folyamat alapú definíció is. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Generikus osztály példányosításakor lehet másik generikus osztály a paraméter. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Ha CMMI modellt alkalmazunk, a cég érettségi szintjét és a folyamatok képességi szintjét is vizsgálnunk kell. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Ha SPICE modellt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy a kockázatokat azonosítsuk, mert ezzel a modell egy külön folyamata foglalkozik. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
+== Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A szoftver az elkészült forráskódot jelenti.==
+== Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)==
+== Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Ha egy szál véget ért, akkor start() metódushívással újraindítható. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Határérték tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Integrációs teszt megjelenik explicit módon a V-modellben. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A scrum csapatban – naponta többször cserélődő – párokban programoznak.==
+== Kommunikációs diagramon nem ábrázolható a párhuzamosság. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.==
+== Konfigurációs elemeket nem csak a kód esetében, hanem a szoftverfejlesztés során végrehajtott összes tevékenység munkatermékeinek esetében azonosítani kell. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a szoftvertervezés szerves része a User Story/felhasználói történet/story point meghatározása.==
+== Konfigurációs elemeket nemcsak a kódra, hanem a szoftverfejlesztési projekt során készülő összes munkatermékre azonosítani kell. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha  előfordul, hogy naponta akár több build is készül.==
+== Konstruktornak nem lehet láthatósága. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Késedelmes sprint esetén a csapatot új emberekkel bővítik. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Késedelmes sprint esetén a csapatot új emberekkel bővítik. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Két interfész csak akkor valósítható meg egy osztályban, ha az interfészeknek nincsen közös metódusa. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Lehet olyan private tag, aminek többször is lehet értéket adni. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Milyen elemek lehetnek egy adatfolyamábrán, beleértve a (context) diagramot is? ==
+{{kvízkérdés|típus=több|válasz=1,2,3,4|pontozás=-}}
+# Terminátor
+# Procesz
+# Adatfolyam
+# Adattár
+== Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye) ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Nem a validációs tesztelés célja megmutatni, hogy a szoftver megfelel a követelményeinek, vagy ez az, amit a vásárló szeretne. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Primitív típus is lehet generikus osztály template-paramétere. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Primitív típus tömbje is a primitív típusok közé számít. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Private tag nem szerializálódik. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Privát metódust csak privát metódusból lehet hívni. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Sprint közben folytonosan követik a felhasználó igényeinek változását. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Statikus metódus nem dobhat kivételt. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Statikus metódusban használható a this változó. ==
+{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
+# Igaz
+# Hamis
+== Statikus tag nem szerializálódik. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.==
+== Strukturális tesztelés esetében a teszteseteket a kód belső szerkezete alapján hozzuk létre. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Egy projekt lehet agilis, ha a projektben az érdekelt felek többféle szerepet is betölthetnek (pl. tesztelő és fejlesztő lehet ugyanaz a személy).==
+== Subversionben update-kor változhat a munkapéldány. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Ha ISO 12207 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.==
+== Subversionben update-kor változhat a repository. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== Sprint közben folytonosan követik a felhasználó igényeinek változását.==
+== Synchronized módosítójú metódusban nem lehet wait() metódust hívni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.==
+== Szerializálás körkörös hivatkozású adatszerkezeten (pl. Gyűrű) kivételt dob. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.==
+== Szoftverfejlesztésnél az architekturális tervezéskor a rendszer fő komponenseinek azonosítását és a közöttük fennálló együttműködéseket definiáljuk. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== Ha SPICE modellt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy a kockázatokat azonosítsuk, mert ezzel a modell egy külön folyamata foglalkozik.==
+== Unit teszt megjelenik explicit módon a V-modellben. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Általában a szoftverfejlesztési életciklusban először a statikus tesztelés, majd a strukturális tesztelés, végül a funkcionális tesztelés technikái jutnak szerephez. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.==
+== Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== Az ekvivalencia particionális fehérdoboz tesztelési technika. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A fehér doboz teszt megjelenik explicit módon a V-modellben.==
+== A Konfigurációmenedzsment (CM) folyamat a CMMI modell 2-es érettségi szintjén jelenik meg (ML2). ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka = 0. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A SPICE modell lépcsős folyamatfejlesztési modell. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön.==
+== A szekvenciális életciklus modelll szerint minden fejlesztési fázis az előző fázis eredményeire alapul; a fázisok időben egymás után következnek. ==
 {{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
 # Igaz
 # Hamis
-== A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni.==
+== Nemfunkcionális követelményeket a CMMI 2-es érettségi szintjén levő cégnél nem lehet meghatározni. ==
 {{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
 # Igaz
 # Hamis
+== Az útvonal alapú tesztelés és az adatfolyam alapú tesztelés a strukturális tesztelés két alapvető megközelítése. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
+== A feketedoboz tesztelés a függyvényelmélet elemeit használja. ==
+{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
+# Igaz
+# Hamis
 ----
 {{Vissza|Szoftvertechnológia}}