Szoftvertechnológia - Igaz/Hamis
A lap korábbi változatát látod, amilyen Csia Klaudia Kitti (vitalap | szerkesztései) 2023. január 3., 16:53-kor történt szerkesztése után volt. (Új kérdések hozzáadása.)
Kikérdező a tárgyhonlapon lévő igaz/hamis kérdésekhez + Wikin fenn található vizsgákból.
Tartalomjegyzék
- 1 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra.
- 2 A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.
- 3 Egy projekt lehet agilis, ha azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
- 4 A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.
- 5 A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.
- 6 Az ekvivalencia osztály alapú tesztelés a kód belső szerkezetén alapul.
- 7 Subversion-ben update-kor változhat a munkapéldány.
- 8 A GUI tervezése során figyelni kell a felhasználók sokféleségére.
- 9 Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.
- 10 A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.
- 11 A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.
- 12 A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.
- 13 A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.
- 14 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie.
- 15 A projekt tervben a kritikus úton levő tevékenységek hossza megváltoztatható anélkül, hogy ez a projekt teljes átfutását befolyásolná.
- 16 A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.
- 17 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.
- 18 A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.
- 19 A rövid válaszidő minden szoftver esetében alapkövetelmény.
- 20 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.
- 21 A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.
- 22 Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
- 23 A konfigurációkezelésre nem kell időt tervezni a projektben.
- 24 Az útvonal alapú tesztelés a kód belső szerkezetén alapul.
- 25 Késedelmes sprint esetén a csapatot új emberekkel bővítik.
- 26 A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.
- 27 A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 28 Integrációs teszt megjelenik explicit módon a V-modellben.
- 29 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.
- 30 Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.
- 31 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.
- 32 A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.
- 33 A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 34 A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.
- 35 A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.
- 36 A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
- 37 A szoftvertermék minőségét meg lehet meghatározni; a rövid válaszidő és a folyamatos rendelkezésre állás mindig a jó minőség eleme.
- 38 A CMMI modellben 4-es érettségi szinten az összes, 4-as érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie.
- 39 Egy projekt lehet agilis, ha előfordul, hogy a teszt eseteket hamarabb írják meg, mint a kódot.
- 40 Béta-teszt megjelenik explicit módon a V-modellben.
- 41 A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.
- 42 Az ekvivalencia osztály alapú tesztelési technika követelményspecifikáción alapul.
- 43 A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.
- 44 A határérték analízis a kód belső szerkezetén alapul.
- 45 A kódminőséget a V-modellben a refaktorálás (refactoring) tevékenység hivatott növelni.
- 46 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell.
- 47 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)
- 48 A „megvalósult érték számítás” segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.
- 49 A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.
- 50 A válaszidőre vonatkozó követelményt nem-funkcionális követelményként szoktuk kezelni.
- 51 A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.
- 52 A szoftvertermék tartalmazza a felhasználói adatokat.
- 53 Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
- 54 A tesztelés során készülő dokumentumokat nem kell verziókövetésnek alávetni.
- 55 A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
- 56 A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 2-es érettségi szinten kötelező.
- 57 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni.
- 58 A fehér-doboz tesztelés a kód belső szerkezetén alapul.
- 59 A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)
- 60 A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).
- 61 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.
- 62 A “sprint review” eredménye a product backlog új változata.
- 63 Ha ISO 25000 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- 64 A rövid válaszidő nem minden szoftver esetében alapkövetelmény.
- 65 A CMM egy szervezet által készített összes szoftver minőségét értékeli.
- 66 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.
- 67 A szoftver implementálása pontosan a kódolást jelenti.
- 68 A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 69 Subversion-ben update-kor változhat a repository.
- 70 Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz.
- 71 Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.
- 72 A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.
- 73 A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.
- 74 Agilis projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.
- 75 A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).
- 76 A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.
- 77 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.
- 78 A szoftvertermék nem tartalmazza a felhasználói adatokat, mert azokat a felhasználók gyakran megváltoztatják.
- 79 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.
- 80 A nem definiált láthatóságú attribútum publikusnak számít. (UML2)
- 81 Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)
- 82 A konfigurációkezelésre időt kell tervezni a projektben.
- 83 A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.
- 84 Unit teszt megjelenik explicit módon a V-modellben.
- 85 Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el.
- 86 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.
- 87 Agilis környezetben a készülő kód méretét nem lehet becsülni.
- 88 Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.
- 89 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.
- 90 A DD-path tesztelési technika követelményspecifikáción alapul.
- 91 A fehér-doboz tesztelési technika követelményspecifikáción alapul.
- 92 A határérték analízis tesztelési technika követelményspecifikáción alapul.
- 93 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie.
- 94 A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
- 95 Garvin 5-féle definíciót adott a szoftverminőségre.
- 96 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.
- 97 A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.
- 98 A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
- 99 A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.
- 100 Egy projekt lehet agilis, ha a projektben szigorúan követik a RUP (Rational Unified Process) előírásait az életciklusra vonatkozóan.
- 101 Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.
- 102 A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.
- 103 A követelménymenedzsment egyik feladata a követelmények változásának követése.
- 104 A szoftver implementálása nem csak a kódolást jelenti.
- 105 A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.
- 106 Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni.
- 107 Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni.
- 108 A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.
- 109 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.
- 110 A V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.
- 111 A projektben időt kell tervezni a mérések és elemzések végzésére is.
- 112 Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2)
- 113 A COSMIC agilis szoftverfejlesztési módszertan.
- 114 A tényleges és az elvárt eredmények összehasonlítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 115 A GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.
- 116 A kódot össze kell tudni rendelni a követelményekkel, a design elemekkel és a tesztesetekkel is.
- 117 Az adott helyzetben legmegfelelőbb tesztelési technikák kiválasztása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 118 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.
- 119 A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) informatív elemek.
- 120 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A beszállókártyát ki lehet nyomtatni.
- 121 A teszt összefoglaló jelentésének megírása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 122 A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.
- 123 A use-case leírás és az adatfolyamábra egyenértékű. (UML2)
- 124 Agilis környezetben a készülő kód méretét nem lehet mérni.
- 125 Á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.
- 126 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik.
- 127 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.
- 128 A rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni; az a fontos, hogy a legvégső verzió rendelkezésre álljon.
- 129 Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.
- 130 A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.
- 131 Az egyetlen agilis projekt menedzsment eszköz a Scrum.
- 132 A tesztelés a kulcsfontosságú fejlesztések után kezdődik.
- 133 Döntési tábla alapú teszt megjelenik explicit módon a V-modellben.
- 134 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal.
- 135 Az ISO 9001 alapú audit a kód minőségét vizsgálja.
- 136 Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- 137 A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata.
- 138 A tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 139 Egy projekt lehet agilis, ha a projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
- 140 Ha ISO 9001 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- 141 A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.
- 142 A hibák részletes dokumentálása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 143 A szoftver az elkészült forráskódot jelenti.
- 144 Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)
- 145 A scrum csapatban – naponta többször cserélődő – párokban programoznak.
- 146 Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.
- 147 Egy projekt lehet agilis, ha a szoftvertervezés szerves része a User Story/felhasználói történet/story point meghatározása.
- 148 Egy projekt lehet agilis, ha előfordul, hogy naponta akár több build is készül.
- 149 A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.
- 150 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).
- 151 Ha ISO 12207 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- 152 Sprint közben folytonosan követik a felhasználó igényeinek változását.
- 153 A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.
- 154 A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.
- 155 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.
- 156 A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.
- 157 A fehér doboz teszt megjelenik explicit módon a V-modellben.
- 158 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön.
- 159 A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni.
- 160 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.
- 161 Minden primitív típusnak van csomagoló (wrapper) osztálya.
- 162 Primitív típus is lehet generikus osztály template-paramétere.
- 163 Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa.
- 164 Statikus metódus nem dobhat kivételt.
- 165 Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob.
- 166 Ha egy szál véget ért, akkor start() metódushívással újraindítható.
- 167 Egy metódust el lehet látni egyszerre abstract és final módosítóval is.
- 168 A primitív típusokhoz tartozó csomagoló osztályok (wrapper classes) nem változtathatók (immutable).
- 169 A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter.
- 170 Egy változó dinamikus típusa nem lehet absztrakt osztály.
- 171 Egy objektum notifyAll() metódusának meghívásakor a végrehajtó szál kilép az objektum monitorából.
- 172 Két interfész csak akkor valósítható meg egy osztályban, ha az interfészeknek nincsen közös metódusa.
- 173 Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez.
- 174 Egy objektum wait() metódusának meghívásakor a végrehajtó szálnak nem kell az objektum monitorában tartózkodnia.
- 175 Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk.
- 176 A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni.
- 177 A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk.
- 178 Catch blokkjában lehet újonnan létrehozott kivételt dobni.
- 179 Statikus metódus nem dobhat kivételt.
- 180 Abstract osztálynak lehet final metódusa.
- 181 Final metódusban használható a this változó.
- 182 Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob.
- 183 Generikus osztály példányosításakor lehet másik generikus osztály a paraméter.
- 184 Ha egy szál véget ért, akkor start() metódushívással újraindítható.
- 185 Konstruktornak nem lehet láthatósága.
- 186 Private tag nem szerializálódik.
- 187 Statikus tag nem szerializálódik.
- 188 Lehet olyan private tag, aminek többször is lehet értéket adni.
- 189 Privát metódust csak privát metódusból lehet hívni.
- 190 Statikus metódusban használható a this változó.
- 191 Final metódus nem módosíthatja az attribútumok értékét.
- 192 Synchronized módosítójú metódusban nem lehet wait() metódust hívni.
- 193 Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez.
- 194 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.
- 195 Primitív típus tömbje is a primitív típusok közé számít.
- 196 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.
- 197 A relációban szereplő osztályok metódusainak száma.
- 198 A leszármazott osztályok közötti csatolás (coupling).
- 199 Az alternatívák (case és if szerkezetek) száma.
- 200 A leszármazott osztályokon belüli kohézió (cohesion).
- 201 A sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.
- 202 A scrum csapatban – naponta többször cserélődő – párokban programoznak.
- 203 Sprint közben folytonosan követik a felhasználó igényeinek változását.
- 204 A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.
- 205 Késedelemes sprint esetén a csapatot új emberekkel bővítik.
- 206 A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.
- 207 A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
- 208 A “sprint review” eredménye a product backlog új változata.
- 209 Egy interfészben csak operációk deklarálhatóak, attribútumok nem.
- 210 A use-case diagramon szereplő asszociációnak is van multiplicitása.
- 211 Egy állapotdiagramnak (state chart) csak akkor lehet két vagy több végállapota, ha a modelben párhuzamos régiók vannak.
- 212 A use-case leírásban szerepelhetnek az elő- és utófeltételek is.
- 213 Az aktor és a use-case is classifier (osztályszerű).
- 214 A use-case diagramon nem szerepelhet függőség (dependency).
- 215 A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett.
- 216 Kommunikációs diagramon nem ábrázolható a párhuzamosság.
- 217 A prekondíciók biztosítása a hívott metódus feladata.
- 218 A posztkondíciók biztosítása a hívott metódus feladata.
- 219 Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest.
- 220 Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival.
- 221 Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája.
- 222 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.
- 223 A vízesés modell és a V-modell szekvenciális életciklus modellek.
- 224 A szoftver tartalmazza a felhasználói adatokat.
- 225 A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
- 226 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.
- 227 A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük.
- 228 A szoftver az elkészült forráskódot jelenti.
- 229 A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
- 230 A CMMI (Capabilitiy Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni.
- 231 A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél.
- 232 Egy cégnek választani kell , hogy CMMI modellt , vagy TMMI (Test Maturity Model Integration) modellt alkalmaz. A kettő együtt nem alkalmazható.
- 233 A CMMI modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
- 234 Agilisan dolgozó cégnél a CMMI nem alkalmazható.
- 235 Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni.
- 236 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.
- 237 A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni.
- 238 A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye)
- 239 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)
- 240 A rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye)
- 241 Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye)
- 242 A válaszidőnek mindig 2 sec alatt kell lennie. (Webes alkalmazás nemfunkcionális követelménye.)
- 243 A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell. (Webes alkalmazás nemfunkcionális követelménye)
- 244 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)
- 245 A rendszernek 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye)
- 246 Előfordul, hogy naponta akár több build is készül.
- 247 A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
- 248 A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
- 249 Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
- 250 A projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
- 251 A „szoftvertervezés” (mint műszaki, mérnöki munka) és "projekttervezés" (mint menedzsment feladat) élesen elkülönül egymástól.
- 252 A kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.
- 253 A szoftvertervezés szerves része a User Story / felhasználói történet / story point meghatározása.
- 254 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).
- 255 A szoftver minőségét pontosan a kód jó minősége jelenti.
- 256 A „félig kész munka” a szoftverben a Hét Pazarlás egyike.
- 257 A követelmények modellezésének hármas csoportosítása (IREB szerint): adat, viselkedés, funkcionalitás.
- 258 Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
- 259 Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát.
- 260 Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog.
- 261 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.
- 262 A keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
- 263 A moderálás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
- 264 A tanonckodás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
- 265 A tanúsítás egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
- 266 Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”.
- 267 Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez.
- 268 Az ekvivalencia osztály alapú tesztelés alkalmazásakor ismernünk kell a program struktúráját.
- 269 Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést.
- 270 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.
- 271 A vízesés modell és a V -modell iteratív életciklus modellek.
- 272 Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le.
- 273 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.
- 274 Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás.
- 275 Az iteratív és inkrementális fejlesztések hátránya, hogy a felhasználói visszajelzések későn jelennek meg a fejlesztési folyamatban.
- 276 A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike.
- 277 A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.
- 278 Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- 279 A GQM paradigma a kód minőségének mérésére nem alkalmazható.
- 280 Egy cég alkalmazhatja együttesen a CMMI modellt és az ISO 9001 szabványt.
- 281 Az ISO 9001 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 282 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.
- 283 Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni.
- 284 A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.
- 285 A V-modellben megjelenik a stressz teszt.
- 286 A V-modellben megjelenik a dinamikus teszt.
- 287 A V-modellben megjelenik a peer review.
- 288 A V-modellben megjelenik a béta teszt.
- 289 A V-modellben megjelenik a regressziós teszt.
- 290 A V-modellben megjelenik az integrációs teszt.
- 291 A Burndown Chart tipikus agilis projekttervezési és követési eszköz.
- 292 A COSMIC projekttervezési és követési eszköz.
- 293 A Planning Joker projekttervezési és követési eszköz.
- 294 A Kanban Boardról készült fotók egy projekttervezési és követési eszköz.
- 295 A csapat sebessége projekttervezési és követési eszköz.
- 296 A TSP projekttervezési és követési eszköz.
- 297 A Continous Integration projekttervezési és követési eszköz.
- 298 A DoD (Definition of Done) projekttervezési és követési eszköz.
- 299 Garvin ötféle szoftverminőségi definíciója között van termék alapú és folyamat alapú definíció is.
- 300 Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik.
- 301 A strukturális tesztelés esetében a teszt eseteket a követelmények alapján hozzuk létre.
- 302 A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik.
- 303 A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik.
- 304 A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike.
- 305 Az EF (Experience Factory) a QIP (Quality Improvement Pradigm) egyik eszköze.
- 306 Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- 307 Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket.
- 308 Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel.
- 309 Az ISO 12207 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 310 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.
- 311 Ha Scrum-ot alkalmazunk,a kód méretét kötelezően IFPUG módszerrel kell mérni.
- 312 A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.
- 313 A verifikáció explicit módon megjelenik a CMMI modellben.
- 314 A dinamikus teszt explicit módon megjelenik a CMMI modellben.
- 315 A peer review explicit módon megjelenik a CMMI modellben.
- 316 A validáció explicit módon megjelenik a CMMI modellben.
- 317 A regressziós teszt explicit módon megjelenik a CMMI modellben.
- 318 A progressziós teszt explicit módon megjelenik a CMMI modellben.
- 319 A struktúrális teszt explicit módon megjelenik a CMMI modellben.
- 320 Az uni teszt explicit módon megjelenik a CMMI modellben.
- 321 A GQM (Goal-Question-Metric) a QIP (Quality Improvement Pradigm) egyik eszköze.
- 322 Ha CMMI modellt alkalmazunk, a cég érettségi szintjét és a folyamatok képességi szintjét is vizsgálnunk kell.
- 323 Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni.
- 324 Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie.
- 325 Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 326 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.
- 327 A Scrum szerint a cég vezetői „Csirkék”.
- 328 A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.
- 329 Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak.
- 330 A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák.
- 331 A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik.
- 332 A tesztelés RUP módszerrel történik.
- 333 A projektkövetés egyik eszköze a ProjektCsapat sebességének (Team Velocity) mérése.
- 334 A projektvezetői szerepkört a „Scrum master” látja el.
- 335 Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg.
- 336 A projektet indító szervezet Lean filozófiát alkalmaz.
- 337 Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél.
- 338 A RUP agilis szoftverfejlesztési életciklus modell.
- 339 Az ISO 25000 szabványcsalád a szoftverfejlesztési folyamat minőségével foglalkozik.
- 340 A jó szoftver esetében a rövid válaszidő és a folyamatos rendelkezésre állás mindig alapkövetelmény.
- 341 Az IREB (International Requirements Engineering Board) szerint a követelmények modellezésének hármas csoportosítása: adat, viselkedés, funkcionalitás.
- 342 Az ISO 12207 szabvány semmilyen életciklus modellt nem ír le.
- 343 Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- 344 A szoftver jó minősége pontosan a jó teszteléssel biztosítható.
- 345 A “projekt terv” pontosan a tevékenységek hálódiagramját vagy sávdiagramját jelenti.
- 346 Agilis szoftvertervezés szerves része a User Story / felhasználói történet / Story Point meghatározása.
- 347 Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket.
- 348 A tesztelés pontosan a hibakeresést és hibajavítást jelenti.
- 349 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.
- 350 Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni.
- 351 A projektvezetőnek nem kell követnie a készülő kód méretét, mert ez a fejlesztők dolga.
- 352 A tesztelési folyamatokat leíró TMMi modell szerkezete teljesen megegyezik a CMMI modell szerkezetével.
- 353 Határérték tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre.
- 354 A Peer review egy dinamikus tesztelési technika, amelyik a CMMI modellben is megjelenik.
- 355 Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni.
- 356 A strukturális tesztelés előnye, hogy pontos méréseket tesz lehetővé a teszt lefedettséggel kapcsolatban.
- 357 A RUP szekvenciális szoftverfejlesztési módszertan.
- 358 A teszt eseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat.
- 359 A SPICE modell 6 képességi szintet határoz meg egy folyamat esetében.
- 360 A Scrum szekvenciális szoftverfejlesztési életciklus modell.
- 361 A „féregírtó paradoxon” a „Hét Pazarlás” egyike.
- 362 A jó szoftver esetében a rövid válaszidő és a megfelelő felhasználói dokumentáció mindig alapkövetelmény.
- 363 A szoftvermérnökök nem fogalmazhatnak meg funkcionális követelményeket egy szoftverre vonatkozóan; ez mindig a felhasználók feladata.
- 364 Az ISO 9001 szabvány és a TMMi modell együttesen is alkalmazható egy agilisan működő szoftvercégnél.
- 365 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.
- 366 A szoftver jó minősége pontosan a jó és rendszeres auditokkal biztosítható.
- 367 A “tesztelési terv” pontosan a tesztesetek leírását jelenti.
- 368 Agilis projektben Burn Down Chart-tal lehet a projekt előrehaladását követni.
- 369 Agilis projektekben a tesztelést nem kell megtervezni, mert a tesztelők tapasztalat alapján gyorsabban le tudják futtatni a teszteket.
- 370 Nem megengedhető a CMMI modell szerint, hogy a projekt előrehaladását Kanban Boardról készített fotókkal dokumentálják.
- 371 A sikeres teszt eseteket nem szükséges dokumentálni, ha agilisan dolgozunk.
- 372 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.
- 373 Ha Scrum-ot alkalmazunk, a kód méretét nem lehet COSMIC módszerrel mérni.
- 374 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ő.
- 375 Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel kell mérni.
- 376 A PRINCE a RUP továbbfejlesztett változata.
- 377 A GQM paradigma tesztelési folyamatok mérésére nem alkalmazható.
- 378 Strukturális tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre.
- 379 A Peer Review statikus tesztelési technika.
- 380 A rendszertervezés során alapvetően a rendszer statikus és dinamikus nézetét írjuk le.
- 381 Egy projekt hálódiagramjában a kritikus úton azok a tevékenységek helyezkednek el, amelyeknek teljes időjátéka nem 0.
- 382 Konfigurációs elemeket nemcsak a kódra, hanem a szoftverfejlesztési projekt során készülő összes munkatermékre azonosítani kell.
- 383 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ő.
- 384 Agilis projektben a követelményeket a kódban nem kell tudni beazonosítani, mert a követelmények gyakran változnak.
- 385 Tapasztalt rendszertervezőknek a design (rendszertervezés) során nemkell megvizsgálni, hogy milyen architektúra stílusokat, mintákat lehetnealkalmazni, mert tapasztalataik alapján eleve a legjobbat fogjákválasztani.
- 386 A RUP nem agilis fejlesztési módszertan.
- 387 A Követelménymenedzsment (REQM) folyamat a CMMI modell 4-esérettségi szintjén (ML4) jelenik meg.
- 388 A projekt tervében a kritikus úton azok a tevékenységek foglalnak helyet, amelyeknek teljes időjátéka nem egyenlő 0-val.
- 389 A projekt olyan tevékenységsorozat, amely nem korlátos (többek között) a minőségre vonatkozóan.
- 390 Az Extreme Programming szerinti életciklusban a User Story központi helyen van.
- 391 Az útvonal alapú tesztelés fehérdoboz tesztelési technika.
- 392 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á.
- 393 Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni.
- 394 A szoftver tesztelése nem csak a kód futtatását jelenti.
- 395 Agilis fejlesztés esetében semmit sem kell dokumentálni, lényeg, hogy a kód legyen minél előbb kész.
- 396 A Projekt tervezés (PPL) folyamat a CMMI modell 3-as érettségi szintjén jelenik meg.
- 397 A fehérdoboz tesztelés alapja az UML diagramok.
- 398 A RUP nem tartalmaz projektirányítási eljárásokat.
- 399 A projekt olyan tevékenységsorozat, amely korlátos (többek között) a készülő szoftver válaszidejére vonatkozóan.
- 400 A projekt olyan tevékenységsorozat, amely korlátos (többek között) a minőségre vonatkozóan.
- 401 A SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig.
- 402 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.
- 403 A CMMI előírja, hogy a nem-funkcionális követelményeket egy szoftverre vonatkozóan az ISO 9126 / ISO 25000 szabvány szerint kell meghatározni.
- 404 A Scrum szerint egy projekt minden sprintjében naponta kell meetingeket tartani, elsősorban az előrehaladás megfelelő ellenőrzése és a teljesítést esetleg gátló elemek azonnali azonosítása céljából.
- 405 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.
- 406 A „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszt eseteket rendszeresen felül kell vizsgálni és módosítani kell.
- 407 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.
- 408 A dinamikus tesztelés alapulhat követelményspecifikáción és a kód belső szerkezetén is.
- 409 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.
- 410 A tesztelés pontosan a tesztek futtatását jelenti, de nem azonos a hibakereséssel.
- 411 A strukturális tesztelés nem feltételezi a kód futtatását.
- 412 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.
- 413 Az, hogy a szabványos folyamatokat dokumentáltak, a CMMI modellben legkorábban a 3-as érettségi szintre jellemző.
- 414 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.
- 415 A megbízhatósági követelmények nemfunkcionális követelmények.
- 416 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.
- 417 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.
- 418 A V-modell a vízesés-modellből kialakított iteratív modell.
- 419 A CMMI előírja, hogy a termék méréséhez a GQM paradigmát kell használni.
- 420
- 421
- 422
- 423
- 424
- 425
- 426
- 427
- 428
- 429
- 430
- 431
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: Egyszerre maximum 5 repülőjegyet lehet foglalni ugyanarra a járatra.
- Igaz
- Hamis
A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.
- Igaz
- Hamis
Egy projekt lehet agilis, ha azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
- Igaz
- Hamis
A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.
- Igaz
- Hamis
A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.
- Igaz
- Hamis
Az ekvivalencia osztály alapú tesztelés a kód belső szerkezetén alapul.
- Igaz
- Hamis
Subversion-ben update-kor változhat a munkapéldány.
- Igaz
- Hamis
A GUI tervezése során figyelni kell a felhasználók sokféleségére.
- Igaz
- Hamis
Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.
- 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 tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.
- 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 design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek maximum 1000 felhasználót kell egyszerre kezelnie.
- Igaz
- Hamis
A projekt tervben a kritikus úton levő tevékenységek hossza megváltoztatható anélkül, hogy ez a projekt teljes átfutását befolyásolná.
- Igaz
- Hamis
A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.
- 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 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 rövid válaszidő minden szoftver esetében alapkövetelmény.
- 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
A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.
- Igaz
- Hamis
Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
- Igaz
- Hamis
A konfigurációkezelésre nem kell időt tervezni a projektben.
- Igaz
- Hamis
Az útvonal alapú tesztelés a kód belső szerkezetén alapul.
- Igaz
- Hamis
Késedelmes sprint esetén a csapatot új emberekkel bővítik.
- Igaz
- Hamis
A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.
- 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
Integrációs teszt megjelenik explicit módon a V-modellben.
- 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
Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.
- 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
A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.
- 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 követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.
- Igaz
- Hamis
A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.
- Igaz
- Hamis
A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
- Igaz
- Hamis
A szoftvertermék minőségét meg lehet meghatározni; a rövid válaszidő és a folyamatos rendelkezésre állás mindig a jó minőség eleme.
- Igaz
- Hamis
A CMMI modellben 4-es érettségi szinten az összes, 4-as érettségi szinten kötelező folyamatnak legalább 4-es képességi szintűnek kell lennie.
- Igaz
- Hamis
Egy projekt lehet agilis, ha előfordul, hogy a teszt eseteket hamarabb írják meg, mint a kódot.
- Igaz
- Hamis
Béta-teszt megjelenik explicit módon a V-modellben.
- Igaz
- Hamis
A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.
- Igaz
- Hamis
Az ekvivalencia osztály alapú tesztelési technika követelményspecifikáción alapul.
- Igaz
- Hamis
A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.
- Igaz
- Hamis
A határérték analízis a kód belső szerkezetén alapul.
- Igaz
- Hamis
A kódminőséget a V-modellben a refaktorálás (refactoring) tevékenység hivatott növelni.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek PC-n, tableten és Androidot használó okostelefonon is működnie kell.
- 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
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 CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.
- Igaz
- Hamis
A válaszidőre vonatkozó követelményt nem-funkcionális követelményként szoktuk kezelni.
- Igaz
- Hamis
A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.
- Igaz
- Hamis
A szoftvertermék tartalmazza a felhasználói adatokat.
- Igaz
- Hamis
Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
- Igaz
- Hamis
A tesztelés során készülő dokumentumokat nem kell verziókövetésnek alávetni.
- 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 (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 2-es érettségi szinten kötelező.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet Mastercard vagy Visa bankkártyával ki lehet fizetni.
- Igaz
- Hamis
A fehér-doboz tesztelés a kód belső szerkezetén alapul.
- Igaz
- Hamis
A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)
- Igaz
- Hamis
A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).
- 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 “sprint review” eredménye a product backlog új változata.
- Igaz
- Hamis
Ha ISO 25000 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- Igaz
- Hamis
A rövid válaszidő nem minden szoftver esetében alapkövetelmény.
- Igaz
- Hamis
A CMM egy szervezet által készített összes szoftver minőségét értékeli.
- 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
A szoftver implementálása pontosan a kódolást jelenti.
- Igaz
- Hamis
A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- Igaz
- Hamis
Subversion-ben update-kor változhat a repository.
- Igaz
- Hamis
Agilis munkavégzésben a projektet indító szervezet Lean filozófiát alkalmaz.
- 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
A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.
- Igaz
- Hamis
A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.
- Igaz
- Hamis
Agilis projektben a tesztelők külön csoportban dolgoznak, munkájuk teljesen elkülönül a programozókétól, az objektivitás megőrzése céljából.
- 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 sprintben csak kódolás és tesztelés történik. A tervezésre a “sprint planning” során kerül sor.
- 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
A szoftvertermék nem tartalmazza a felhasználói adatokat, mert azokat a felhasználók gyakran megváltoztatjá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
A nem definiált láthatóságú attribútum publikusnak számít. (UML2)
- Igaz
- Hamis
Az objektum diagramon szereplő “link”-nek nincs multiplicitása. (UML2)
- Igaz
- Hamis
A konfigurációkezelésre időt kell tervezni a projektben.
- Igaz
- Hamis
A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.
- Igaz
- Hamis
Unit teszt megjelenik explicit módon a V-modellben.
- Igaz
- Hamis
Agilis munkavégzésben a projektvezetői szerepkört a „Scrum master” látja el.
- 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
Agilis környezetben a készülő kód méretét nem lehet becsülni.
- Igaz
- Hamis
Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.
- 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 DD-path tesztelési technika követelményspecifikáción alapul.
- Igaz
- Hamis
A fehér-doboz tesztelési technika követelményspecifikáción alapul.
- Igaz
- Hamis
A határérték analízis tesztelési technika követelményspecifikáción alapul.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A válaszidőnek mindig 10 sec alatt kell lennie.
- Igaz
- Hamis
A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
- Igaz
- Hamis
Garvin 5-féle definíciót adott a szoftverminőségre.
- 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 scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.
- Igaz
- Hamis
A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
- Igaz
- Hamis
A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.
- 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
Agilis környezetben a készülő kód méretét lehet Cosmic módszerrel becsülni.
- Igaz
- Hamis
A Projekt követés (PMC) folyamat a CMMI modellben a 2-es érettségi szinten (ML2) van.
- Igaz
- Hamis
A követelménymenedzsment egyik feladata a követelmények változásának követése.
- Igaz
- Hamis
A szoftver implementálása nem csak a kódolást jelenti.
- Igaz
- Hamis
A CMM érettségi szint (maturity level) kifejezi a szervezet vezetésének minőségét is.
- Igaz
- Hamis
Ha Scrumot alkalmazunk, nem lehet kritikus utat számolni.
- Igaz
- Hamis
Ha Scrum-ot alkalmazunk, kötelező COSMIC módszerrel funkciópont-számolást végezni.
- Igaz
- Hamis
A döntési tábla alapú tesztelési technika követelményspecifikáción alapul.
- 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 V-modellben a rendszerteszt során a teljes követelményrendszert validáljuk.
- Igaz
- Hamis
A projektben időt kell tervezni a mérések és elemzések végzésére is.
- Igaz
- Hamis
Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják. (UML2)
- Igaz
- Hamis
A COSMIC agilis szoftverfejlesztési módszertan.
- 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 GQM (Goal Question Metric) paradigma az agilis projekttervezés és/vagy projektkövetés eszköze.
- Igaz
- Hamis
A kódot össze kell tudni rendelni a követelményekkel, a design elemekkel és a tesztesetekkel 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 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.
- 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 következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A beszállókártyát ki lehet nyomtatni.
- 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 sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.
- Igaz
- Hamis
A use-case leírás és az adatfolyamábra egyenértékű. (UML2)
- Igaz
- Hamis
Agilis környezetben a készülő kód méretét nem lehet mérni.
- 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
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A lefoglalt repülőjegyet a rendszer 10 percig megőrzi, ezalatt a felhasználónak fizetnie kell. Ha nem fizet, a foglalás megszűnik.
- 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 rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni; az a fontos, hogy a legvégső verzió rendelkezésre álljon.
- Igaz
- Hamis
Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.
- Igaz
- Hamis
A Scrum-ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.
- Igaz
- Hamis
Az egyetlen agilis projekt menedzsment eszköz a Scrum.
- Igaz
- Hamis
A tesztelés a kulcsfontosságú fejlesztések után kezdődik.
- Igaz
- Hamis
Döntési tábla alapú teszt megjelenik explicit módon a V-modellben.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszernek titkosított csatornán kommunikálnia kell a fizetésre elfogadott bankkártyákat kibocsátó bankokkal.
- Igaz
- Hamis
Az ISO 9001 alapú audit a kód minőségét vizsgálja.
- 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
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 tesztesetek kialakítása az alapvető tesztelési folyamat „Végrehajtás” fázisába tartozik.
- 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
Ha ISO 9001 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- Igaz
- Hamis
A CMM egy adott szoftver termék fejlettségét, érettségét vizsgálja.
- 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 szoftver az elkészült forráskódot jelenti.
- Igaz
- Hamis
Egy osztálynak több egymástól független ősosztálya is lehet. (UML2)
- Igaz
- Hamis
A scrum csapatban – naponta többször cserélődő – párokban programoznak.
- Igaz
- Hamis
Egy cég alkalmazhatja együttesen a CMMI modellt és a TMMI (Test Maturity Model Integration) modellt.
- Igaz
- Hamis
Egy projekt lehet agilis, ha a szoftvertervezés szerves része a User Story/felhasználói történet/story point meghatározása.
- Igaz
- Hamis
Egy projekt lehet agilis, ha előfordul, hogy naponta akár több build is készül.
- Igaz
- Hamis
A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.
- 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
Ha ISO 12207 szabványt alkalmazunk, a szoftverfejlesztési projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
- Igaz
- Hamis
Sprint közben folytonosan követik a felhasználó igényeinek változását.
- Igaz
- Hamis
A Continuous Integration az agilis projekttervezés és/vagy projektkövetés eszköze.
- Igaz
- Hamis
A „felesleges funkciók” a szoftverben a Hét Pazarlás egyike.
- 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
A GQM paradigma az emberi erőforrások mérésére nem alkalmazható.
- Igaz
- Hamis
A fehér doboz teszt megjelenik explicit módon a V-modellben.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A rendszer 99%-os rendelkezésre állással működjön.
- Igaz
- Hamis
A következő követelmény lehet egy repülőjegyeket árusító webes alkalmazás nem-funkcionális követelménye: A repülőjegyet bankkártyával ki lehet fizetni.
- 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
Minden primitív típusnak van csomagoló (wrapper) osztálya.
- Igaz
- Hamis
Primitív típus is lehet generikus osztály template-paramétere.
- Igaz
- Hamis
Egy osztály lehet akkor is absztrakt, ha nincs absztrakt metódusa.
- Igaz
- Hamis
Statikus metódus nem dobhat kivételt.
- Igaz
- Hamis
Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob.
- Igaz
- Hamis
Ha egy szál véget ért, akkor start() metódushívással újraindítható.
- Igaz
- Hamis
Egy metódust el lehet látni egyszerre abstract és final módosítóval is.
- Igaz
- Hamis
A primitív típusokhoz tartozó csomagoló osztályok (wrapper classes) nem változtathatók (immutable).
- Igaz
- Hamis
A Java generikus osztályok példányosításakor sosem lehet primitív típus a template-paraméter.
- Igaz
- Hamis
Egy változó dinamikus típusa nem lehet absztrakt osztály.
- 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
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
Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez.
- 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
Ha van két szálunk, akkor a join metódusaikat tetszőleges sorrendben meghívhatjuk.
- Igaz
- Hamis
A szálak képesek saját magukat közvetlenül waiting állapotból notify-jal felébreszteni.
- Igaz
- Hamis
A wait() függvény csak olyan objektumon hívható, amelyre rászinkronizáltunk.
- Igaz
- Hamis
Catch blokkjában lehet újonnan létrehozott kivételt dobni.
- Igaz
- Hamis
Statikus metódus nem dobhat kivételt.
- Igaz
- Hamis
Abstract osztálynak lehet final metódusa.
- Igaz
- Hamis
Final metódusban használható a this változó.
- Igaz
- Hamis
Szerializálás körkörös hivatkozású adatszerkezeten (pl. gyűrű) kivételt dob.
- Igaz
- Hamis
Generikus osztály példányosításakor lehet másik generikus osztály a paraméter.
- Igaz
- Hamis
Ha egy szál véget ért, akkor start() metódushívással újraindítható.
- Igaz
- Hamis
Konstruktornak nem lehet láthatósága.
- Igaz
- Hamis
Private tag nem szerializálódik.
- Igaz
- Hamis
Statikus tag nem szerializálódik.
- Igaz
- Hamis
Lehet olyan private tag, aminek többször is lehet értéket adni.
- Igaz
- Hamis
Privát metódust csak privát metódusból lehet hívni.
- Igaz
- Hamis
Statikus metódusban használható a this változó.
- Igaz
- Hamis
Final metódus nem módosíthatja az attribútumok értékét.
- Igaz
- Hamis
Synchronized módosítójú metódusban nem lehet wait() metódust hívni.
- Igaz
- Hamis
Amikor egy szál véget ér, a szálat reprezentáló objektum bármely metódusának meghívása kivételdobást erdményez.
- 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
Primitív típus tömbje is a primitív típusok közé számít.
- 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
A relációban szereplő osztályok metódusainak száma.
- Igaz
- Hamis
A leszármazott osztályok közötti csatolás (coupling).
- Igaz
- Hamis
Az alternatívák (case és if szerkezetek) száma.
- Igaz
- Hamis
A leszármazott osztályokon belüli kohézió (cohesion).
- 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 scrum csapatban – naponta többször cserélődő – párokban programoznak.
- Igaz
- Hamis
Sprint közben folytonosan követik a felhasználó igényeinek változását.
- Igaz
- Hamis
A sprint addig tart, amíg a sprint backlogban felsorolt célkitűzéseket a csapat el nem éri.
- Igaz
- Hamis
Késedelemes sprint esetén a csapatot új emberekkel bővítik.
- 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 napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
- Igaz
- Hamis
A “sprint review” eredménye a product backlog új változata.
- Igaz
- Hamis
Egy interfészben csak operációk deklarálhatóak, attribútumok nem.
- Igaz
- Hamis
A use-case diagramon szereplő asszociációnak is van multiplicitása.
- 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
A use-case leírásban szerepelhetnek az elő- és utófeltételek is.
- Igaz
- Hamis
Az aktor és a use-case is classifier (osztályszerű).
- Igaz
- Hamis
A use-case diagramon nem szerepelhet függőség (dependency).
- Igaz
- Hamis
A szekvenciadiagramon a neg-gel jelzett dobozban (combined fragment) olyan interakciót írunk le, amely nem megengedett.
- Igaz
- Hamis
Kommunikációs diagramon nem ábrázolható a párhuzamosság.
- Igaz
- Hamis
A prekondíciók biztosítása a hívott metódus feladata.
- Igaz
- Hamis
A posztkondíciók biztosítása a hívott metódus feladata.
- Igaz
- Hamis
Öröklés során a leszármazottakban a prekondíciók gyengülhetnek az őséhez képest.
- Igaz
- Hamis
Öröklés során a leszármazott invariánsai mindig megegyeznek az ős invariánsaival.
- Igaz
- Hamis
Egy osztály refaktorálása során módosulhat a metódusai paraméterlistája.
- Igaz
- Hamis
Az öröklés alkalmazásával általában csökken a forráskódban az alternatívák (case és if szerkezetek) száma.
- Igaz
- Hamis
A vízesés modell és a V-modell szekvenciális életciklus modellek.
- Igaz
- Hamis
A szoftver tartalmazza a felhasználói adatokat.
- Igaz
- Hamis
A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
- 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
A V-modellben a felhasználói követelményeket a rendszerteszt során teszteljük.
- Igaz
- Hamis
A szoftver az elkészült forráskódot jelenti.
- Igaz
- Hamis
A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
- Igaz
- Hamis
A CMMI (Capabilitiy Maturity Model Integration) modellben a méréseket a 2-es érettségi szinten el kell kezdeni.
- Igaz
- Hamis
A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél.
- Igaz
- Hamis
Egy cégnek választani kell , hogy CMMI modellt , vagy TMMI (Test Maturity Model Integration) modellt alkalmaz. A kettő együtt nem alkalmazható.
- Igaz
- Hamis
A CMMI modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
- 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
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
A Scrum előírja, hogy a követelményeket kötelező a projekt elején teljeskörűen dokumentálni.
- Igaz
- Hamis
A bevásárlólistának nyomtathatónak kell lennie.(Webes alkalmazás nemfunkcionális követelménye)
- 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 rendszernek maximum 15000 felhasználót kell egyszerre kezelnie. (Webes alkalmazás nemfunkcionális követelménye)
- Igaz
- Hamis
Más jelszavát csak rendszergazda jogosultságú felhasználó tudja megváltoztatni. (Webes alkalmazás nemfunkcionális követelménye)
- Igaz
- Hamis
A válaszidőnek mindig 2 sec alatt 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 1 órán belül visszaállíthatónak kell lennie. (Webes alkalmazás nemfunkcionális követelménye)
- Igaz
- Hamis
Előfordul, hogy naponta akár több build is készül.
- Igaz
- Hamis
A projektben érdekelt felek vagy „Disznók”, vagy „Csirkék”.
- Igaz
- Hamis
A projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
- Igaz
- Hamis
Azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
- Igaz
- Hamis
A projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
- Igaz
- Hamis
A „szoftvertervezés” (mint műszaki, mérnöki munka) és "projekttervezés" (mint menedzsment feladat) élesen elkülönül egymástól.
- Igaz
- Hamis
A kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.
- Igaz
- Hamis
A szoftvertervezés szerves része a User Story / felhasználói történet / story point meghatározása.
- 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
A szoftver minőségét pontosan a kód jó minősége jelenti.
- Igaz
- Hamis
A „félig kész munka” a szoftverben a Hét Pazarlás egyike.
- Igaz
- Hamis
A követelmények modellezésének hármas csoportosítása (IREB szerint): adat, viselkedés, funkcionalitás.
- Igaz
- Hamis
Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
- Igaz
- Hamis
Egy cég alkalmazhatja együttesen az Automotive SPICE modellt és a GQM paradigmát.
- Igaz
- Hamis
Agilis környezetben a kódot nem kell kommentezni, mert a refaktorálás során úgyis változni fog.
- 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 keresés egy ténylegesen létező egyeztetési technika a követelmények meghatározása során.
- 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 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
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 jellemzője, hogy független változókat feltételez.
- Igaz
- Hamis
Az ekvivalencia osztály alapú tesztelés alkalmazásakor ismernünk kell a program struktúráját.
- 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
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 vízesés modell és a V -modell iteratív életciklus modellek.
- Igaz
- Hamis
Az ISO/IEC 12207 szabvány semmilyen életciklus modellt nem ír le.
- 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
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 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
A „félig kész munka” a szoftverfejlesztésben a Hét Pazarlás egyike.
- Igaz
- Hamis
A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.
- Igaz
- Hamis
Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- Igaz
- Hamis
A GQM paradigma a kód minőségének mérésére nem alkalmazható.
- Igaz
- Hamis
Egy cég alkalmazhatja együttesen a CMMI modellt és az ISO 9001 szabványt.
- Igaz
- Hamis
Az ISO 9001 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 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
Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel lehet becsülni.
- 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 V-modellben megjelenik a stressz teszt.
- Igaz
- Hamis
A V-modellben megjelenik a dinamikus teszt.
- Igaz
- Hamis
A V-modellben megjelenik a peer review.
- Igaz
- Hamis
A V-modellben megjelenik a béta teszt.
- Igaz
- Hamis
A V-modellben megjelenik a regressziós teszt.
- Igaz
- Hamis
A V-modellben megjelenik az integrációs teszt.
- Igaz
- Hamis
A Burndown Chart tipikus agilis projekttervezési és követési eszköz.
- Igaz
- Hamis
A COSMIC projekttervezési és követési eszköz.
- Igaz
- Hamis
A Planning Joker projekttervezési és követési eszköz.
- Igaz
- Hamis
A Kanban Boardról készült fotók egy projekttervezési és követési eszköz.
- Igaz
- Hamis
A csapat sebessége projekttervezési és követési eszköz.
- Igaz
- Hamis
A TSP projekttervezési és követési eszköz.
- Igaz
- Hamis
A Continous Integration projekttervezési és követési eszköz.
- Igaz
- Hamis
A DoD (Definition of Done) projekttervezési és követési eszköz.
- 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
Az ISO 25000 szabványcsalád a szoftvertermék minőségével foglalkozik.
- Igaz
- Hamis
A strukturális tesztelés esetében a teszt eseteket a követelmények alapján hozzuk létre.
- Igaz
- Hamis
A TSP-t alkalmazó csapat minden tagja PSP szerint dolgozik.
- Igaz
- Hamis
A TSP-t alkalmazó csapat minden tagja CMMI szerint dolgozik.
- Igaz
- Hamis
A „feladatok váltogatása” a szoftverfejlesztésben a Hét Pazarlás egyike.
- Igaz
- Hamis
Az EF (Experience Factory) a QIP (Quality Improvement Pradigm) egyik eszköze.
- Igaz
- Hamis
Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- 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
Az ISO 9001 szabvány kiemelten foglalkozik a cégnél végzett mérésekkel és elemzésekkel.
- Igaz
- Hamis
Az ISO 12207 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 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
Ha Scrum-ot alkalmazunk,a kód méretét kötelezően IFPUG módszerrel kell mérni.
- 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 verifikáció explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A dinamikus teszt explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A peer review explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A validáció explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A regressziós teszt explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A progressziós teszt explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A struktúrális teszt explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
Az uni teszt explicit módon megjelenik a CMMI modellben.
- Igaz
- Hamis
A GQM (Goal-Question-Metric) a QIP (Quality Improvement Pradigm) egyik eszköze.
- 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
Agilis projektekben a követelményeket User Story / Story Point formájában szokás dokumentálni.
- Igaz
- Hamis
Az ISO 9001 szabvány előírja, hogy a cégnek regressziós tesztelést kell végeznie.
- Igaz
- Hamis
Az ISO 15504 alapú audit a szoftverfejlesztő cég szoftvertermékeit vizsgálja.
- 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 Scrum szerint a cég vezetői „Csirkék”.
- 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
Folyamatos integráció (Continuous integration) történik, ehhez automatizált eszközkészletet használnak.
- Igaz
- Hamis
A projekt elején a követelmények teljes halmazát nagyon pontosan meghatározzák.
- Igaz
- Hamis
A készítendő rendszer bonyolultságát Planning Poker módszerrel becsülik.
- Igaz
- Hamis
A tesztelés RUP módszerrel történik.
- Igaz
- Hamis
A projektkövetés egyik eszköze a ProjektCsapat sebességének (Team Velocity) mérése.
- Igaz
- Hamis
A projektvezetői szerepkört a „Scrum master” látja el.
- Igaz
- Hamis
Csak kéthetente tartanak projekt megbeszéléseket, hogy a fejlesztők munkáját ne szakítsák meg.
- Igaz
- Hamis
A projektet indító szervezet Lean filozófiát alkalmaz.
- Igaz
- Hamis
Az ISO 9001 szabvány és a CMMI modell együttesen is alkalmazható egy szoftvercégnél.
- Igaz
- Hamis
A RUP agilis szoftverfejlesztési életciklus modell.
- Igaz
- Hamis
Az ISO 25000 szabványcsalád a szoftverfejlesztési folyamat minőségével foglalkozik.
- 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
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 12207 szabvány semmilyen életciklus modellt nem ír le.
- Igaz
- Hamis
Ha SPICE modellt alkalmazunk, nekünk kell kiválasztani, hogy mely folyamatok képességi szintjét szeretnénk fejleszteni.
- Igaz
- Hamis
A szoftver jó minősége pontosan a jó teszteléssel biztosítható.
- Igaz
- Hamis
A “projekt terv” pontosan a tevékenységek hálódiagramját vagy sávdiagramját jelenti.
- Igaz
- Hamis
Agilis szoftvertervezés szerves része a User Story / felhasználói történet / Story Point meghatározása.
- 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
A tesztelés pontosan a hibakeresést és hibajavítást jelenti.
- 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
Ha Scrumot alkalmazunk, a kód méretét kötelezően IFPUG módszerrel kell mérni.
- 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 tesztelési folyamatokat leíró TMMi modell szerkezete teljesen megegyezik a CMMI modell szerkezetével.
- Igaz
- Hamis
Határérték tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre.
- Igaz
- Hamis
A Peer review egy dinamikus tesztelési technika, amelyik a CMMI modellben is megjelenik.
- Igaz
- Hamis
Fehér doboz tesztelési technikát agilis fejlesztés esetében nem lehet alkalmazni.
- 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 RUP szekvenciális szoftverfejlesztési módszertan.
- Igaz
- Hamis
A teszt eseteknek tartalmazniuk kell a teszt végrehajtása során kapott kimenő adatokat.
- Igaz
- Hamis
A SPICE modell 6 képességi szintet határoz meg egy folyamat esetében.
- Igaz
- Hamis
A Scrum szekvenciális szoftverfejlesztési életciklus modell.
- Igaz
- Hamis
A „féregírtó paradoxon” a „Hét Pazarlás” egyike.
- 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 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
Az ISO 9001 szabvány és a TMMi modell együttesen is alkalmazható egy agilisan működő szoftvercégnél.
- 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 szoftver jó minősége pontosan a jó és rendszeres auditokkal biztosítható.
- Igaz
- Hamis
A “tesztelési terv” pontosan a tesztesetek leírását jelenti.
- Igaz
- Hamis
Agilis projektben Burn Down Chart-tal lehet a projekt előrehaladását követni.
- 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
Nem megengedhető a CMMI modell szerint, hogy a projekt előrehaladását Kanban Boardról készített fotókkal dokumentálják.
- Igaz
- Hamis
A sikeres teszt eseteket nem szükséges dokumentálni, ha agilisan dolgozunk.
- 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
Ha Scrum-ot alkalmazunk, a kód méretét nem lehet COSMIC módszerrel mérni.
- 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
Ha Scrum-ot alkalmazunk, a kód méretét COSMIC módszerrel kell mérni.
- Igaz
- Hamis
A PRINCE a RUP továbbfejlesztett változata.
- Igaz
- Hamis
A GQM paradigma tesztelési folyamatok mérésére nem alkalmazható.
- Igaz
- Hamis
Strukturális tesztelés esetében a teszt eseteket a kód belső szerkezete alapján hozzuk létre.
- Igaz
- Hamis
A Peer Review statikus tesztelési technika.
- Igaz
- Hamis
A rendszertervezés során alapvetően a rendszer statikus és dinamikus nézetét írjuk le.
- 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
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
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
Agilis projektben a követelményeket a kódban nem kell tudni beazonosítani, mert a követelmények gyakran változnak.
- Igaz
- Hamis
Tapasztalt rendszertervezőknek a design (rendszertervezés) során nemkell megvizsgálni, hogy milyen architektúra stílusokat, mintákat lehetnealkalmazni, mert tapasztalataik alapján eleve a legjobbat fogjákválasztani.
- Igaz
- Hamis
A RUP nem agilis fejlesztési módszertan.
- Igaz
- Hamis
A Követelménymenedzsment (REQM) folyamat a CMMI modell 4-esérettségi szintjén (ML4) jelenik meg.
- 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 projekt olyan tevékenységsorozat, amely nem korlátos (többek között) a minőségre vonatkozóan.
- Igaz
- Hamis
Az Extreme Programming szerinti életciklusban a User Story központi helyen van.
- Igaz
- Hamis
Az útvonal alapú tesztelés fehérdoboz tesztelési technika.
- 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
Az Extreme Programming szerinti életciklusban a User Story-val nem kell foglalkozni.
- Igaz
- Hamis
A szoftver tesztelése nem csak a kód futtatását jelenti.
- 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
A Projekt tervezés (PPL) folyamat a CMMI modell 3-as érettségi szintjén jelenik meg.
- Igaz
- Hamis
A fehérdoboz tesztelés alapja az UML diagramok.
- Igaz
- Hamis
A RUP nem tartalmaz projektirányítási eljárásokat.
- 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 SPICE modell szoftverfolyamatokra határoz meg képességi szinteket, 0-tól 5-ig.
- 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 CMMI előírja, hogy a nem-funkcionális követelményeket egy szoftverre vonatkozóan az ISO 9126 / ISO 25000 szabvány szerint kell meghatározni.
- Igaz
- Hamis
A Scrum szerint egy projekt minden sprintjében naponta kell meetingeket tartani, elsősorban az előrehaladás megfelelő ellenőrzése és a teljesítést esetleg gátló elemek azonnali azonosítása céljából.
- 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
A „féregirtó paradoxon” egy tesztelési technika, amely szerint a teszt eseteket rendszeresen felül kell vizsgálni és módosítani kell.
- 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 dinamikus tesztelés alapulhat követelményspecifikáción és a kód belső szerkezetén is.
- 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 tesztelés pontosan a tesztek futtatását jelenti, de nem azonos a hibakereséssel.
- Igaz
- Hamis
A strukturális tesztelés nem feltételezi a kód futtatását.
- 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
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 megbízhatósági követelmények nemfunkcionális követelmények.
- 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
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
A V-modell a vízesés-modellből kialakított iteratív modell.
- Igaz
- Hamis
A CMMI előírja, hogy a termék méréséhez a GQM paradigmát kell használni.
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis
- Igaz
- Hamis