„Szoftvertechnológia (régi)/Igaz-Hamis kikérdező” változatai közötti eltérés
→A projektvezetői szerepkört a „Scrum master” látja el.: Egyértelműsítés, agilis munkavégzésre vonatokik a kérdés |
Új kérdések hozzáadása. |
||
| 128. sor: | 128. sor: | ||
== Késedelmes sprint esetén a csapatot új emberekkel bővítik.== | == Késedelmes sprint esetén a csapatot új emberekkel bővítik.== | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
| 191. sor: | 186. sor: | ||
# Hamis | # Hamis | ||
== A szoftvertermék minőségét | == A szoftvertermék minőségét meg lehet meghatározni; a rövid válaszidő és a folyamatos rendelkezésre állás mindig a jó minőség eleme. == | ||
{{kvízkérdés|típus=egy|válasz= | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
| 281. sor: | 276. sor: | ||
# Hamis | # Hamis | ||
== A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.== | == 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=-}} | {{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 | # Igaz | ||
# Hamis | # Hamis | ||
| 377. sor: | 377. sor: | ||
== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 441. sor: | 436. sor: | ||
# Hamis | # Hamis | ||
== Agilis környezetben a készülő kód méretét nem lehet becsülni.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 511. sor: | 506. sor: | ||
# Hamis | # Hamis | ||
== Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 536. sor: | 531. sor: | ||
# Hamis | # Hamis | ||
== Ha | == Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni. == | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 621. sor: | 621. sor: | ||
# Hamis | # Hamis | ||
== Agilis környezetben a készülő kód méretét nem lehet mérni.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 641. sor: | 641. sor: | ||
# Hamis | # Hamis | ||
== A rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni.== | == A rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni; ; az a fontos, hogy a legvégső verzió rendelkezésre álljon.== | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 746. sor: | 746. sor: | ||
# Hamis | # Hamis | ||
== A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # 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).== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # 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.== | == 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. == | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== Sprint közben folytonosan követik a felhasználó igényeinek változását.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.== | == A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike. == | ||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # 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.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.== | == 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=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
# Hamis | # Hamis | ||
== A fehér doboz teszt megjelenik explicit módon a V-modellben.== | == A fehér doboz teszt megjelenik explicit módon a V-modellben. == | ||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | {{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | ||
# Igaz | # Igaz | ||
| 800. sor: | 800. sor: | ||
# Igaz | # Igaz | ||
# Hamis | # 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. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Minden primitív típusnak van csomagoló (wrapper) osztálya. == | |||
{{kvízkérdés|típus=egy|válasz=1|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 | |||
== 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 | |||
== Statikus metódus nem dobhat kivételt. == | |||
{{kvízkérdés|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. == | |||
{{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 | |||
== 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 | |||
== 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 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 | |||
== 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 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 | |||
== 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 | |||
== Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez. == | |||
{{kvízkérdés|típus=egy|válasz=2|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 | |||
== 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 | |||
== 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 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 | |||
== Catch blokkjában lehet újonnan létrehozott kivételt dobni. == | |||
{{kvízkérdés|típus=egy|válasz=1|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 | |||
== Abstract osztálynak lehet final metódusa. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Final metódusban használható a this változó. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 | |||
== Egy szál csak akkor hajthat végre notify() metódushívást, ha a hívott objektum monitorában tartózkodik. == | |||
{{kvízkérdés|típus=egy|válasz=|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 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 | |||
== Konstruktornak nem lehet láthatósága. == | |||
{{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 | |||
== Statikus tag nem szerializálódik. == | |||
{{kvízkérdés|típus=egy|válasz=1|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 | |||
== 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 | |||
== Statikus metódusban használható a this változó. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 | |||
== 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 | |||
== Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez. == | |||
{{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 | |||
== 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 | |||
== 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 | |||
== 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 leszármazott osztályok közötti csatolás (coupling). == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az alternatívák (case és if szerkezetek) száma. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 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 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 | |||
== 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 | |||
== 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 | |||
== Késedelemes sprint esetén a csapatot új emberekkel bővítik. == | |||
{{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 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 “sprint review” eredménye a product backlog új változata. == | |||
{{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 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 | |||
== 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 | |||
== 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 | |||
== Az aktor és a use-case is classifier (osztályszerű). == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 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 | |||
== 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 | |||
== 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 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 | |||
== Ö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 | |||
== Ö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 | |||
== 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 | |||
== 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 | |||
== 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 szoftver tartalmazza a felhasználói adatokat. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 | |||
== 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 | |||
== 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 szoftver az elkészült forráskódot jelenti. == | |||
{{kvízkérdés|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. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A CMMI (Capabilitiy 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 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 | |||
== Egy cégnek választani kell , hogy CMMI modellt , vagy TMMI (Test Maturity Model Integration) modellt alkalmaz. A kettő együtt nem alkalmazható. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A CMMI 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 | |||
== 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 | |||
== 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 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 | |||
== 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 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 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 | |||
== 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 | |||
== 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 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 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 | |||
== 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 | |||
== 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 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 | |||
== 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 | |||
== 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 | |||
== A „szoftvertervezés” (mint műszaki, mérnöki munka) és "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 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 | |||
== A szoftvertervezés szerves része a User Story / felhasználói történet / story point meghatározása. == | |||
{{kvízkérdés|típus=egy|válasz=1|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=|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 | |||
== 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 követelmények modellezésének hármas csoportosítása (IREB szerint): adat, viselkedés, funkcionalitás. == | |||
{{kvízkérdés|típus=egy|válasz=1|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 | |||
== 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 | |||
== 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 | |||
== 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 | |||
== 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 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 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 | |||
== 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 jellemzője, hogy független változókat feltételez. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az ekvivalencia osztály alapú tesztelés alkalmazásakor ismernünk kell a program struktúráját. == | |||
{{kvízkérdés|típus=egy|válasz=2|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 | |||
== 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 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 | |||
== 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 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 | |||
== 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 | |||
== 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 „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 folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény. == | |||
{{kvízkérdés|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. == | |||
{{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 | |||
== Egy cég alkalmazhatja együttesen a CMMI modellt és az ISO 9001 szabványt. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az ISO 9001 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. == | |||
{{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 | |||
== 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 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 V-modellben megjelenik a stressz teszt. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A V-modellben megjelenik a dinamikus teszt. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A V-modellben megjelenik a peer review. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A V-modellben megjelenik a béta teszt. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A V-modellben megjelenik a regressziós teszt. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A V-modellben megjelenik az integrációs teszt. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Burndown Chart tipikus agilis projekttervezési és követési eszköz. == | |||
{{kvízkérdés|típus=egy|válasz=1|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 Planning Joker projekttervezési és követési eszköz. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Kanban Boardról készült fotók egy projekttervezési és követési eszköz. == | |||
{{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 TSP projekttervezési és követési eszköz. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Continous Integration projekttervezési és követési eszköz. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A DoD (Definition of Done) projekttervezési és követési eszköz. == | |||
{{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 | |||
== 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 | |||
== A strukturális tesztelés esetében a teszt eseteket a követelmények alapján hozzuk létre. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 | |||
== Az EF (Experience Factory) a QIP (Quality Improvement Pradigm) egyik eszköze. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 | |||
== 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 | |||
== 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 12207 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. == | |||
{{kvízkérdés|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 nullára csökkentsük. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Ha Scrum-ot 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 | |||
== 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 verifikáció explicit módon megjelenik a CMMI modellben. == | |||
{{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 | |||
== A peer review explicit módon megjelenik a CMMI modellben. == | |||
{{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 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 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 struktúrális teszt explicit módon megjelenik a CMMI modellben. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az uni teszt explicit módon megjelenik a CMMI modellben. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A GQM (Goal-Question-Metric) a QIP (Quality Improvement Pradigm) egyik eszköze. == | |||
{{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 | |||
== Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni. == | |||
{{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 | |||
== 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 | |||
== 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 | |||
== 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 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 | |||
== 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 | |||
== 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 készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A tesztelés RUP módszerrel történik. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A projektkövetés egyik eszköze a ProjektCsapat sebességének (Team Velocity) mérése. == | |||
{{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. == | |||
{{kvízkérdés|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. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A projektet indító szervezet Lean filozófiát alkalmaz. == | |||
{{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 | |||
== A RUP agilis szoftverfejlesztési életciklus modell. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az ISO 25000 szabványcsalád a szoftverfejlesztési folyamat minőségével foglalkozik. == | |||
{{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 folyamatos rendelkezésre állás mindig alapkövetelmény. == | |||
{{kvízkérdés|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. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Az ISO 12207 szabvány semmilyen életciklus modellt nem ír le. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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=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 “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 | |||
== Agilis szoftvertervezés szerves része a User Story / felhasználói történet / Story Point meghatározása. == | |||
{{kvízkérdés|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. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== 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 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 | |||
== Ha Scrum-ot 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=|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 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 | |||
== Határérték tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Peer review egy dinamikus tesztelési technika, amelyik a CMMI modellben is megjelenik. == | |||
{{kvízkérdés|típus=egy|válasz=2|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 | |||
== 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 | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A teszt eseteknek 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 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 Scrum szekvenciális szoftverfejlesztési életciklus modell. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A „féregírtó paradoxon” a „Hét Pazarlás” egyike. == | |||
{{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 | |||
== 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 | |||
== 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 | |||
== 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 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 “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 | |||
== 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 | |||
== 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 | |||
== Nem megengedhető a CMMI modell szerint, hogy a projekt előrehaladását Kanban Boardról készített fotókkal dokumentálják. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A sikeres teszt eseteket nem szükséges dokumentálni, ha agilisan dolgozunk. == | |||
{{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 | |||
== Ha Scrum-ot alkalmazunk, a kód méretét nem lehet COSMIC módszerrel mérni. == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel kell mérni. == | |||
{{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 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 | |||
== Strukturális tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre. == | |||
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== A Peer Review statikus tesztelési technika. == | |||
{{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 | |||
== 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 | |||
== 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 | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
== == | |||
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}} | |||
# Igaz | |||
# Hamis | |||
---- | ---- | ||
{{Vissza|Szoftvertechnológia}} | {{Vissza|Szoftvertechnológia}} | ||