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

A VIK Wikiből
Csia Klaudia Kitti (vitalap | szerkesztései)
a Új kérdések hozzáadása.
a Elgépelések javítása
 
(8 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva)
3. sor: 3. sor:
''Kikérdező a tárgyhonlapon lévő igaz/hamis kérdésekhez + Wikin fenn található vizsgákból.''  
''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 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.==
== A "Ez jó szoftver?" kérdés a validációhoz kapcsolódik. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.==
== A "Jó ez a szoftver?" kérdés a verifikációhoz kapcsolódik. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 Burndown Chart az agilis projekttervezés és/vagy agilis 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=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ekvivalencia osztály alapú tesztelés a kód belső szerkezetén alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Subversion-ben update-kor változhat a munkapéldá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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A GUI tervezése során figyelni kell a felhasználók sokféleségére.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.==
== 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
# Igaz
# Hamis
# Hamis


== A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek. ==
{{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 projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A rövid válaszidő minden szoftver esetében alapkövetelmény.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha  a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.==
== 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=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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az útvonal alapú tesztelés a kód belső szerkezetén alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Késedelmes sprint esetén a csapatot új emberekkel bővítik.==
== A COSMIC agilis szoftverfejlesztési módszertan. ==
{{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 projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.==
== A COSMIC projekttervezési és követési eszköz. ==
{{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 teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
== A Continuous Integration projekttervezési és követési eszköz. ==
{{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


== Integrációs teszt megjelenik explicit módon a V-modellben.==
== A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 DD-path tesztelési technika követelményspecifikáción alapul. ==
{{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


== Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.==
== 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
 
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 GQM (Goal-Question-Metric) a QIP (Quality Improvement Paradigm) egyik eszköze. ==
{{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.==
{{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


== A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.==
== A GQM paradigma az emberi erőforrások mérésére nem alkalmazható. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== 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. ==
== A GQM paradigma tesztelési folyamatok 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 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 GUI tervezése során figyelni kell a felhasználók sokféleségére. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha előfordul, hogy a teszt eseteket hamarabb írják meg, mint a kódot.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Béta-teszt megjelenik explicit módon a V-modellben.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.==
== A PRINCE a RUP továbbfejlesztett változata. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ekvivalencia osztály alapú tesztelési technika követelményspecifikáción alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A határérték analízis a kód belső szerkezetén alapul.==
== A RUP agilis szoftverfejlesztési életciklus modell. ==
{{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 kódminőséget a V-modellben a refaktorálás (refactoring) tevékenység hivatott növelni.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.==
== A RUP nem agilis fejlesztési módszertan. ==
{{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


== A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.==
== A RUP nem tartalmaz projektirányítási eljárásokat. ==
{{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 válaszidőre vonatkozó követelményt nem-funkcionális követelményként szoktuk kezelni.==
== A RUP szekvenciális szoftverfejlesztési módszertan. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftvertermék tartalmazza a felhasználói adatokat.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztelés során készülő dokumentumokat nem kell verziókövetésnek alávetni.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# 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 Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon. ==
{{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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 Scrum szekvenciális szoftverfejlesztési életciklus modell. ==
{{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 tesztelés a kód belső szerkezetén alapul.==
== A Scrum szerint a cég vezetői „Csirkék”. ==
{{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


== A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).==
== A TSP projekttervezési és követési eszköz. ==
{{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 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 TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A “sprint review” eredménye a product backlog új változata.==
== A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik. ==
{{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 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 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A rövid válaszidő nem minden szoftver esetében alapkövetelmény.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMM egy szervezet által készített összes szoftver minőségét értékeli.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver implementálása pontosan a kódolást jelenti.==
== A V-modellben megjelenik a dinamikus teszt. ==
{{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 teszteljárások fejlesztése 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Subversion-ben update-kor változhat a repository.==
== A V-modellben megjelenik a stressz teszt. ==
{{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


== Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.==
== A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.==
== A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).==
== A csapat sebessége projekttervezési és követési eszköz. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 dinamikus teszt explicit módon megjelenik a CMMI 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
# Hamis
# Hamis


== A szoftvertermék nem tartalmazza a felhasználói adatokat, mert azokat a felhasználók gyakran megváltoztatják.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 döntési tábla alapú tesztelési technika követelményspecifikáción alapul. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A nem definiált láthatóságú attribútum publikusnak számít. (UML2)==
== 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
# Hamis
# Hamis


== Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A konfigurációkezelésre időt kell tervezni a projektben.==
== A fehér-doboz tesztelési technika követelményspecifikáción alapul. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.==
== A fehérdoboz tesztelés alapja az UML diagramok. ==
{{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


== Unit teszt megjelenik explicit módon a V-modellben.==
== A felülvizsgálat, átvizsgálás, review, audit dinamikus verifikációs technikák. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis környezetben a készülő kód méretét nem lehet becsülni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A DD-path tesztelési technika követelményspecifikáción alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A fehér-doboz tesztelési technika követelményspecifikáción alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A határérték analízis tesztelési technika követelményspecifikáción alapul.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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


== A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Garvin 5-féle definíciót adott a szoftverminőségre.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.==
== 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=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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.==
== A konfigurációkezelésre időt kell tervezni a projektben. ==
{{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


== A követelménymenedzsment egyik feladata a követelmények változásának követése.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver implementálása nem csak a kódolást jelenti.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektben időt kell tervezni a mérések és elemzések végzésére is.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A COSMIC agilis szoftverfejlesztési módszertan.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A kódot össze kell tudni rendelni a követelményekkel, a design elemekkel és a tesztesetekkel is.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.==
== 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
# Hamis
# Hamis


== A use-case leírás és az adatfolyamábra egyenértékű. (UML2)==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis környezetben a készülő kód méretét nem lehet mérni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== A posztkondíciók biztosítása a hívott metódus feladata. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== 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.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.==
== A progressziós teszt explicit módon megjelenik a CMMI 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
# Hamis
# Hamis


== A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az egyetlen agilis projekt menedzsment eszköz a Scrum.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztelés a kulcsfontosságú fejlesztések után kezdődik.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Döntési tábla alapú teszt megjelenik explicit módon a V-modellben.==
== 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=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.==
{{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


== Az ISO 9001 alapú audit a kód minőségét vizsgálja.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver az elkészült forráskódot jelenti.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)==
== A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”. ==
{{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


== A scrum csapatban – naponta többször cserélődő – párokban programoznak.==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy projekt lehet agilis, ha  előfordul, hogy naponta akár több build is készül.==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során. ==
== 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=-}}
{{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). ==
== 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=-}}
{{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. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Sprint közben folytonosan követik a felhasználó igényeinek változását. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike. ==
== A rendszerteszt a specifikáció ellenőrzésére irányul. ==
{{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. ==
== A rövid válaszidő minden szoftver esetében alapkövetelmény. ==
{{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 rövid válaszidő nem minden szoftver esetében alapkövetelmény. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A fehér doboz teszt megjelenik explicit módon a V-modellben. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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.==
== A sikeres teszteseteket nem szükséges dokumentálni, ha agilisan dolgozunk. ==
{{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


== 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. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Minden primitív típusnak van csomagoló (wrapper) osztálya. ==
== 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=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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Statikus metódus nem dobhat kivételt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha egy szál véget ért, akkor start() metódushívással újraindítható. ==
== A strukturális teszt explicit módon megjelenik a CMMI 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
# Hamis
# Hamis


== Egy metódust el lehet látni egyszerre abstract és final módosítóval is. ==
== 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=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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter. ==
== A szoftver az elkészült forráskódot jelenti. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy változó dinamikus típusa nem lehet absztrakt osztály. ==
== A szoftver implementálása nem csak a kódolást jelenti. ==
{{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 objektum notifyAll() metódusának meghívásakor a végrehajtó szál kilép az objektum monitorából. ==
== A szoftver implementálása pontosan a kódolást jelenti. ==
{{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


== Két interfész csak akkor valósítható meg egy osztályban, ha az interfészeknek nincsen közös metódusa. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy objektum wait() metódusának meghívásakor a végrehajtó szálnak nem kell az objektum monitorában tartózkodnia. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk. ==
== A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában. ==
{{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


== A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Catch blokkjában lehet újonnan létrehozott kivételt dobni. ==
== 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 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Statikus metódus nem dobhat kivételt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Abstract osztálynak lehet final metódusa. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Final metódusban használható a this változó. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Generikus osztály példányosításakor lehet másik generikus osztály a paraméter. ==
== A szoftverspecifikálást a követelmény előzi meg. ==
{{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 egy szál véget ért, akkor start() metódushívással újraindítható. ==
== A szoftverspecifikálást a tervezés követi. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Konstruktornak nem lehet láthatósága. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Private tag nem szerializálódik. ==
== A szoftvertermék tartalmazza a felhasználói adatokat. ==
{{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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Lehet olyan private tag, aminek többször is lehet értéket adni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Privát metódust csak privát metódusból lehet hívni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Statikus metódusban használható a this változó. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Final metódus nem módosíthatja az attribútumok értékét. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Synchronized módosítójú metódusban nem lehet wait() metódust hívni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== A tervezést az implementáció követi. ==
{{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


== Primitív típus tömbje is a primitív típusok közé számít. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A relációban szereplő osztályok metódusainak száma. ==
== A tesztelés a kulcsfontosságú fejlesztések után kezdődik. ==
{{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 leszármazott osztályok közötti csatolás (coupling). ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az alternatívák (case és if szerkezetek) száma. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A leszármazott osztályokon belüli kohézió (cohesion). ==
== A tesztelés pontosan a hibakeresést és hibajavítást jelenti. ==
{{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 sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A scrum csapatban – naponta többször cserélődő – párokban programoznak. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Sprint közben folytonosan követik a felhasználó igényeinek változását. ==
== A tesztelés statikus verifikációs technika. ==
{{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 sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Késedelemes sprint esetén a csapatot új emberekkel bővítik. ==
== 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 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása. ==
== A teszteseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt. ==
== A tulajdonos jó szerepkör típus szoftver átvizsgálásakor. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A “sprint review” eredménye a product backlog új változata. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy interfészben csak operációk deklarálhatóak, attribútumok nem. ==
== A use-case diagramon nem szerepelhet függőség (dependency). ==
{{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
1 057. sor: 1 045. sor:
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
1 067. sor: 1 055. sor:
# Hamis
# Hamis


== Az aktor és a use-case is classifier (osztályszerű). ==
== A validáció explicit módon megjelenik a CMMI modellben. ==
{{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


== A use-case diagramon nem szerepelhet függőség (dependency). ==
== A validálás a követelmények ellenőrzésére irányul. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett. ==
== A verifikáció explicit módon megjelenik a CMMI modellben. ==
{{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


== Kommunikációs diagramon nem ábrázolható a párhuzamosság. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A prekondíciók biztosítása a hívott metódus feladata. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A posztkondíciók biztosítása a hívott metódus feladata. ==
== A vízesés modell és a V-modell iteratív életciklus modellek. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival. ==
== A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== A “sprint review” eredménye a product backlog új változata. ==
{{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


== A vízesés modell és a V-modell szekvenciális életciklus modellek. ==
== A “tesztelési terv” pontosan a tesztesetek leírását jelenti. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver tartalmazza a felhasználói adatokat. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában. ==
== 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


== 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver az elkészült forráskódot jelenti. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat. ==
== A „féregírtó paradoxon” 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


== A CMMI (Capabilitiy Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Hamis
 
== Abstract osztálynak lehet final metódusa. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy cégnek választani kell , hogy CMMI modellt , vagy TMMI (Test Maturity Model Integration) modellt alkalmaz. A kettő együtt nem alkalmazható. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A CMMI modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező. ==
== 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
# Hamis
# Hamis


== Agilisan dolgozó cégnél a CMMI nem alkalmazható. ==
== 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
# Hamis
# Hamis


== Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni. ==
== 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
# Hamis
# 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. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye) ==
== Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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) ==
== Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye) ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye) ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A válaszidőnek mindig 2 sec alatt kell lennie. (Webes alkalmazás nemfunkcionális követelménye.) ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. (Webes alkalmazás nemfunkcionális követelménye) ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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) ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A rendszernek 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye) ==
== Agilisan dolgozó cégnél a CMMI nem alkalmazható. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Előfordul, hogy naponta akár több build is készül. ==
== Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{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
# Igaz
# Hamis
# Hamis


== A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak. ==
== Az EF (Experience Factory) a QIP (Quality Improvement Paradigm) egyik eszköze. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentáljá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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni. ==
{{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 kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A szoftvertervezés szerves része a User Story / felhasználói történet / story point meghatározása. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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). ==
== 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
 
== Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja. ==
{{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


== A szoftver minőségét pontosan a kód jó minősége jelenti. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A „félig kész munka” a szoftverben a Hét Pazarlás egyike. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A követelmények modellezésének hármas csoportosítása (IREB szerint): adat, viselkedés, funkcionalitás. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát. ==
== Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le. ==
{{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


== Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A moderálás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tanonckodás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
== Az aktor és a use-case is classifier (osztályszerű). ==
{{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


== A tanúsítás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez. ==
== Az egyetlen agilis projekt menedzsment eszköz a Scrum. ==
{{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


== Az ekvivalencia osztály alapú tesztelés alkalmazásakor ismernünk kell a program struktúráját. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A vízesés modell és a V -modell iteratív életciklus modellek. ==
== Az elnök jó szerepkör típus szoftver átvizsgálásakor. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
1 382. sor: 1 380. sor:
# Hamis
# Hamis


== A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike. ==
== Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2) ==
{{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


== A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény. ==
== 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=egy|válasz=2|pontozás=-}}
{{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
# Igaz
# Hamis
# Hamis


== Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A GQM paradigma a kód minőségének mérésére nem alkalmazható. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Egy cég alkalmazhatja együttesen a CMMI modellt és az ISO 9001 szabványt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 9001 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== Béta-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
# Hamis
# Hamis


== Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni. ==
== Catch blokkjában lehet újonnan létrehozott kivételt dobni. ==
{{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


== A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik a stressz teszt. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik a dinamikus teszt. ==
== Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik a peer review. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik a béta teszt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik a regressziós teszt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A V-modellben megjelenik az integrációs teszt. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Burndown Chart tipikus agilis projekttervezési és követési eszköz. ==
== 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
 
== Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa. ==
{{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


== A COSMIC projekttervezési és követési eszköz. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Planning Joker projekttervezési és követési eszköz. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Kanban Boardról készült fotók egy projekttervezési és követési eszköz. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A csapat sebessége projekttervezési és követési eszköz. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A TSP projekttervezési és követési eszköz. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Continous Integration projekttervezési és követési eszköz. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A DoD (Definition of Done) projekttervezési és követési eszköz. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Garvin ötféle szoftverminőségi definíciója között van termék alapú és folyamat alapú definíció is. ==
== 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


== Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A strukturális tesztelés esetében a teszt eseteket a követelmények alapján hozzuk létre. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik. ==
== 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
 
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az EF (Experience Factory) a QIP (Quality Improvement Pradigm) egyik eszköze. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni. ==
== Egy változó dinamikus típusa nem lehet absztrakt osztá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


== Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 12207 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha Scrum-ot alkalmazunk,a kód méretét kötelezően IFPUG módszerrel kell mérni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga. ==
== Final metódusban használható a this változó. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A verifikáció explicit módon megjelenik a CMMI modellben. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A dinamikus teszt explicit módon megjelenik a CMMI modellben. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A peer review explicit módon megjelenik a CMMI modellben. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A validáció explicit módon megjelenik a CMMI modellben. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A regressziós teszt explicit módon megjelenik a CMMI modellben. ==
== 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 progressziós teszt explicit módon megjelenik a CMMI modellben. ==
== 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=-}}
{{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
# Igaz
# Hamis
# Hamis


== A struktúrális teszt explicit módon megjelenik a CMMI modellben. ==
== 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
# Hamis
# Hamis


== Az uni teszt explicit módon megjelenik a CMMI modellben. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A GQM (Goal-Question-Metric) a QIP (Quality Improvement Pradigm) egyik eszköze. ==
== Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha CMMI modellt alkalmazunk, a cég érettségi szintjét és a folyamatok képességi szintjét is vizsgálnunk kell. ==
== Ha egy szál véget ért, akkor start() metódushívással újraindítható. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja. ==
== Integrációs 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=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== Kommunikációs diagramon nem ábrázolható a párhuzamosság. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Scrum szerint a cég vezetői „Csirkék”. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak. ==
== Konstruktornak nem lehet láthatósága. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák. ==
== 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


== A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik. ==
== Késedelmes sprint esetén a csapatot új emberekkel bővítik. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztelés RUP módszerrel történik. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektkövetés egyik eszköze a ProjektCsapat sebességének (Team Velocity) mérése. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektvezetői szerepkört a „Scrum master” látja el. ==
== Milyen elemek lehetnek egy adatfolyamábrán, beleértve a (context) diagramot is? ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{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
# Igaz
# Hamis
# Hamis


== Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektet indító szervezet Lean filozófiát alkalmaz. ==
== Primitív típus is lehet generikus osztály template-paramétere. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél. ==
== 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=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A RUP agilis szoftverfejlesztési életciklus modell. ==
== Private tag nem szerializálódik. ==
{{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


== Az ISO 25000 szabványcsalád a szoftverfejlesztési folyamat minőségével foglalkozik. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A jó szoftver esetében a rövid válaszidő és a folyamatos rendelkezésre állás mindig alapkövetelmény. ==
== 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


== Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás. ==
== Statikus metódus nem dobhat kivételt. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Az ISO 12207 szabvány semmilyen életciklus modellt nem ír le. ==
== Statikus metódusban használható a this változó. ==
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni. ==
== Statikus tag nem szerializálódik. ==
{{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


== A szoftver jó minősége pontosan a jó teszteléssel biztosítható. ==
== 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=2|pontozás=-}}
{{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
# Igaz
# Hamis
# Hamis


== Agilis szoftvertervezés szerves része a User Story / felhasználói történet / Story Point meghatározása. ==
== Subversionben update-kor változhat a munkapéldány. ==
{{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


== Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket. ==
== Subversionben update-kor változhat a repository. ==
{{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 tesztelés pontosan a hibakeresést és hibajavítást jelenti. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# 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. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga. ==
== Unit 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=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A tesztelési folyamatokat leíró TMMi modell szerkezete teljesen megegyezik a CMMI modell szerkezetével. ==
== Á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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Határérték tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre. ==
== Ö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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Peer review egy dinamikus tesztelési technika, amelyik a CMMI modellben is megjelenik. ==
== Ö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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni. ==
== Az ekvivalencia particionális fehérdoboz tesztelési technika. ==
{{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 strukturális tesztelés előnye, hogy pontos méréseket tesz lehetővé a teszt lefedettséggel kapcsolatban. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A RUP szekvenciális szoftverfejlesztési módszertan. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A teszt eseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat. ==
== A SPICE modell lépcsős folyamatfejlesztési modell. ==
{{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 SPICE modell 6 képességi szintet határoz meg egy folyamat esetében. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A Scrum szekvenciális szoftverfejlesztési életciklus modell. ==
== 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=-}}
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A „féregírtó paradoxon” a „Hét Pazarlás” egyike. ==
== 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=2|pontozás=-}}
{{kvízkérdés|típus=egy|válasz=1|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis


== A jó szoftver esetében a rövid válaszidő és a megfelelő felhasználói dokumentáció mindig alapkövetelmény. ==
== A feketedoboz tesztelés a függyvényelmélet elemeit használja. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
{{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
 
== 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
 
== 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
 
== 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
 
== 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
 
== 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
 
== Tapasztalt rendszertervezőknek a design (rendszertervezés) során nemkell megvizsgálni, hogy milyen architektúra stílusokat, mintákat lehetnealkalmazni, mert tapasztalataik alapján eleve a legjobbat fogjákválasztani. ==
{{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 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 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 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
 
== 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 útvonal alapú tesztelés fehérdoboz tesztelési technika. ==
{{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 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
 
== 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 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
 
== 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
 
== 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 fehérdoboz tesztelés alapja az UML diagramok. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Hamis
 
== 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 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 SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig. ==
{{kvízkérdés|típus=egy|válasz=1|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 CMMI előírja, hogy a nem-funkcioná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 Scrum szerint egy projekt minden sprintjében naponta kell meetingeket tartani, elsősorban az előrehaladás megfelelő ellenőrzése és a teljesítést esetleg gátló elemek azonnali azonosítása céljából. ==
{{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 „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszt eseteket 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
 
== 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
 
== 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
 
== 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 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 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
 
== 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
 
== 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 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 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
 
== 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
 
== 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 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 RUP egyik fázisai közé tartozik a CEIT, azaz Collaboration-Inception-Transition-Elaboration. ==
{{kvízkérdés|típus=egy|válasz=2|pontozás=-}}
# Igaz
# Hamis
 
== A RUP egyik fázisai közé tartozik a CEIT, azaz Construction-Inception-Transition-Elaboration. ==
{{kvízkérdés|típus=egy|válasz=2|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
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Hamis
 
==  ==
{{kvízkérdés|típus=egy|válasz=|pontozás=-}}
# Igaz
# Igaz
# Hamis
# Hamis
----
----
{{Vissza|Szoftvertechnológia}}
{{Vissza|Szoftvertechnológia}}

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


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


Szoftvertechnológia Igaz/Hamis
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 "Ez jó szoftver?" kérdés a validációhoz kapcsolódik.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

A COSMIC agilis szoftverfejlesztési módszertan.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

A PRINCE a RUP továbbfejlesztett változata.

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

A RUP agilis szoftverfejlesztési életciklus modell.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

A RUP nem agilis fejlesztési módszertan.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

A V-modellben megjelenik a dinamikus teszt.

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

  1. Igaz
  2. Hamis

A V-modellben megjelenik a regressziós teszt.

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

  1. Igaz
  2. Hamis

A V-modellben megjelenik a stressz teszt.

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

Abstract osztálynak lehet final metódusa.

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

Az egyetlen agilis projekt menedzsment eszköz a Scrum.

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. A rövid válaszidőt.
  2. A könnyű tanulhatóságot.
  3. Demeter törvényét az architektúra tervezésekor.
  4. Kohéziót elvét az objektumok meghatározásakor.
  5. A felhasználói sokféleséget.
  6. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

Konstruktornak nem lehet láthatósága.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Terminátor
  2. Procesz
  3. Adatfolyam
  4. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

Private tag nem szerializálódik.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

Statikus metódus nem dobhat kivételt.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

Statikus tag nem szerializálódik.

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis

Subversionben update-kor változhat a repository.

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

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. 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: -.

  1. Igaz
  2. Hamis

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

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

  1. Igaz
  2. Hamis