Studied by 11 peopleh
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.
h
A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma.
h
Egy projekt lehet agilis, ha azért, hogy a csapattagok koncentrálni tudjanak szakmai feladataikra, csak maximum havi 1 projektmegbeszélést tartanak.
h
A folyamatos rendelkezésre állás minden szoftver esetében alapkövetelmény.
i
A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.
h
Az ekvivalencia osztály alapú tesztelés a kód belső szerkezetén alapul.
i
Subversion-ben update-kor változhat a munkapéldány.
i
A GUI tervezése során figyelni kell a felhasználók sokféleségére.
i
Egy projekt lehet agilis, ha naponta tartanak rövid megbeszélést a projekt előrehaladásáról.
i
A projektirányítási folyamatok egyik mérőszáma lehet a projekt tervezéssel eltöltött idő.
i
A tesztelés egyik módszere a TDD (Test Driven Development, tesztvezérelt fejlesztés) agilis szoftverfejlesztés esetén.
i
A CMMI modellben a sajátos célok (Specific Goals) és általános célok (Generic Goals) kötelező elemek.
i
A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.
i
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.
h
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á.
i
A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.
h
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.
h
A projekt tervben nem kell megemlíteni a tesztelési tevékenységeket, mert ezeket a teszt tervezők fogják leírni.
h
A rövid válaszidő minden szoftver esetében alapkövetelmény.
h
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.
h
A CMM előírja, hogy az orchestration elvén szervezzék a technológiai folyamatokat.
i
Egy projekt lehet agilis, ha a projektben érdekelt felek vagy „Disznók", vagy „Csirkék".
h
A konfigurációkezelésre nem kell időt tervezni a projektben.
i
Az útvonal alapú tesztelés a kód belső szerkezetén alapul.
h
Késedelmes sprint esetén a csapatot új emberekkel bővítik.
i
A vízesés modell és a V-modell szekvenciális életciklus modellek.
h
A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.
h
A teszteléshez szükséges erőforrások meghatározása az alapvető tesztelési folyamat „Végrehajtás" fázisába tartozik.
i
Integrációs teszt megjelenik explicit módon a V-modellben.
h
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.
i
Az inspekció a leghatásosabb az összes szemle között, viszont költséges és nehéz a bevezetése.
i
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.
h
A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.
h
A tapasztalatok elemzése az elkövetkező projektek számára az alapvető tesztelési folyamat „Végrehajtás" fázisába tartozik.
i
A követelményeket össze kell tudni rendelni a design elemekkel, a kóddal és a tesztesetekkel is.
h
A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.
i
A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
i
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.
h
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.
i
Egy projekt lehet agilis, ha előfordul, hogy a teszt eseteket hamarabb írják meg, mint a kódot.
h
Béta-teszt megjelenik explicit módon a V-modellben.
i
A Definition of Done az agilis projekttervezés és/vagy projektkövetés eszköze.
i
Az ekvivalencia osztály alapú tesztelési technika követelményspecifikáción alapul.
h
A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.
h
A határérték analízis a kód belső szerkezetén alapul.
h
A kódminőséget a V-modellben a refaktorálás (refactoring) tevékenység hivatott növelni.
i
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.
h
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)
i
A „megvalósult érték számítás" segít előrejelezni, hogy mi várható a projekt következő szakaszaiban.
h
A CMMI folytonos reprezentációja (continuous representation) megfelel a szoftver CMM-nek.
i
A válaszidőre vonatkozó követelményt nem-funkcionális követelményként szoktuk kezelni.
i
A csapat sebessége (Team velocity) az agilis projekttervezés és/vagy projektkövetés eszköze.
i
A szoftvertermék tartalmazza a felhasználói adatokat.
i
Egy projekt lehet agilis, ha a projekt előrehaladását a Kanban Board-ról készült fotókkal dokumentálják.
h
A tesztelés során készülő dokumentumokat nem kell verziókövetésnek alávetni.
i
A CMMI (Capability Maturity Model Integration) modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
h
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.
i
A fehér-doboz tesztelés a kód belső szerkezetén alapul.
i
A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni. (UML2)
h
A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion).
h
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.
i
A "sprint review" eredménye a product backlog új változata.
h
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.
i
A rövid válaszidő nem minden szoftver esetében alapkövetelmény.
h
A CMM egy szervezet által készített összes szoftver minőségét értékeli.
i
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.
h
A szoftver implementálása pontosan a kódolást jelenti.
h
A teszteljárások fejlesztése az alapvető tesztelési folyamat „Végrehajtás" fázisába tartozik.
h
Subversion-ben update-kor változhat a repository.
i
A projektet indító szervezet Lean filozófiát alkalmaz.
i
Egy projekt lehet agilis, ha a kódminőséget a refaktorálás (refactoring) tevékenység hivatott növelni.
i
A Burndown Chart az agilis projekttervezés és/vagy agilis projektkövetés eszköze.
i
A CMMI folytonos reprezentációja (continuous representation) a képességi szinteken (capability levels) alapul.
h
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.
h
A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling).
h
Agilis környezetben minden projektben szigorúan követik a V-modell előírásait az életciklusra vonatkozóan.
h
A sprintben csak kódolás és tesztelés történik. A tervezésre a "sprint planning" során kerül sor.
h
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.
h
A szoftvertermék nem tartalmazza a felhasználói adatokat, mert azokat a felhasználók gyakran megváltoztatják.
h
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.
h
A nem definiált láthatóságú attribútum publikusnak számít. (UML2)
i
Az objektum diagramon szereplő "link"-nek nincs multiplicitása. (UML2)
i
A konfigurációkezelésre időt kell tervezni a projektben.
h
A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.
i
Unit teszt megjelenik explicit módon a V-modellben.
i
A projektvezetői szerepkört a „Scrum master" látja el.
i
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.
h
Agilis környezetben a készülő kód méretét nem lehet becsülni.
i
Az ISO 9001 alapú audit a szoftverfejlesztő cég folyamatait vizsgálja.
i
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.
h
A DD-path tesztelési technika követelményspecifikáción alapul.
h
A fehér-doboz tesztelési technika követelményspecifikáción alapul.
i
A határérték analízis tesztelési technika követelményspecifikáción alapul.
i
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.
h
A napi scrum meeting zártkörű, csak a csapat és a scrum master vehet rajta részt.
i
Garvin 5-féle definíciót adott a szoftverminőségre.
i
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.
i
A scrum master legfőbb feladata a csapat előtt álló nehézségek, problémák elhárítása.
i
A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
i
A tesztelés során készülő dokumentumokat verziókövetésnek kell alávetni.
Note
Flashcard