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