szoft

h

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.