A szoftver az elkészült forráskódot jelenti.
A szoftvertermék tartalmazza a felhasználói adatokat.
A szoftver megjelenhet koncepciók, ügyletek vagy eljárások alakjában.
Egy példa a szoftverre a számítógépprogram.
A szoftver magában foglalja a működéséhez szükséges eljárásokat, szabályokat.
A szoftvernek alkalmazkodnia kell a mindig változó hardver követelményekhez.
A minőség még egyazon termék esetében sem állandó.
A szoftvernek nincs a hagyományos módon mérhető, fizikai léte
A szoftver minősége függ a minőséget értékelő személyétől
A szoftver minősége nem függ a szoftver típusától.
Az evolúciós fejlesztés (rapid prototyping) egyik előnye, hogy a felhasználói visszajelzések viszonylag korán megjelennek a fejlesztési folyamatban.
A „tesztvezérelt fejlesztés” során minden funkcióra már az implementálása előtt elkészülnek a tesztesetek.
Általában a szoftverfejlesztési életciklusban először a statikus tesztelés, majd a strukturális tesztelés, végül a funkcionális tesztelés technikái jutnak szerephez.
A V-modellben a rendszer validálása a fejlesztési életciklus végére kerül.
Agilisan dolgozó cégnél a CMMI nem alkalmazható.
Agilisan dolgozó cégnél nem kell a becsléseket dokumentálni.
A RUP agilis fejlesztési módszertan.
Agilisan dolgozó cégnél előfordul, hogy naponta akár több build is készül.
A funkciópont számolás kötelező minden CMMI 3-as érettségi szinten levő cégnél.
Egy cégnek választani kell , hogy CMMI modellt , vagy TMMI modellt alkalmaz. A kettő együtt nem alkalmazható.
A CMMI modellben a méréseket méréseket a 2-es érettségi szinten el kell kezdeni.
A CMMI modellben az összes fejlesztési folyamat (Engineering Processes) a 3-as érettségi szinten kötelező.
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.
Agilis fejlesztés esetén a kódminőséget a refaktorálás / refaktorálás (refactoring) tevékenység hivatott növelni.
Az agilis szoftvertervezés szerves része a User Story / felhasználói történet / story point meghatározása
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 az agilis környezetben.
A design (rendszertervezés) során mindig meg kell vizsgálni, hogy milyen architektúra stílusokat, mintákat lehetne alkalmazni.
A GUI tervezése során figyelni kell a felhasználók sokféleségére.
A rendszertervezés során készülő dokumentumokat nem kell verziókövetésnek alávetni.
A jó szoftvertervező többféle alternatívát is megvizsgál egy rendszer tervezése során.
Teszt eset nem írja le egy teszt elvárt eredményét.
Teszt eljárás leírja egy teszt elvárt eredményét.
Tesztelési feltételek nem írják le egy teszt elvárt eredményét.
A szoftvertesztelés a hibák jelenlétét és nem a hibamentességet mutatja meg.
A bemenetek és kimenetek kombinációi kimutatják az összes hibát a szoftverben.
A tesztelés a kulcsfontosságú fejlesztések után kezdődik.
A biztonságkritikus rendszerek tesztelése hasonló a webalkalmazások teszteléséhez.
Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk biztosítani, hogy a tesztelésünk „teljes”.
Az ekvivalencia osztály alapú tesztelés jellemzője, hogy független változókat feltételez.
Az ekvivalencia osztály alapú tesztelés alkalmazásakor ismerjük a program struktúráját.
Az ekvivalencia osztály alapú tesztelés segítségével szeretnénk elkerülni a redundáns adatokkal való tesztelést.
A progressziós tesztek kifejezetten az utolsó változtatásnál módosított/létrehozott részek/funkciók tesztelésére koncentrálnak.
Az „alfa teszt” során a külső felhasználók egy korlátozott csoportja teszteli a rendszert.
A rendszerteszt a funkcionális specifikáción alapul, ezért a nem-funkcionális követelmények vizsgálatára nem tér ki.
Az inspekció a leghatásosabb az összes szemle között viszont költséges és nehéz a bevezetése.
A projekt tervben a kritikus út a 0 időjátékkal rendelkező feladatok sorozata.
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á.
Ha Scrum-ot alkalmazunk, nem lehet kritikus utat számolni.
A projektben a kritikus úton mindig a legköltségesebb tevékenységek foglalnak helyet.
Az egyetlen agilis projekt menedzsment eszköz a Scrum.
A Scrum -ban, szerepük szerint, „Disznók”-nak nevezzük a cég felsővezetését.
A Scrum kifejezetten ellenzi, hogy a csapat kódolási szabványokat használjon.
Az agilis projektekben nem kell időt fordítani arra, hogy megértsük és elemezzük, mi a siker vagy kudarc oka.
A kockázatmenedzsment lényege, hogy az előre nem tervezett események előfordulását megakadályozzuk, és ezáltal hatásukat nullára csökkentsük.
A minőségbiztosítás a szoftverfejlesztésben a jó tesztelést jelenti.
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.
Az ISO 9001 alapú audit a kód minőségét vizsgálja.
A vízesés modell és a V -modell szekvenciális életciklus modellek.
Az iteratív és inkrementális fejlesztések egyik előnye, hogy a felhasználói visszajelzések viszonylag korán megjelennek a fejlesztési folyamatban.
A „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.
Egy osztálynak több egymástól független ősosztálya is lehet.
A nem definiált láthatóságú attribútum publikusnak számít.
A use-case leírás és az adatfolyamábra egyenértékű.
Az asszociáció, a kompozíció, a függőség és a specializáció közül a specializáció a leggyengébb.
Az aktivitás diagramon szereplő úszósávokat a konkurencia leírására használják
Az objektum diagramon szereplő “link”-nek nincs multiplicitása.
Az UML2 szabvány definiálja a RUP (Rational Unified Process) fejlesztési módszertant is.
A kommunikációs diagramon az üzenetek sorrendjét számozással lehet megadni.
A polimorfizmus alkalmazásával általában csökken a relációban szereplő osztályok metódusainak száma
A polimorfizmus alkalmazásával általában csökken a leszármazott osztályok közötti csatolás (coupling)
A polimorfizmus alkalmazásával általában csökken az alternatívák (case és if szerkezetek) száma.
A polimorfizmus alkalmazásával általában csökken a leszármazott osztályokon belüli kohézió (cohesion)
