https://vik.wiki/index.php?action=history&feed=atom&title=Szoftvertechnol%C3%B3gia%2F2024-vd1-kikerdezo 2026-05-15T15:34:44Z Az oldal laptörténete a wikiben MediaWiki 1.43.8 https://vik.wiki/index.php?title=Szoftvertechnol%C3%B3gia/2024-vd1-kikerdezo&diff=206185&oldid=prev 2024-12-18T15:39:48Z

<p>Új oldal, tartalma: „{{Vissza|Szoftvertechnológia}} {{Kvízoldal | cím= Szoftvertechnológia 2024/25 Első vizsga | pontozás=-}} == Melyik állítás NEM igaz a CoSysMo költségbecslő módszerre? == {{kvízkérdés|típus=egy|válasz=2}} # Az elkészítendő rendszer költségének becsléséhez figyelembe veszi a megvalósítandó interfészek számát # A megoldandó feladat bonyolultságát a kifejlesztendő rendszer becsült forráskód méretével (LoC) jellemezzük # Az…”</p> <p><b>Új lap</b></p><div>{{Vissza|Szoftvertechnológia}}<br /> <br /> {{Kvízoldal | cím= Szoftvertechnológia 2024/25 Első vizsga | pontozás=-}}<br /> <br /> == Melyik állítás NEM igaz a CoSysMo költségbecslő módszerre? ==<br /> {{kvízkérdés|típus=egy|válasz=2}}<br /> # Az elkészítendő rendszer költségének becsléséhez figyelembe veszi a megvalósítandó interfészek számát<br /> # A megoldandó feladat bonyolultságát a kifejlesztendő rendszer becsült forráskód méretével (LoC) jellemezzük<br /> # Az összes többi állítás igaz<br /> # Az elkészítendő rendszer és a projektcsapat jellemzőit is figyelembe veszi a költségtényezők meghatározása során<br /> <br /> <br /> == Melyik állítás igaz a CoCoMo modellre? ==<br /> {{kvízkérdés|típus=egy|válasz=3}}<br /> # Egy exportkorlátozásokat megfogalmazó listát definiáltak a segítségével<br /> # Jól használható rendszerfejlesztési feladatok becslésére is<br /> # Egy faktor alapú költségbecslő modell<br /> # A modell becsléséhez ismerni kell minden projektrésztvevő havi fizetési költségét<br /> <br /> <br /> == Kik tekinthetők a rendszer érintettjeinek (stakeholder) az alábbiak közül? ==<br /> {{kvízkérdés|típus=több|válasz=1,2,3,4}}<br /> # Hatóságok<br /> # Megrendelők<br /> # Végfelhasználók<br /> # Fejlesztők<br /> <br /> <br /> == Mi igaz az UML használati esetekkel (use case) kapcsolatban? ==<br /> {{kvízkérdés|típus=több|válasz=3}}<br /> # Egy használati eset egy forgatókönyvet (scenario) ír le<br /> # Az aktor a modellezett rendszernek egy olyan része, aki valami interakciót hajt végre<br /> # Egy használati esetben nem csak a rendszer felhasználója lehet aktor<br /> # A használati eset diagram tartalmazza a használati esettel kapcsolatos összes fontos információt<br /> <br /> <br /> == Melyik állítás NEM igaz Gantt diagramok kapcsán? ==<br /> {{kvízkérdés|típus=egy|válasz=2}}<br /> # A Gantt diagram egyik lehetséges felhasználása, hogy különböző szempontok szerinti ütemezéseket javaslunk a projekt tevékenységeihez<br /> # Akkor és csak akkor van függőség két tevékenység között, ha az egyiket csak akkor lehet elkezdeni, amikor a másik már befejeződik<br /> # Az elemi tevékenységek becsült időráfordítását is felhasználjuk a Gantt diagram elkészítéséhez<br /> # A tartalék (slack) azt adja meg, hogy mennyi tartalék időnk van az adott tevékenység befejezésében<br /> <br /> <br /> == Mi jellemző az integrációs mintákra? ==<br /> {{kvízkérdés|típus=több|válasz=1,3,4}}<br /> # A Feature Branch minta esetén egy új funkcióval kapcsolatos minden munkát egy külön, saját ágon végezzük, és csak akkor integráljuk vissza, amikor kész az új funkció<br /> # A Mainline Integration minta gyakori, a Feature Branch minta ritka integrációt ír elő<br /> # A Mainline Integration mintában a fejlesztők a mainline-on keresztül integrálják a munkájukat, onnan leszedve és összefésülve a többiek változtatásait, majd – ha működik – akkor a saját változtatásaikat is vissza integrálják<br /> # A Feature Branch minta esetén egy hibajavítással kapcsolatos minden munkát egy külön, saját ágon végezzük, és csak akkor integráljuk vissza, amikor kész az új funkció<br /> <br /> <br /> == Mely állítások igazak a kiadás mintákra? ==<br /> {{kvízkérdés|típus=több|válasz=1,3}}<br /> # A Release Branch minta esetén a kiadandó szoftververzió egy külön, release branch-en található<br /> # A Release-Ready Mainline minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat<br /> # A Release Branch minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat<br /> # A Release-Ready Mainline minta esetén a kiadandó szoftververzió egy külön, release branch-en található<br /> <br /> <br /> == Mi igaz a tesztelésre? ==<br /> {{kvízkérdés|típus=több|válasz=3}}<br /> # A tesztelés mindig manuális folyamat<br /> # Teszteléssel be lehet látni a szoftver helyességét<br /> # A tesztelés segíthet felderíteni a szoftver elgépelésekből eredő hibáit<br /> # A 100%-os utasításfedettség azt jelenti, hogy a rendszerünk összes lehetséges viselkedését kipróbáltuk<br /> <br /> <br /> == Jelölje be az alábbi osztálydiagramra igaz állításokat! ==<br /> {{kvízkérdés|típus=több|válasz=1,3}}<br /> # A Door és Window osztályok a Dwelling osztállyal kompozíciós (rész-egész) viszonyban állnak<br /> # A Door és Window osztályok kapcsolata a Dwelling osztállyal feléjük nem navigálható<br /> # A Dwelling osztálynak mindig pontosan 1 owner-e van<br /> # Az Apartment osztály megvalósítja a Dwelling interfészt<br /> <br /> <br /> == Mely állítások igazak a szoftverrendszerekre? ==<br /> {{kvízkérdés|típus=több|válasz=1,2}}<br /> # Elsődleges értékét a szoftver végrehajtása adja<br /> # Lehetnek hardverben megvalósított részei<br /> # Folyamatos, megszakítás nélküli működésre képes<br /> # Kizárólag szoftverből álló rendszer<br /> <br /> <br /> == Melyik állítás igaz a modellezés kapcsán? ==<br /> {{kvízkérdés|típus=egy|válasz=4}}<br /> # Modellezés során nem érdemes a modellt finomítani, mert komplex lesz és nem tudjuk használni majd. <br /> # Érdemes egy nagy, közös modellt készíteni, ami leírja a készítendő rendszer összes fontos jellemzőit<br /> # Hierarchikus finomítás során a változók értékkészletét finomítjuk<br /> # Az absztrakció alkalmazásával bizonyos információt szándékosan elhanyagolunk a modell készítése során<br /> <br /> <br /> == Melyik dokumentumban fogalmazzuk meg a rendszer komponensekre bontását? ==<br /> {{kvízkérdés|típus=egy|válasz=4}}<br /> # Felhasználói dokumentáció<br /> # Követelményspecifikáció<br /> # Komponensterv<br /> # Architektúraterv<br /> <br /> <br /> == Mi igaz a szoftvermérnökségre? ==<br /> {{kvízkérdés|típus=több|válasz=3,4}}<br /> # Egy mérnöki ág, ami kizárólagosan szoftverek fejlesztésére fókuszál<br /> # Alapelve, hogy kizárólag tervezés után lehet az implementációt elvégezni<br /> # Célja alapos módszerek kidolgozása, amik szoftverek tervezését és fejlesztését segítik<br /> # Egy lehetséges definíciója, hogy többverziós programok többszereplős fejlesztése<br /> <br /> <br /> == Mitől lesz jól érthető egy forráskód? ==<br /> {{kvízkérdés|típus=több|válasz=1,3,4}}<br /> # Érthetőek a változónevek<br /> # Minden függvény külön fájlba van kiszervezve<br /> # Szakterületi, üzleti fogalmakat használ, ahol az indokolt<br /> # A programozási nyelv és platform bevett stílusát, mintáit használja<br /> <br /> <br /> == Mely állítás igaz? ==<br /> {{kvízkérdés|típus=egy|válasz=1}}<br /> # Használati esetekből lehet teszteseteket származtatni<br /> # A határérték analízis az utasítás (statement) lefedettség növelésére alkalmazott technika<br /> # Az ekvivalencia osztályokat mindig automatikusan, algoritmikusan határozzuk meg<br /> # 100%-os utasítás lefedettség mellett biztosak lehetünk benne, hogy hibátlan a kódunk<br /> <br /> <br /> == Melyik állítás NEM igaz az aktorokra UML használati esetek (use case) esetén? ==<br /> {{kvízkérdés|típus=több|válasz=1,2,3}}<br /> # Az aktorokat minden esetben &quot;pálcika emberke&quot; (stick figure) jelöli a diagramon<br /> # Az aktorokat a diagram bal oldalára kell felvenni<br /> # Egy diagramon egy aktort adhatunk meg, aki a használati eset igénybevételét végzi<br /> # Egy személy több aktor szerepében is lehet az adott rendszer kapcsán<br /> <br /> <br /> == Melyik az agilis módszertan által előnyben részesített alapelv? ==<br /> {{kvízkérdés|típus=több|válasz=1,4}}<br /> # működő szoftver<br /> # nagyon részletes dokumentáció<br /> # előre definiált folyamatok<br /> # együttműködés a megrendelővel<br /> <br /> <br /> == Ki tagja a Scrum csapatnak? ==<br /> {{kvízkérdés|típus=több|válasz=1,2,4}}<br /> # Tesztelő<br /> # Product owner<br /> # Megrendelő<br /> # Fejlesztő<br /> <br /> <br /> == Kik tekinthetők érintetteknek (stakeholder) az alábbiak közül? ==<br /> {{kvízkérdés|típus=több|válasz=1,2,3,4}}<br /> # Üzemeltetők<br /> # Beszállítók<br /> # Hatóságok<br /> # Fejlesztők<br /> <br /> <br /> == Jelölje be az igaz állításokat az alábbi, komponens modellezéssel kapcsolatos állítások közül! ==<br /> {{kvízkérdés|típus=több|válasz=1,2}}<br /> # Az interfészek a függőségi kapcsolatok pontosításaként használhatók<br /> # A belső komponens által megvalósított interfész kivezetését a külső komponensre delegációs összeköttetéssel valósíthatjuk meg<br /> # Az interfészeknek nem lehet attribútuma<br /> # Egy port lehet összetett, ekkor több portja van<br /> <br /> <br /> == Mi igaz a moduláris dekompozícióra? ==<br /> {{kvízkérdés|típus=több|válasz=2,3,4}}<br /> # Kizárólag szoftver (komponensek) esetén értelmezhető ez az alapelv<br /> # Az alapja az információrejtés (information hiding)<br /> # Az implementáció szintjén alkalmazhatjuk, amikor a (szoftver) komponenst osztályokra bontjuk fel<br /> # Az architektúra tervezés során alkalmazhatjuk, amikor a rendszert komponensekre bontjuk fel<br /> <br /> <br /> == Melyik igaz az agilis módszertanokra? ==<br /> {{kvízkérdés|típus=egy|válasz=2}}<br /> # Kanban táblát használunk minden fejlesztés során<br /> # Az agilitás, a változásra való reagálás képessége kiemelt fontosságú<br /> # Nem kell semmiféle tervet készíteni, mert úgyis minden változik majd<br /> # A sprint célja a megrendelői szerződés egyik pontjának megvalósítása<br /> <br /> <br /> == Mely állítás(ok) igaz(ak)? ==<br /> {{kvízkérdés|típus=egy|válasz=1}}<br /> # 100%-os döntési (decision) lefedettségből következik a 100%-os utasítás (statement) lefedettség <br /> # Teszteléskor a fő lefutási ágat (happy path) nem érdemes vizsgálni, az általában úgy is jól működik<br /> # Ha a specifikáció alapú tesztjeink hibátlanul lefutottak, nincs értelme kódlefedettséget vizsgálni<br /> # Csak olyan tesztkészlet fogadható el, ami 100%-os döntésfedettséget ér el<br /> <br /> <br /> == Mely fogalomhoz tartozik az adott definíció? Kiválasztva egy kódrészletet, meg kell tudni mutatni, hogy az milyen követelmény miatt került be ==<br /> {{kvízkérdés|típus=egy|válasz=2}}<br /> # Követelmény menedzsment<br /> # Hátrafelé követhetőség<br /> # Tanúsítás<br /> # Előrefelé követhetőség<br /> <br /> <br /> ==  Mely állítások igazak a &quot;szoftverfejlesztési életciklus&quot; modellek kontextusában? ==<br /> {{kvízkérdés|típus=több|válasz=3,4}}<br /> # Alkalmazásuk kritikus rendszerek fejlesztésekor ajánlott; más jellegű rendszer esetén túl költséges a használatuk<br /> # Általában technológiafüggő ajánlásokat (pl. támogatott programozási nyelv, build keretrendszer) is megfogalmaznak<br /> # Minden életciklus modell lépések vagy fázisok sorozatából áll, amelyekhez jól meghatározott kimenetek tartoznak<br /> # Céljuk a szoftver tervezésének, megvalósításának, illetve működtetésének szisztematikus leírása<br /> <br /> <br /> == Melyik állítás igaz a Scrum-ban a sprintre? ==<br /> {{kvízkérdés|típus=egy|válasz=5}}<br /> # Addig nem ér véget a sprint, amíg a sprint backlogba beválogatott minden feladatot meg nem oldott a csapat<br /> # A sprint során többször is bemutatja a csapat az eredményeket az ügyfélnek a gyors visszajelzés érdekében<br /> # Ha a sprint során hibát találunk az adott sprintben fejlesztendő funkcióban, akkor azt még abban a sprintben ki kell javítani<br /> # Egy sprint két hétig tart<br /> # Egyik másik állítás sem igaz<br /> <br /> <br /> == Melyik állítás NEM igaz a modellezés kapcsán az alábbi háromból? ==<br /> {{kvízkérdés|típus=egy|válasz=1}}<br /> # Mind a három állítás IGAZ<br /> # Állítás 2: Nem csak grafikus modellezési nyelveket lehet definiálni<br /> # Állítás 3: Hierarchikus finomítás során a modell elemeit felbontjuk további alelemekre<br /> # Állítás 1: Egy modellezési nyelv szemantikája a modell és modellelemek jelentését adja meg<br /> <br /> <br /> == Melyik állítás igaz a strukturális kódmetrikákra? ==<br /> {{kvízkérdés|típus=több|válasz=4}}<br /> # A ciklomatikus komplexitás a kódban lévő ciklusok számát adja meg<br /> # A ciklomatikus komplexitás meghatározásához ki kell először számolni a vezérlési szerkezetek legmélyebb beágyazását (max nesting)<br /> # Két modul közül az a bonyolultabb, amiben több kódsor van (LoC)<br /> # A csomósodás (knots) nevű metrika a párhuzamos ágak számát adja meg<br /> <br /> <br /> == Milyen praktikus technikák léteznek a kódolási irányelvek betartatására? ==<br /> {{kvízkérdés|típus=több|válasz=1,3}}<br /> # Átvizsgálás GitHub pull request review keretében<br /> # Megkövetelni, hogy azonos operációs rendszert használjanak a fejlesztők<br /> # Fejlesztőkörnyezet (IDE) formázási funkcióinak használata<br /> # Strukturális teszttervezés utasításfedettség alapján</div>

Török Zsombor