Szoftvertechnológia 1. Flashcards
1
Q
Minek a rövidítése a RUP?
RationalUnifiedProcess
RadicalUndefinedProcess
RationalUndefinedProcess
RadicalUnifiedProcess
A
RationalUnifiedProcess
2
Q
Melyek a RUP modell fázisai?
Elindítás, kidolgozás, megépítés, átmenet
Kezdeményezés, tervezés, elkészítés, átadás
Elindítás, tervezés, kifejtés, átadás
Helyzetelemzés, tervezés, kidolgozás, átadás
A
Elindítás, kidolgozás, megépítés, átmenet
3
Q
Mely modell fázisait foglalja magában a RUP modell 2. dimenziója?
Vízesés modell
Evolúciós modell
Spirál modell
V-modell
A
Vízesés modell
4
Q
Mi az a RUP?
Egy specifikációs módszer.
Egy zenei stílus.
A Vízesés modell utolsó fázisa.
Egy szoftverfejlesztési modell.
A
Egy szoftverfejlesztési modell.
5
Q
Miért olyan fontos a követelményspecifikáció a RUP modellben?
Azért, mert jó követelményspecifikációval a projekt végén sok prémiumra számíthatunk.
Egyrészt azért fontos, hogy ne kelljen sokat kommunikálni a fejlesztőkkel, másrészt azért, hogy a
fejlesztés többi fázisát ne kelljen elvégezni, mivel jó követelményspecifikáció esetén nincs szükség
a fejlesztés többi fázisára.
A számos előny közül kiemelendő, hogy ha a követelmények pontosan le vannak fektetve, akkor
később a megrendelővel sem kell annyit egyeztetnünk, illetve a fejlesztés többi fázisát gyorsabban
el tudjuk végezni, mivel letisztult, pontos kiindulási adataink vannak.
A
A számos előny közül kiemelendő, hogy ha a követelmények pontosan le vannak fektetve, akkor
később a megrendelővel sem kell annyit egyeztetnünk, illetve a fejlesztés többi fázisát gyorsabban
el tudjuk végezni, mivel letisztult, pontos kiindulási adataink vannak.
6
Q
Mely jellemző nem az agilis szoftverfejlesztés jellemzője?
rugalmas
jó követelményspecifikáció
jó kommunikáció a megrendelővel, felhasználóval
nagyon bonyolult szabályrendszerek
A
nagyon bonyolult szabályrendszerek
7
Q
Mely szavak jellemzik leginkább az agilis szoftverfejlesztést?
fürge, rugalmas, hatékony, kommunikatív
gyors, törtető, zárkózott, merev
lassú, hatékony, kommunikatív, előre definiált
fürge, előre definiált, korlátolt, hatékony
A
fürge, rugalmas, hatékony, kommunikatív
8
Q
Mi a scrum?
Agilis szoftverfejlesztési módszer.
Utcai harctípus.
Gyorsított üzleti eljárás.
A
Agilis szoftverfejlesztési módszer.
9
Q
Melyek jellemzik a scrum-ot?
sprint, productbacklog, dailyscrum meeting
scrumfight, 100 m sprint, relaxingtraining
economicplanning, sprint, business meeting
A
sprint, productbacklog, dailyscrum meeting
10
Q
Kik a scrum résztvevői?
Product Owner, ScrumMaster, Team
SrumTeam, Coach, Audience
A
Product Owner, ScrumMaster, Team
11
Q
Egy szoftver projektben mi a feladata a projektvezetőnek?
projekttervezés, felülvizsgálat, beszámoló
projekt anyagi támogatása, kész projekt felülvizsgálata
team munkájának gazdasági elemzése, tanácsadás a megrendelőnek
A
projekttervezés, felülvizsgálat, beszámoló
12
Q
Mi a feladata egy szoftverprojektben a projektmenedzsernek?
kiegészítő munkák, melyekkel könnyebbé teszi a team munkáját
team oktatása, team ellenőrzése a projekt végén, jelentések készítése a team felé
team összeállítása és vezetése, ütemterv elkészítése, képviselet a külvilág felé
A
team összeállítása és vezetése, ütemterv elkészítése, képviselet a külvilág felé
13
Q
Mely tervre nem igaz, hogy egy szoftverprojekt tervezésének fontos része?
validációs terv
konfigurációkezelési terv
épületgépészeti terv
karbantartási terv
A
épületgépészeti terv
14
Q
Mit nem tartalmaz a projektterv?
bevezetés
kockázatelemzés
megrendelő fizetése
projekt ütemterve
A
megrendelő fizetése
15
Q
Egy szoftverprojekt során mely nem szoftverkockázat?
specifikáció késése
méret alábecslése
munkaerő stílusának megváltozása
technológia megváltozása
A
munkaerő stílusának megváltozása
16
Q
Egy szoftverprojekt esetében mely nem kockázati kategória?
projektkockázat
termékkockázat
szomszédos kockázat
üzleti kockázat
A
szomszédos kockázat
17
Q
Miért jobb a COCOMO Intermediate, mint a COCOMO Basic?
Mert számol költségtényezőkkel is.
Mert később dolgozták ki.
Mert olcsóbb.
A
Mert számol költségtényezőkkel is.
18
Q
Hány csoportra oszthatjuk a COCOMO Intermediate költségtényezőit?
3
6
4
5
A
4
19
Q
Mely nem tartozik a COCOMO Intermediate személyi költségtényezői (personnelattributes) közé?
applicationsexperience
virtualmachineexperience
communicationability
software engineercapability
A
communicationability
20
Q
A COCOMO2 mely modellre vonatkozik elsősorban?
V-modell
vízesés modell
spirál modell
evolúciós modell
A
vízesés modell
21
Q
Mi az a CMM?
Kormányzati projektre kifejlesztett módszer annak kiderítésére, hogy milyen eséllyel teljesül a
projekt.
Koordinált műszaki manufaktúra.
Olyan módszer, mellyel pontosan meghatározható a projekt teljes költsége.
A
Kormányzati projektre kifejlesztett módszer annak kiderítésére, hogy milyen eséllyel teljesül a
projekt.
22
Q
Melyik a CMM utódja?
CMM1
CMM2
CMMb
CMMI
A
CMMI
23
Q
Mely nem a CMMI fő iránya?
development
services
hardware
acquisition
A
hardware
24
Q
Melyek a CMMI érettségi szintjei?
Initial, Managed, Defined, QuantitativelyManaged, Optimizing
Initial, Intermediate, Defined, Created, Optimized
Incomplete, Initial, Defined, Performed, Optimizing
A
Initial, Managed, Defined, QuantitativelyManaged, Optimizing
25
Mi a feladata a scrum-ban a Product Ownernek?
Felelős a költségekért, illetve elfogadja vagy visszadobja a kész szoftverrészeket.
Felelős a scrum betartásáért és ő finanszírozza a szoftver elkészítését.
Biztosítja, hogy a team hatékonyan tudjon dolgozni, illetve folyamatosan ellenőrzi a team munkáját.
Felelős a scrum betartásáért és biztosítja, hogy a csapat hatékony és termelékeny legyen.
26
Mi a feladata a scrum-ban a Teamnek?
Csapat alkotása, a szoftver elkészítése.
Mindenkinek megvan a titulusa, eszerint végzi a feladatát.
A projekt legvégéig fix tagsággal működik, és a szoftver tesztelése a legfontosabb feladata.
Csapat alkotása, a szoftver elkészítése.
27
Mely állítás nem igaz a product backlog-ról?
A kívánt munkák listáját tartalmazza a projekten.
Része a sprint backlog.
A sprint burndown chart része.
A sprint burndown chart része.
28
Mely állítás nem igaz a daily scrum-ra?
Állva történik.
Nagyon rövid (kb. 15 perc).
Során megoldják a felmerülő problémákat.
Megbeszélik, hogy ki mit végez el.
Során megoldják a felmerülő problémákat.
29
Mely állítás nem igaz a sprint-re?
Közben a csapatot nem érheti külső hatás.
A napi scrum meetinggel kezdődik.
2-4 hetes iterációkban történik.
Pontosan egy van belőle egy projekt során.
Pontosan egy van belőle egy projekt során.
30
Mennyi ideig tart egy sprint?
2-4 hét
1-6 hónap
2 hét – 6 hónap
4-8 hét
2-4 hét
31
Mi történik a sprint planning során?
Produckt backlog és sprint backlog elkészítése, a sprint céljának meghatározása.
A daily scrum meeting témájának előkészítése.
A szoftver elkészítése.
Produckt backlog és sprint backlog elkészítése, a sprint céljának meghatározása.
32
Mi a sprint backlog?
A product backlog része, amit a sprint alatt teljesíteni kell.
A product owner által meghatározott tevékenységek.
A scrum master által megírt tevékenységlista, mely nem bővíthető, pontosan be kell tartani.
A product backlog része, amit a sprint alatt teljesíteni kell.
33
Mi az a sprint burndown chart?
Egy diagram, mely tartalmazza (naponta), hogy mennyi idő és mennyi elem van még hátra.
Egy diagram, melyen lineárisan ábrázolják a projekt időbeosztását.
Egy diagram, mely folytonosan lefelé halad a 0-ig.
Egy diagram, mely tartalmazza (naponta), hogy mennyi idő és mennyi elem van még hátra.
34
Mi az a release burndown chart?
Diagram, melyen látható, hogy időben kész lesz-e a szoftver aktuális változata.
Diagram, melyen láthatjuk a projekt teljes időbeosztását.
Diagram, melyen 0-200 között láthatjuk a napi hátralévő feladatszámot.
Diagram, melyen látható, hogy időben kész lesz-e a szoftver aktuális változata.
35
Mi jellemző a CMMI „Kezdeti ” érettségi szintére?
A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek.
A hangsúly a folyamatok tökéletesítésén van.
A folyamatok mérhetőek és ellenőrzöttek.
A folyamatok a szervezetre szabottak és biztonságosabbak.
A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek.
36
Mi jellemző a CMMI „Menedzselt” érettségi szintére?
A folyamatok a projektre szabottabbak.
A hangsúly a folyamatok tökéletesítésén van.
A folyamatok mérhetőek és ellenőrzöttek.
A folyamatok a szervezetre szabottak és biztonságosabbak.
A folyamatok a projektre szabottabbak.
37
Mi jellemző a CMMI „Meghatározott” érettségi szintére?
A folyamatok a szervezetre szabottak és biztonságosabbak.
A hangsúly a folyamatok tökéletesítésén van.
A folyamatok mérhetőek és ellenőrzöttek.
A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek.
A folyamatok a szervezetre szabottak és biztonságosabbak.
38
Mi jellemző a CMMI „Mennyiségileg menedzselt” érettségi szintére?
A folyamatok mérhetőek és ellenőrzöttek.
A hangsúly a folyamatok tökéletesítésén van.
A folyamatok a szervezetre szabottak és biztonságosabbak.
A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek.
A folyamatok mérhetőek és ellenőrzöttek.
39
Mi jellemző a CMMI „Optimalizált” érettségi szintére?
A hangsúly a folyamatok tökéletesítésén van.
A folyamatok mérhetőek és ellenőrzöttek.
A folyamatok a szervezetre szabottak és biztonságosabbak.
A folyamatok kiszámíthatatlanok, gyengén ellenőrzöttek.
A hangsúly a folyamatok tökéletesítésén van.
40
Mit mond ki a Moore-törvény?
Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény
másfél évenként megkétszereződik.
Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény
két évenként megkétszereződik.
Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény
másfél évenként megkétszereződik.
Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény két
évenként megkétszereződik.
Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény
másfél évenként megkétszereződik.
41
Mik egy hardver rendszer részei?
Számítógép
Számítógéphez csatlakozó perifériák
Kommunikációs elemek
A rendszer felépítését, összetételét leíró dokumentáció
A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció
A rendszer koncepcióját, tervét leíró fejlesztői dokumentáció
A számítógépben található komponensek, egységek
Számítógép
Számítógéphez csatlakozó perifériák
Kommunikációs elemek
A rendszer felépítését, összetételét leíró dokumentáció
A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció
42
Mik egy szoftver rendszer részei?
A számítógépen futó programok együttese
A programok futtatásához szükséges konfigurációs adatok, fájlok együttese
A rendszer felépítését, összetételét leíró rendszer-dokumentáció.
A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció
A számítógép tároló egységein található adat, információ
A szoftverhez tartozó adattároló egység (pl.: CD, DVD)
A számítógépen futó programok együttese
A programok futtatásához szükséges konfigurációs adatok, fájlok együttese
A rendszer felépítését, összetételét leíró rendszer-dokumentáció.
A rendszer üzemeltetését, működtetését leíró felhasználói dokumentáció
43
Az alábbiak közül melyik lehet egy szoftver termék?
Generikus termék
Genetikus termék
Generális termék
Custom product
Egyik sem
Generikus termék
44
Mi a generikus termék jellemzői?
Fejlesztő cég önálló terméke
Fejlesztő cég saját erőből állítja elő
Nyílt piacon értékesítik
Felhasználói megrendelésre készül
Megrendelő ötletei alapján készül
Fejlesztő cég önálló terméke
Fejlesztő cég saját erőből állítja elő
Nyílt piacon értékesítik
45
Mi a generikus termék jellemzői?
Fejlesztő cég saját tervek alapján készíti el
Bárki megvásárolhatja
Nyílt piacon nem kerül értékesítésre
Megrendelő finanszírozza
Adott ügyfél számára készül
Fejlesztő cég saját tervek alapján készíti el
Bárki megvásárolhatja
46
Mi a megrendeléses termék jellemzői?
Felhasználói megrendelésre készül
Felhasználó igényei alapján tervezik
Szerződés alapján készül
Nyílt piacon értékesítik
Fejlesztő cég saját erőből állítja elő
Fejlesztő cég önálló terméke
Felhasználói megrendelésre készül
Felhasználó igényei alapján tervezik
Szerződés alapján készül
47
Hogyan szokás még nevezni a generikus terméket?
Generic product
Becsomagolt termék
Bedobozolt termék
Zárt termék
Bespoken product
Generic product
Becsomagolt termék
Bedobozolt termék
48
Melyik az a szoftver termék, melynek specifikálását, tervezését, létrehozását a fejlesztő
intézmény a piaci elvárások felmérése alapján, a várható felhasználói igények meghatározása révén
végzi el?
Generic product
Generikus termék
Megrendeléses termék
Custom software
Bespoken product
Egyik sem
Generic product
Generikus termék
49
Szoftver termékek esetén mit jelent a customization?
Egy generikus szoftvert egy adott felhasználó igényeihez alakítva adnak el neki
Adott felhasználó igényei alapján fejlesztenek számára egy egyedi szoftvert
Olyan szoftverről van szó, melyet a felhasználó saját maga testre szabhat, igényeinek megfelelően
A kifejezés nem értelmezett a szoftver termékek esetén
Egy generikus szoftvert egy adott felhasználó igényeihez alakítva adnak el neki
50
Mit értünk az elvárásoknak megfelelő működésen?
A szoftver teljesíti a felhasználói igényeket, elfogadható futási idő alatt, és elfogadható kényelmet
biztosítva végzi el feladatát.
A szoftver kielégíti a specifikációban lefektetett feltételeket, és hibafellépés nélkül végzi el feladatát.
A szoftver működése során nem veszélyeztet emberi életet, nem okoz környezeti és gazdasági
károkat.
A szoftver az elvárt kimenettel szolgál adott bemenetek esetén.
A szoftver teljesíti a felhasználói igényeket, elfogadható futási idő alatt, és elfogadható kényelmet
biztosítva végzi el feladatát
51
Egy szoftver termékre milyen tulajdonságoknak kell teljesülnie?
Hatékony
Megbízható
Használható
Módosítható
Hordozható
Hasznosítható
Mozgatható
Hatékony
Megbízható
Használható
Módosítható
Hordozható
52
Egy szoftver termékre milyen tulajdonságoknak kell teljesülnie?
Tesztelhető
Újra-felhasználható
Karbantartható
Együttműködhető
Biztonságos
Hasznosítható
Tesztelhető
Újra-felhasználható
Karbantartható
Együttműködhető
53
Mit jelent egy szoftver termék esetén a hatékonyság?
Kellő idő alatt teljesíti a számítási feladatát.
Elfogadható a futási ideje.
Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal.
Hibafellépés nélkül hajtja végre előírt feladatát.
Kellő idő alatt teljesíti a számítási feladatát.
Elfogadható a futási ideje.
54
Mit jelent egy szoftver termék esetén a megbízhatóság?
Hibafellépés nélkül hajtja végre előírt feladatát.
Kellő idő alatt teljesíti a számítási feladatát. Elfogadható a futási ideje.
A hibákat felismeri és megfelelően kezeli.
Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal.
Hibafellépés nélkül hajtja végre előírt feladatát.
55
Mit jelent egy szoftver termék esetén a használhatóság?
Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal.
Kellő idő alatt teljesíti a számítási feladatát.
Hibafellépés nélkül hajtja végre előírt feladatát.
Elfogadható a futási ideje.
Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal.
56
Mit jelent egy szoftver termék esetén a módosíthatóság?
Könnyen meg lehet változtatni, ha a követelmények változnak.
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek.
A felhasználó igényei szerint változtathatja a szoftver összetételét, komponenseit.
A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani.
Könnyen meg lehet változtatni, ha a követelmények változnak.
57
Mit jelent egy szoftver termék esetén a hordozhatóság?
A lehető legkevesebb újraírás árán lehessen átvinni egy másik hardver-platformra.
A lehető legkevesebb újraírás árán lehessen átvinni egy másik operációs rendszer alá.
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek,
felhasználhatóak legyenek.
A szoftver mobil informatikai eszközökön is futtatható legyen.
A lehető legkevesebb újraírás árán lehessen átvinni egy másik hardver-platformra.
A lehető legkevesebb újraírás árán lehessen átvinni egy másik operációs rendszer alá.
58
Mit jelent egy szoftver termék esetén a tesztelhetőség?
Könnyen lehessen tesztelni, az esetleges működési hibákat megtalálni.
A szoftver tartalmaz olyan modulokat, melyek elősegítik a tesztek végrehajtását.
A fejlesztés olyan fázishoz érkezett, ahol lehetőség adódik a szoftver termék tesztelésére.
Egyik sem.
Könnyen lehessen tesztelni, az esetleges működési hibákat megtalálni.
59
Mit jelent egy szoftver termék esetén az újra-felhasználhatóság?
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek,
felhasználhatóak legyenek.
A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani.
A felhasználó a szoftvert az eredeti felhasználási igényeken túlmenően más feladatok elvégzésére is
fel tudja használni.
Könnyen meg lehet változtatni, ha a követelmények változnak.
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek,
felhasználhatóak legyenek.
60
Mit jelent egy szoftver termék esetén a karbantarthatóság?
A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani.
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek,
felhasználhatóak legyenek.
Könnyen meg lehet változtatni, ha a követelmények változnak.
Szoftver meghibásodás esetén hatékonyan lehet javítani, módosítani.
A felhasználás során felmerülő igényekhez lehessen megváltoztatni, átalakítani, módosítani.
61
Mit jelent egy szoftver termék esetén az együttműködhetőség?
A szoftver más rendszerekkel való együttműködési, információcserélési lehetőségeire utal.
Megfelelően lehet használni, elfogadható felhasználói kényelemmel, szolgáltatásokkal.
A lehető legkevesebb újraírás árán lehessen átvinni egy másik hardver-platformra, vagy másik
operációs rendszer alá. Az a jó, ha csak újra le kell fordítani az új számítógépen. De az a legjobb, ha
minden további nélkül képes együttműködni az új környezetben.
Az egész szoftver vagy annak jól elhatárolható részei más rendszerekbe is beépíthetőek,
felhasználhatóak legyenek.
A szoftver más rendszerekkel való együttműködési, információcserélési lehetőségeire utal.
62
Mi az úgynevezett Brooks-féle szabály?
Ahhoz, hogy a kezdeti kétemberes fejlesztés ne csak a két ember számára legyen elfogadható,
hanem széles körben, mások által is használható legyen, még további munkára, ráfordításra van
szükség, ami az eredetinek kb. 8-9-szerese.
Ahhoz, hogy a kezdeti néhány emberes fejlesztés ne csak egy szűk kör számára legyen elfogadható,
hanem széles körben, mások által is használható legyen, még további munkára, ráfordításra van
szükség, ami az eredetinek kb. 4-5-szöröse.
Az ugyanazon térfogatba integrálható áramkörök száma és ezzel együtt a számítási teljesítmény
másfél évenként megkétszereződik
Az ugyanazon térfogatba integrálható tranzisztorok száma és ezzel együtt a számítási teljesítmény
másfél évenként megkétszereződik.
Ahhoz, hogy a kezdeti kétemberes fejlesztés ne csak a két ember számára legyen elfogadható,
hanem széles körben, mások által is használható legyen, még további munkára, ráfordításra van
szükség, ami az eredetinek kb. 8-9-szerese.
63
Mi az emberhónap?
A projektek munkaráfordításának egy mérőszáma. Ezt a számot úgy kapjuk meg, hogy a projektben
részt vevő emberek átlagos számát megszorozzuk a projekt teljes időtartamával.
Egy szoftverfejlesztési mérőszám. Megadja, hogy egy adott fejlesztési projekt elvégzéséhez mennyi
időre van szüksége a fejlesztőcsapatnak.
Megadja, hogy a fejlesztő team egy tagjának mennyi idő szükséges a projekt feladat elvégzéséhez.
Megadja, hogy a fejlesztő team havi lebontásban átlagosan hány fejlesztőt alkalmaz az adott projekt
elvégzésére.
A projektek munkaráfordításának egy mérőszáma. Ezt a számot úgy kapjuk meg, hogy a projektben
részt vevő emberek átlagos számát megszorozzuk a projekt teljes időtartamával.
64
Egy szoftverfejlesztési projekt mikor nevezhető sikeresnek?
Ha a kitűzött határidőn belül készül el
Ha a fejlesztés a megállapított költségkereten belül valósul meg
Ha az eredetileg specifikált működési jellemzők többsége teljesül
Ha a felhasználó igényeket teljes mértékben kielégíti
Ha az értékesítés során sikerül profitot termelni
Ha a kitűzött határidőn belül készül el
Ha a fejlesztés a megállapított költségkereten belül valósul meg
Ha az eredetileg specifikált működési jellemzők többsége teljesül
64
Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver
alkalmazási területek közé?
Rendszer-szoftverek
Valós idejű szoftverek
Üzleti célú szoftverek
Rendszer közeli szoftverek
Rendszer-szoftverek
Valós idejű szoftverek
Üzleti célú szoftverek
64
Egy fejlesztési projekt esetén EH=112. Mennyi lehet E és H értéke?
E=1, H=112
E=2, H=56
E=28, H=4
E=7, H=16
E=14, H=8
E=1, H=112
E=2, H=56
E=28, H=4
E=7, H=16
E=14, H=8
64
Mi a VIR?
EIS
Vezetői információs rendszer
ERP
Vállalati információs rendszer
Vállalati irányítási rendszer
Vezetői irányítási rendszer
EIS
Vezetői információs rendszer
64
Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver
alkalmazási területek közé?
Mérnöki és tudományos célú szoftverek
Beágyazott szoftverek
Felhasználói szoftverek
Operációs rendszer szoftverek
Mérnöki és tudományos célú szoftverek
Beágyazott szoftverek
64
Mi igaz a VIR esetén?
Elsősorban felső szintű döntéshozók, pénzügyi szakemberek és üzletemberek számára nyújt
támogatást.
Nem dolgozik bele a vállalati adatbázisba, onnan csak kiválasztja a „hasznos” adatokat.
Egy vállalat összes üzleti tevékenységét lefedi, kiszolgálja.
Óriási mennyiségű adat írását, olvasását, feldolgozását végzi.
Elterjedt angol megnevezése az Enterprise Resource Planning System.
Elsősorban felső szintű döntéshozók, pénzügyi szakemberek és üzletemberek számára nyújt
támogatást.
Nem dolgozik bele a vállalati adatbázisba, onnan csak kiválasztja a „hasznos” adatokat.
65
Az alábbi kategóriák közül melyek tartoznak Roger Pressman által felállított szoftver
alkalmazási területek közé?
Személyi számítógépes szoftverek
Mesterséges intelligencia szoftverek
Irodai és üzleti szoftverek
Tervező és grafikai szoftverek
Személyi számítógépes szoftverek
Mesterséges intelligencia szoftverek
66
Mely állítások igazak?
Az EIS rendszerek a vezetői döntéshez szükséges információkat szűrik ki, szelektálják az adatbázisból.
Egy vállalat ERP rendszere az EIS rendszerre épül.
Az EIS rendszerek egy vállalat összes üzleti tevékenységét lefedi, kiszolgálja.
Az EIS rendszerek nagy mennyiségű adatok olvasását, írását, feldolgozását végzik.
Az EIS rendszerek a vezetői döntéshez szükséges információkat szűrik ki, szelektálják az adatbázisból.
67
Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések?
Szolgáltatást nyújt, strukturált vagy strukturálatlan fájlok feldolgozása, nagy mennyiségű
adatfeldolgozás.
Rendszer szoftver
Mérnöki és tudományos célú szoftver
Valós idejű szoftver
Üzleti célú szoftver
Rendszer szoftver
68
Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések?
Időbeliséghez igazodás, külső események felügyelete, vezérlése, időkereten belüli reagálás.
Valós idejű szoftver
Rendszer szoftver
Mesterséges intelligencia szoftver
Üzleti célú szoftver
Valós idejű szoftver
69
Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések?
Nagy mennyiségű információ feldolgozás, komponens alapú komplex rendszer, minden
komponensnek egyéni funkció.
Üzleti célú szoftver
Rendszer szoftver
Mérnöki és tudományos célú szoftver
Beágyazott szoftver
Üzleti célú szoftver
70
Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések?
Nagy mennyiségű számítási igény, nagy teljesítményű hardver, komplex matematikai műveletek.
Mérnöki és tudományos célú szoftver
Rendszer szoftver
Mesterséges intelligencia szoftver
Egyik sem
Mérnöki és tudományos célú szoftver
71
Mely szoftver alkalmazási területre jellemzőek az alábbi kifejezések?
Vezérlő eszköz vagy célberendezés működését segítik, teszik lehetővé.
Beágyazott szoftver
Mesterséges intelligencia szoftver
Rendszer szoftver
Egyik sem
Beágyazott szoftver
72
Honnan számítható egy szoftver életciklusa?
Egy szoftver életciklusa a követelmények specifikálásával veszi kezdetét.
Egy szoftver életciklusa akkor kezdődik, amikor a felhasználó használatba veszi az elkészült szoftvert.
Egy szoftver életciklusa a fejlesztési folyamattal egy időben kezdődik.
Egy szoftver életciklusa az üzembe helyezéssel indul.
Egy szoftver életciklusa a követelmények specifikálásával veszi kezdetét.
73
Mikor fejeződik be egy szoftver életciklusa?
Amikor a szoftver elavulttá válik, használaton kívülre kerül.
Amikor a szoftverfejlesztés lezárul, értékesíthetővé válik a szoftver.
Egy szoftver életciklusa sosem zárul le, mert a szoftver nem öregszik és nem megy tönkre.
Amikor a szoftvernek újabb kiadása kerül értékesítésre, ezáltal a régebbi verzió használaton kívülre
kerül.
Amikor a szoftver elavulttá válik, használaton kívülre kerül.
74
Az alábbiak közül melyek szoftverfejlesztési modellek?
Vízesés modell
Evolúciós fejlesztés
Inkrementális fejlesztés
Spirál modell
V-modell
Generikus fejlesztés
Dekrementális fejlesztés
Iterációs fejlesztés
Vízesés modell
Evolúciós fejlesztés
Inkrementális fejlesztés
Spirál modell
V-modell
75
Az alábbi állítások közül mely hamis?
A V-modell leginkább a vállalati információs rendszerekhez alkalmas.
A spirál modell a nem szigorúan specifikált kiinduláshoz alkalmazható.
A spirál modell az erőforrások elosztására és a költségekre koncentrál.
A V-modell a biztonsági követelmények teljesítéséhez alkalmazkodik
A V-modell leginkább a vállalati információs rendszerekhez alkalmas.
A spirál modell a nem szigorúan specifikált kiinduláshoz alkalmazható.
76
Mi jellemezte egy szoftverfejlesztési folyamatot a szoftver-technológia kialakulásának
kezdetén?
Egymás után elvégzendő feladatok sorozatának definiálása.
Egyes feladatok végrehajtására konkrét tevékenységek rendelése.
Fejlesztési tevékenységek időrendbeli rendezése.
Konkrét feladat megoldására alkalmas modell.
Fejlesztési lépések halmazának definiálása.
Fejlesztési lépések céljának meghatározása.
Fejlesztési folyamat elvont, absztrakt definiálása.
Általános fejlesztési modell.
Egymás után elvégzendő feladatok sorozatának definiálása.
Egyes feladatok végrehajtására konkrét tevékenységek rendelése.
Fejlesztési tevékenységek időrendbeli rendezése.
Konkrét feladat megoldására alkalmas modell.
77
Mi jellemezi egy szoftverfejlesztési folyamatot a szoftver-technológia mai szemlélete
szerint?
Fejlesztési lépések halmazának definiálása.
Fejlesztési lépések céljának meghatározása.
Fejlesztési folyamat elvont, absztrakt definiálása.
Általános fejlesztési modell.
Egymás után elvégzendő feladatok sorozatának definiálása.
Egyes feladatok végrehajtására konkrét tevékenységek rendelése.
Fejlesztési tevékenységek időrendbeli rendezése.
Konkrét feladat megoldására alkalmas modell.
Fejlesztési lépések halmazának definiálása.
Fejlesztési lépések céljának meghatározása.
Fejlesztési folyamat elvont, absztrakt definiálása.
Általános fejlesztési modell.
78
Milyen fázisok találhatóak a vízesés modellben?
Követelmények elemzése és meghatározása
Rendszertervezés és szoftvertervezés
Implementáció és az egységek tesztelése
Integrálás és rendszertesztelés
Üzemeltetés és karbantartás
Fejlesztési célok, követelmények meghatározása
Modulok előállítása és tesztelése
Felhasználók oktatása
Követelmények elemzése és meghatározása
Rendszertervezés és szoftvertervezés
Implementáció és az egységek tesztelése
Integrálás és rendszertesztelés
Üzemeltetés és karbantartás
79
A vízesés modell fázisai közül melyik az, melyből bármelyik korábbi fázishoz visszatérhetünk?
Üzemeltetés és karbantartás
Rendszer validálás és bizonylatolás
Integrálás és rendszertesztelés
Implementáció és egységek tesztelése
Üzemeltetés és karbantartás
80
Hogyan szokás még nevezni a vízesés modellt?
Lineáris ciklus
Inkrementális modell
Növekményes fejlesztés
Evolúciós fejlesztés
Prototípus alapú fejlesztés
Lineáris ciklus
81
Mikor alkalmazható jól a vízesés modell?
Ha a fejlesztési követelmények egyértelműen meg vannak határozva.
Ha nem áll fent annak a veszélye, hogy a követelmények megváltoznak.
Ha a fejlesztési követelmények kezdetben nincsenek egyértelműen meghatározva.
Ha a fejlesztési követelmények a projekt során többször módosulnak.
Ha a fejlesztési követelmények egyértelműen meg vannak határozva.
Ha nem áll fent annak a veszélye, hogy a követelmények megváltoznak.
82
Ha egy rendszert nem lehet vagy nem érdemes pontosan specifikálni, akkor milyen
szoftverfejlesztési modellt célszerű alkalmazni?
Evolúciós fejlesztés
Prototípus-alapú fejlesztés
Inkrementális modell
Spirál modell
V modell
Evolúciós fejlesztés
Prototípus-alapú fejlesztés
83
Milyen fázisok találhatóak a prototípus alapú fejlesztésben?
Feladat meghatározása
Rendszer specifikálása
Prototípus kifejlesztése
Prototípus megfelelőségének vizsgálata
Rendszer megtervezése
Rendszer megépítése
Prototípusok tesztelése és implementálása
Rendszer üzemeltetése és karbantartása
Integrálás és rendszertesztelés
Feladat meghatározása
Rendszer specifikálása
Prototípus kifejlesztése
Prototípus megfelelőségének vizsgálata
Rendszer megtervezése
Rendszer megépítése
84
Mi jellemző a lineáris ciklusra?
Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött
sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt
megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak
egyetlen „menetben” valósul meg.
Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások
eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására.
Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót
eredményez.
Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a
tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési
ciklusokba, hurkokba rendezve. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel.
Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő
szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes
rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat
rendelik meg.
Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött
sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt
megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak
egyetlen „menetben” valósul meg.
85
Mi jellemző az evolúciós fejlesztésre?
Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások
eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására.
Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót
eredményez.
Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött
sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt
megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak
egyetlen „menetben” valósul meg.
Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a
tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési
ciklusokba, hurkokba rendezve. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel.
Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő
szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes
rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat
rendelik meg
Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások
eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására.
Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót
eredményez.
86
Prototípus alapú fejlesztés esetén melyik az a fázis, mely során visszaléphetünk a modell
kezdeti fázisához?
Prototípus megfelelőségének vizsgálata
Rendszer specifikálása
Rendszer tervezése
Rendszer tesztelése és validálása
Prototípus implementálása és tesztelése
Prototípus megfelelőségének vizsgálata
87
Mekkora rendszereknél célszerű alkalmazni az evolúciós fejlesztést?
Kiss és közepes méretű rendszerek esetén, ahol nincs szükség több team-re.
Nagy méretű rendszerek esetén, ahol több team munkájára van szükség.
Kiss és nagy méretű fejlesztések esetén egyaránt jól használható.
Kiss méretű, de több team együttes munkáját igénylő fejlesztéseknél.
Kiss és közepes méretű rendszerek esetén, ahol nincs szükség több team-re.
88
Nagy rendszereknél érdemes e vegyesen használni az evolúciós és a vízesés modellt? Ha
igen, hogyan?
Igen, a specifikáció végleges kialakítását evolúciós módon, és ezt követően már a vízesés-alapú
folyamattal valósítsuk meg a végleges tervet.
Igen, a specifikáció végleges kialakítását vízesés módon, és ezt követően már az evolúciós-alapú
folyamattal valósítsuk meg a végleges tervet.
Igen, a fejlesztést vízesés modellel hajtsuk végre, ahol minden egyes fázis esetén evolúciós modellt
alkalmazunk.
Nem, nagy rendszereknél általában evolúciós modellt érdemes alkalmazni.
Igen, a specifikáció végleges kialakítását evolúciós módon, és ezt követően már a vízesés-alapú
folyamattal valósítsuk meg a végleges tervet.
89
Mit nevezünk inkrementumnak?
Növekményes fejlesztési modell esetén az egyes részfunkciókat megvalósító fejlesztési változatokat.
Evolúciós fejlesztési modell esetén az egyes részfunkciókat megvalósító fejlesztési változatokat.
Növekményes fejlesztési modell esetén a szoftver specifikációban lefektetett részfunkciókat.
Evolúciós fejlesztési modell esetén a szoftver specifikációban lefektetett részfunkciókat.
Egyik sem.
Növekményes fejlesztési modell esetén az egyes részfunkciókat megvalósító fejlesztési változatokat.
90
Az alábbiak közül melyik igaz a növekményes fejlesztési modell esetén?
Inkrementumokból integrálják össze a kész rendszert.
Az egyes inkrementumokat külön fejlesztik le.
A inkrementumok száma a rendszer moduljainak számától függ.
Jellemző sajátossága a szekvencialitás.
A rendszer validálása során bármely korábbi fázishoz visszaléphetünk.
Inkrementumokból integrálják össze a kész rendszert.
Az egyes inkrementumokat külön fejlesztik le.
91
Inkrementális fejleszt esetén mely fázis során és hova léphetünk vissza?
A rendszer teljességének vizsgálata során léphetünk vissza az inkrementum kifejlesztési fázis elé.
A rendszer teljességének vizsgálata során léphetünk vissza a rendszer architektúra tervezési fázis
elé.
A rendszer validálása során léphetünk vissza az inkrementum validálási fázis elé.
Az inkrementum integrálása során léphetünk vissza az inkrementum kifejlesztési fázis elé.
A rendszer validálása során bármely korábbi fázishoz visszaléphetünk.
A rendszer teljességének vizsgálata során léphetünk vissza az inkrementum kifejlesztési fázis elé.
92
Milyen előnyei vannak az inkrementális fejlesztésnek?
A felhasználónak nem kell megvárnia, amíg a teljes végleges rendszert megkapja.
Viszonylag alacsony a kockázata annak, hogy teljes projekt sikertelen lesz.
A fontos szolgáltatások fogják a legtöbb tesztelést kapni.
Szoros az inkrementumok közti kapcsolat és együttműködés.
Az inkrementumok révén jól kezeli a nagy méretű részfunkciókat.
A fejlesztés során előálló prototípusok révén jól tesztelhető a rendszer
A felhasználónak nem kell megvárnia, amíg a teljes végleges rendszert megkapja.
Viszonylag alacsony a kockázata annak, hogy teljes projekt sikertelen lesz.
A fontos szolgáltatások fogják a legtöbb tesztelést kapni.
93
Növekményes fejlesztés esetén mi a teendő, ha egy inkrementum elkészül (véglegessé
válik)?
Hozzáintegráljuk a már elfogadott és egybeépített többi inkrementumhoz.
Átadjuk a felhasználónak, mivel a növekményes fejlesztés lényege, hogy a megrendelő
inkrementumonként kapja kézhez a szoftver rendszert.
Növekményes fejlesztés esetén nem beszélhetünk inkrementumokról, mivel az az inkrementális
fejlesztéshez tartozik.
Validáljuk a rendszert, döntünk a további inkrementumok fejlesztéséről.
Hozzáintegráljuk a már elfogadott és egybeépített többi inkrementumhoz.
94
Mi jellemző a spirál modellre?
Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a
tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési
ciklusokba. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel.
Ez a modell több egymást követő fejlesztési állomásból tevődik össze, ahol az egyes állomások
eredményeinek elemzése alapján kerül sor a következő állomás tervezésére és megvalósítására.
Ebben a megközelítésben mindegyik állomás az előzőnél teljesebb, jobban kiérlelt verziót
eredményez.
Ebben a megoldásban a felhasználók először csak főbb vonásokban határozzák meg az elérendő
szolgáltatásokat, megadva a fontosabb és a kevésbé fontos szempontokat. Kiindulásként a teljes
rendszert részfunkciókra bontják, és az egyes részfunkciókat megvalósító fejlesztési változatokat
rendelik meg.
Jellemző sajátossága a szekvencialitás, ami úgy nyilvánul meg, hogy az egyes fázisok kötött
sorrendben követik egymást. Mégpedig oly módon, hogy egy fázis csak akkor kezdhető el, ha az őt
megelőző fázis fejlesztési eredménye már rendelkezésre áll. Ideális esetben mindegyik szakasz csak
egyetlen „menetben” valósul meg.
Ebben a modellben az egyes tevékenységek nem előírt sorrendben követik egymást, a
tevékenységek közötti bizonyos visszalépésekkel, hanem folyamatosan előre haladva, fejlesztési
ciklusokba. Itt mindegyik ciklus egy önálló fejlesztési fázist képvisel.
95
: Milyen szektorokból és milyen sorrendben épül fel a spirál modell?
1: Fejlesztési célok, tárgykörök megállapítása. 2: Kockázatok értékelése és csökkentése. 3: Fejlesztés
és validálás. 4: Tervezés
1: Fejlesztési célok, tárgykörök megállapítása. 2: Kockázatok értékelése és csökkentése. 3: Tervezés.
4: Fejlesztés és validálás.
1: Felhasználói igények felmérése. 2: Fejlesztési célok, tárgykörök megállapítása. 3: Fejlesztés és
validálás. 4: Tervezés
1: Felhasználói igények felmérése. 2: Fejlesztési célok, tárgykörök megállapítása. 3: Tervezés. 4:
Fejlesztés és validálás.
1: Fejlesztési célok, tárgykörök megállapítása. 2: Kockázatok értékelése és csökkentése. 3: Fejlesztés
és validálás. 4: Tervezés
96
Spirál modell esetén mi történik a tervezési fázisban?
A projekt teljes átvizsgálása, döntés további folytatásról.
A felhasználói igények alapján meg kell tervezni a szoftver architektúrát.
Az egyes szoftvermodulok implementálásához szükséges tervek előkészítése történik.
Kockázatok azonosítása és csökkentése.
A projekt teljes átvizsgálása, döntés további folytatásról.
97
Az alábbiak közül melyik igaz?
A spirál modell fontos velejárója a kockázatok feltárása és csökkentése.
Spirál modell esetén lehetséges az, hogy az egyik spirál-ciklust a másiktól eltérő modell
használatával valósítsuk meg.
Spirál modell esetén mindegyik ciklusban ugyanazt a modellt kell alkalmaznunk.
Spirál modell esetén nem hangsúlyos a kockázatok elemzése és csökkentése.
A spirál modell fontos velejárója a kockázatok feltárása és csökkentése.
Spirál modell esetén lehetséges az, hogy az egyik spirál-ciklust a másiktól eltérő modell
használatával valósítsuk meg.
98
Milyen fejlesztési modellt vagy modelleket választana olyan feladat esetén, amit előzetesen
pontosan ismer, a teljes felépítéssel együtt?
Vízesés modell
V modell
Prototípus alapú fejlesztés
Inkrementális fejlesztés
Spirál modell
Vízesés modell
99
Milyen fejlesztési modellt vagy modelleket választana olyan feladat esetén, amely nincsen
jól strukturálva, és nehezebb átgondolni?
Evolúciós modell
Prototípus alapú fejlesztés
Spirál modell
V modell
Vízesés modell
Evolúciós modell
Prototípus alapú fejlesztés
100
Milyen fejlesztési modellt vagy modelleket választana olyan feladat esetén, ahol korai
eredményt szeretnénk elérni a felhasználó megnyerése érdekében?
Prototípus alapú fejlesztés
Spirál modell
Inkrementális modell
V modell
Vízesés modell
Prototípus alapú fejlesztés
Spirál modell
Inkrementális modell
101
Mi jellemzi a biztonságkritikus rendszert?
Ne veszélyeztesse az emberi életet.
Ne veszélyeztesse az egészséget.
Ne okozzon gazdasági kárt.
Ne okozzon környezeti kárt.
Tipikusan ilyenek a banki szoftverek.
Tipikusan ilyenek a vállalati számlázó szoftverek.
Szoftver hiba esetén is képes végrehajtani a feladatát.
Ne veszélyeztesse az emberi életet.
Ne veszélyeztesse az egészséget.
Ne okozzon gazdasági kárt.
Ne okozzon környezeti kárt.
Tipikusan ilyenek a banki szoftverek.
102
Mi jellemző a hibatűrő rendszerekre?
Hiba esetén is képes ellátni főbb funkcióit.
Hiba esetén teljesítménye lecsökkenhet.
Hiba esetén is ugyanolyan hatásfokkal képes működni, mint hibamentesen.
Szoftver meghibásodás esetén is képes működni.
Tervezésnél az a cél, hogy a szoftver minden körülmények között hibamentesen működjön.
Hiba esetén is képes ellátni főbb funkcióit.
Hiba esetén teljesítménye lecsökkenhet.
103
Mi a megbízhatóság?
Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t]
időintervallumban, feltéve, hogy a t0 <= t időpontban hibátlanul működött.
Annak valószínűsége, hogy az informatikai rendszer helyesen működik a t időpontban.
Annak valószínűsége, hogy az informatikai rendszer helyesen vagy hibásan működik a t időpontban,
de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem
befolyásolja károsan más rendszerek működését.
Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt.
Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t]
időintervallumban, feltéve, hogy a t0 <= t időpontban hibátlanul működött.
104
Mi a rendelkezésre állás?
Annak valószínűsége, hogy az informatikai rendszer helyesen működik a t időpontban.
Annak valószínűsége, hogy az informatikai rendszer helyesen vagy hibásan működik a t időpontban,
de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem
befolyásolja károsan más rendszerek működését.
Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt.
Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t]
időintervallumban, feltéve, hogy a t0 <= t időpontban hibátlanul működött.
Annak valószínűsége, hogy az informatikai rendszer helyesen működik a t időpontban.
105
Mi a biztonságosság?
Annak valószínűsége, hogy az informatikai rendszer helyesen vagy hibásan működik a t időpontban,
de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem
befolyásolja károsan más rendszerek működését.
Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt.
Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t]
időintervallumban, feltéve, hogy a t0 <= t időpontban hibátlanul működött.
Annak valószínűsége, hogy az informatikai rendszer helyesen működik a t időpontban.
Annak valószínűsége, hogy az informatikai rendszer helyesen vagy hibásan működik a t időpontban,
de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem
befolyásolja károsan más rendszerek működését.
106
Mi a karbantarthatóság?
Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt.
Annak feltételes valószínűsége, hogy egy informatikai rendszer hibátlanul működik a [t0, t]
időintervallumban, feltéve, hogy a t0 <= t időpontban hibátlanul működött.
Annak valószínűsége, hogy az informatikai rendszer helyesen működik a t időpontban.
Annak valószínűsége, hogy az informatikai rendszer helyesen vagy hibásan működik a t időpontban,
de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem
befolyásolja károsan más rendszerek működését.
Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt.
107
Melyik állítás igaz a megbízhatóság esetén?
Annak a valószínűségét fejezi ki, hogy a rendszer a [t0, t] intervallumban végig hibátlanul működik,
feltéve, hogy t0-ban hibátlanul működött.
Azt fejezi ki, hogy a [t0, t] intervallumban milyen valószínűséggel működik a rendszer, feltéve, hogy
t0-ban hibátlanul működött.
Megadja, hogy egy t időpillanatban milyen valószínűséggel működik hibátlanul a rendszer.
Megadja, hogy egy t időpillanatban milyen valószínűséggel működőképes a rendszer.
Annak a valószínűségét fejezi ki, hogy a rendszer a [t0, t] intervallumban végig hibátlanul működik,
feltéve, hogy t0-ban hibátlanul működött.
108
Ha egy rendszer megbízható, akkor hibatűrő is?
Nem, a hibatűrés javítja a megbízhatóságot, de ettől még nem biztos, hogy magas lesz a
megbízhatóság.
Igen, a megbízhatóság garantálja, hogy a rendszer nagy valószínűséggel hibátlanul működik.
Igen, a két fogalom ekvivalens.
Nem, a megbízhatóság azt garantálja, hogy valamilyen valószínűséggel nem fordul elő hiba, de a
hibatűrés a hibák teljes kizárását követeli meg.
Nem, a hibatűrés javítja a megbízhatóságot, de ettől még nem biztos, hogy magas lesz a
megbízhatóság.
109
Mi a különbség a megbízhatóság és a rendelkezésre állás között?
A megbízhatóság és a rendelkezésre állás között az a különbség, hogy az előbbi a t időpontig tartó
folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a t időpontban legyen a működés
helyes.
A rendelkezésre állás értéke ott lehet fontos, ahol a rendszert nem állandóan használják egy
feladatra, míg a megbízhatóságot elsősorban olyan rendszerek jellemzésére használják, ahol egy
rövid időre sincs megengedve a hibás működés.
A rendelkezésre állás és a megbízhatóság között az a különbség, hogy az előbbi a t időpontig tartó
folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a t időpontban legyen a működés
helyes.
A megbízhatóság értéke ott lehet fontos, ahol a rendszert nem állandóan használják egy feladatra,
míg a rendelkezésre állást elsősorban olyan rendszerek jellemzésére használják, ahol egy rövid időre
sincs megengedve a hibás működés.
A megbízhatóság és a rendelkezésre állás között az a különbség, hogy az előbbi a t időpontig tartó
folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a t időpontban legyen a működés
helyes.
A rendelkezésre állás értéke ott lehet fontos, ahol a rendszert nem állandóan használják egy
feladatra, míg a megbízhatóságot elsősorban olyan rendszerek jellemzésére használják, ahol egy
rövid időre sincs megengedve a hibás működés.
110
Mit jelent az A(t) >= 0,4 ?
Az informatikai rendszer a t időpontban legalább 0,4 valószínűséggel helyesen fog működik.
Az informatikai rendszer t idő alatt legalább 0,4 valószínűséggel újra üzemképes állapotba hozható.
Az informatikai rendszer a t időpontban legalább 0,4 valószínűséggel biztonságosan fog működni.
Az informatikai rendszer a t időpontig legalább 0,4 valószínűséggel megbízhatóan fog működik.
Az informatikai rendszer a t időpontban legalább 0,4 valószínűséggel helyesen fog működik.
111
Mit jelent az S(t) >= 0,7 ?
Az informatikai rendszer a t időpontban legalább 0,7 valószínűséggel biztonságosan fog működni.
Az informatikai rendszer a t időpontban legalább 0,7 valószínűséggel helyesen fog működik.
Az informatikai rendszer t idő alatt legalább 0,7 valószínűséggel újra üzemképes állapotba hozható.
Az informatikai rendszer a t időpontig legalább 0,7 valószínűséggel megbízhatóan fog működik.
Az informatikai rendszer a t időpontban legalább 0,7 valószínűséggel biztonságosan fog működni.
112
Mit jelent az M(t) >= 0,9 ?
Az informatikai rendszer t idő alatt legalább 0,9 valószínűséggel újra üzemképes állapotba hozható.
Az informatikai rendszer a t időpontban legalább 0,9 valószínűséggel biztonságosan fog működni.
Az informatikai rendszer a t időpontban legalább 0,9 valószínűséggel helyesen fog működik.
Az informatikai rendszer a t időpontig legalább 0,9 valószínűséggel megbízhatóan fog működik.
Az informatikai rendszer t idő alatt legalább 0,9 valószínűséggel újra üzemképes állapotba hozható.
113
Mely állítások igazak a BIST esetén?
A built-in self-testing rövidítése.
Az M(t) értékének magas szinten tartására használják.
Az R(t) értékének magas szinten tartására használják.
Arra szolgál, hogy egy informatikai rendszer könnyen tesztelhető legyen.
Az S(t) értékének magas szinten tartására használják.
A built-in self-testing rövidítése.
Az M(t) értékének magas szinten tartására használják.
114
Mi a verifikáció?
Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e
mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy
előállítási folyamatában.
Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e
mindazokat a felhasználói elvárásokat, amelyeket egy előző fázisban specifikáltak a szoftver
fejlesztési vagy előállítási folyamatában.
A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból
megfelel-e a felhasználói követelményeknek.
A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból
megfelel-e a specifikációban lefektetett követelményeknek.
Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e
mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy
előállítási folyamatában.
115
Mi a validáció?
A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból
megfelel-e a felhasználói követelményeknek.
A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból
megfelel-e a specifikációban lefektetett követelményeknek.
Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e
mindazokat a felhasználói elvárásokat, amelyeket egy előző fázisban specifikáltak a szoftver
fejlesztési vagy előállítási folyamatában.
Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e
mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy
előállítási folyamatában.
A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból
megfelel-e a felhasználói követelményeknek.
116
Ha tökéletesen végrehajtjuk a verifikációs folyamatot, akkor az garantálja a végtermék
tökéletes felhasználhatóságát?
Nem. Amit garantálni lehet, az a kiindulási specifikációval való ekvivalencia teljesülése.
Nem. Ha specifikálásban történt hiányosság vagy tévedés, a végtermék nem fog minden tekintetben
megfelelni a felhasználási követelményeknek.
Nem. A verifikációs folyamat tökéletes végrehajtása csak elméleti szinten lehetséges.
Igen. A verifikáció során mindvégig az előzetesen lefektetett felhasználói követelményekhez kell
igazodni.
Igen. A verifikálásra csak a validálás után kerülhet sor, ami garantálja a tökéletes
felhasználhatóságot.
Nem. Amit garantálni lehet, az a kiindulási specifikációval való ekvivalencia teljesülése.
Nem. Ha specifikálásban történt hiányosság vagy tévedés, a végtermék nem fog minden tekintetben
megfelelni a felhasználási követelményeknek.
117
Biztonságkritikus rendszer esetén mit kell igazolni a validáció során?
A funkcionális megfelelőséget.
A teljesítményben való megfelelőséget.
A biztonsági követelmények teljesülését.
A felhasználói követelményeknek való megfelelőséget.
A biztonsági előírásoknak való megfelelőséget.
A funkcionális megfelelőséget.
A teljesítményben való megfelelőséget.
A biztonsági követelmények teljesülését.
118
Az alábbiak közül melyik igaz?
A verifikáció arra ad választ, hogy a termék előállítása helyesen történt-e.
A validáció arra ad választ, hogy a helyes terméket állítottuk-e elő.
A validáció arra ad választ, hogy a termék előállítása helyesen történt-e.
A verifikáció arra ad választ, hogy a helyes terméket állítottuk-e elő.
A verifikáció arra ad választ, hogy a termék előállítása helyesen történt-e.
A validáció arra ad választ, hogy a helyes terméket állítottuk-e elő.
119
Előfordulhat-e, hogy nincs szükség a validációs vagy a verifikációs folyamatra?
Igen. Bizonyos esetekben, ha a kiindulási specifikációban nincsen semmilyen hiányosság, akkor nincs
szükség a validációra.
Igen. Ha jól validált a rendszer, akkor nincs szükség a verifikációs folyamatra.
Igen. Bizonyos fejlesztési modellek esetén elhagyható a validációs folyamat.
Nem. A verifikációt és a validációt minden esetben el kell végezni.
Nem. Minden szoftver esetén szükség van verifikálásra, melynek része a validációs folyamat.
Igen. Bizonyos esetekben, ha a kiindulási specifikációban nincsen semmilyen hiányosság, akkor nincs
szükség a validációra.
120
Mit fejez ki a V modell lefelé haladó ága?
A tervezési és létrehozási folyamatot.
A specifikációs és architektúrális folyamatot.
A teszttervezési és implementációs folyamatot.
A tesztelési és ellenőrzési folyamatot.
A tervezési és létrehozási folyamatot.
121
Mit fejez ki a V modell felfelé haladó ága?
A tesztelési és ellenőrzési folyamatot.
A tervezési és létrehozási folyamatot.
A specifikációs és architektúrális folyamatot.
A teszttervezési és implementációs folyamatot.
A tesztelési és ellenőrzési folyamatot.
122
Az alábbiak közül melyek a V modell életciklusának állomásai?
Követelmények specifikálása
Hazárd- és kockázatanalízás
Rendszer specifikálás
Felhasználói igények felmérése
Szoftver specifikálás
Követelmények specifikálása
Hazárd- és kockázatanalízás
Rendszer specifikálás
123
Az alábbiak közül melyek a V modell életciklusának állomásai?
Architektúra tervezés
Modul tervezés
Modulok előállítása és tesztelése
Inkrementum kifejlesztése
Specifikációnak való megfelelés vizsgálata
Architektúra tervezés
Modul tervezés
Modulok előállítása és tesztelése
124
Az alábbiak közül melyek a V modell életciklusának állomásai?
Rendszer integrálása és tesztelése
Rendszer verifikálása
Rendszer validálása
Inkrementumok tesztelése és integrálása
Rendszer architektúra tesztelése
Rendszer integrálása és tesztelése
Rendszer verifikálása
Rendszer validálása
125
Mi a V modell életciklusának befejező állomásai?
Bizonylatolás, majd a rendszer üzemeltetése
Rendszer verifikálása, majd validálása
A felhasználók oktatása, végül a rendszer üzemeltetése
Rendszer integrálása és tesztelése, végül a rendszer üzemeltetése
Bizonylatolás, majd a rendszer üzemeltetése
126
V modell esetén mely fázis eredményeként áll elő a biztonsági követelmények
dokumentációja?
Hazárdok és kockázatok elemzése
Követelmények specifikálása
Architekturális tervezés
A teljes rendszer-specifikáció
A teljes rendszer validálása
Hazárdok és kockázatok elemzése
127
V modell esetén mely fázis eredményeként állnak elő a hardver és szoftver
tervdokumentációk?
Architekturális tervezés
A teljes rendszer-specifikáció
Követelmények specifikálása
Modulokra bontás
A teljes rendszer verifikálása
Architekturális tervezés
128
V modell esetén az üzemeltetés és karbantartás fázisnak mi a bemeneti dokumentációja?
A biztonsági követelmények dokumentációja
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A rendszer terve, és a teljes rendszer-specifikáció
A modulok terve, és a teljes rendszer terve
A biztonsági követelmények dokumentációja
129
V modell esetén a bizonylatolás fázisnak mi a bemeneti dokumentációja?
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A biztonsági követelmények dokumentációja
A modulok terve, és a teljes rendszer terve
A teljes rendszer-specifikáció
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
130
V modell esetén a teljes rendszer validálása fázisnak mi a bemeneti dokumentációja?
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A biztonsági követelmények dokumentációja
A modulok terve, és a teljes rendszer terve
A rendszer terve, és a teljes rendszer-specifikáció
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
131
V modell esetén a teljes rendszer verifikálása fázisnak mi a bemeneti dokumentációja?
A rendszer terve, és a teljes rendszer-specifikáció
A biztonsági követelmények dokumentációja
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A modulok terve, és a teljes rendszer terve
A rendszer terve, és a teljes rendszer-specifikáció
132
V modell esetén a szoftver-modulok összeintegrálása fázisnak mi a bemeneti
dokumentációja?
A modulok terve, és a teljes rendszer terve
A biztonsági követelmények dokumentációja
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A rendszer terve, és a teljes rendszer-specifikáció
A modulok terve, és a teljes rendszer terve
133
V modell esetén a modulok elkészítése és tesztelése fázisnak mi a bemeneti
dokumentációja?
A modulok terve
A modulok terve, és a teljes rendszer terve
A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció
A biztonsági követelmények dokumentációja
A modulok terve
134
Mi igaz az inkrementális tesztelésre?
Egy kiindulási, minimális számú modulhoz egymás után illesztjük a bővítésként szolgáló modulokat.
Minden egyes bővítés után külön teszteljük az addig összeállt komplexumot.
Az újabb hibák egy-egy bővítés során léphetnek be nagy valószínűséggel.
A szoftver moduljait külön-külön teszteljük, majd a már verifikált alegységekből építjük fel a szoftver
komplexumot.
Egyszerű a hibajavítás, mert a bővítés során megjelenő hibák az újonnan beépített modulban
keresendők.
A tesztesetek halmazát inkrementálisan növeljük a tesztelés során.
Egy kiindulási, minimális számú modulhoz egymás után illesztjük a bővítésként szolgáló modulokat.
Minden egyes bővítés után külön teszteljük az addig összeállt komplexumot.
Az újabb hibák egy-egy bővítés során léphetnek be nagy valószínűséggel.
135
Mi igaz a big bang tesztelésre?
Az összes modult egyszerre rakjuk össze.
Azon a feltevésen alapul, hogy az előzetesen már letesztelt modulok együtt is jól fognak működni.
Több menetben hajtjuk végre a tesztelést.
Hibák megtalálása egyszerűbb, mint az inkrementális tesztelés esetén.
Olyan rendszerek esetén használjuk, ami nem igényli, hogy több modulra bontsuk szét.
Az összes modult egyszerre rakjuk össze.
Azon a feltevésen alapul, hogy az előzetesen már letesztelt modulok együtt is jól fognak működni.
136
V modell esetén mi történik az architekturális tervezés fázisban?
El kell dönteni, hogy mely funkciók legyenek megvalósítva hardver, és melyek szoftver által.
Elő kell állítani a hardver és szoftver rendszerterveket.
El kell dönteni, hogy a szoftver rendszert milyen funkciókra bontjuk fel és azok milyen környezetben
kerülnek megvalósításra.
Elő kell állítani a szoftver modulok tervdokumentációját.
El kell dönteni, hogy mely funkciók legyenek megvalósítva hardver, és melyek szoftver által.
Elő kell állítani a hardver és szoftver rendszerterveket.
137
Mi a HW-SW co-design?
Ebben a megközelítésben a tervezési folyamatnak csak egy későbbi szakaszában dől el a HW-SWmegosztás.
A hardver és szoftver fejlesztés szétválasztására ad irányelveket.
Ebben a megközelítésben mindvégig egységes alapokon történik a hardver és szoftver tervezés.
Egy rendszerfejlesztési életciklus modellt definiál.
Ebben a megközelítésben a tervezési folyamatnak csak egy későbbi szakaszában dől el a HW-SWmegosztás.
138
Mi a hazárd?
Olyan helyzet, amely valóságos vagy lehetséges veszélyt jelent az emberek vagy a környezet
számára.
Egy kockázathoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki,
hogy milyen valószínűségű veszélyes következményei lehetnek egy kockázatnak.
A szoftver vagy hardver rendszer olyan komponense, mely veszély és hiba forrása lehet.
Olyan szituáció, mely gazdasági, környezeti, emberi károkat okozhat.
Egyik sem.
Olyan helyzet, amely valóságos vagy lehetséges veszélyt jelent az emberek vagy a környezet
számára.
139
Mi a kockázat?
Egy hazárdhoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki,
hogy milyen valószínűségű veszélyes következményei lehetnek egy hazárdnak.
Olyan helyzet, amely valóságos vagy lehetséges veszélyt jelent az emberek vagy a környezet
számára.
Olyan szituáció, mely gazdasági, környezeti, emberi károkat okozhat.
A szoftver vagy hardver rendszer egy komponenséhez köthető valószínűségi alapú hibaforrás.
Egyik sem.
Egy hazárdhoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki,
hogy milyen valószínűségű veszélyes következményei lehetnek egy hazárdnak.
140
Mit nevezünk mérföldkőnek?
Egy kiemelt teljesítési időpont egy projekt menetében.
Az életciklus modellek egyes állomásait nevezzük mérföldkőnek.
A mérföldkő a projektek kezdeti fázisára utal.
Mérföldkő egy jól meghatározott tevékenység egy projekt menetében.
Egyik sem.
Egy kiemelt teljesítési időpont egy projekt menetében.
141
Fejlesztési projekt esetén mit jelent a függőség?
Egy mérföldkőtől kiinduló tevékenységek csak akkor kezdődhetnek el, ha a mérföldkőbe befutó
tevékenységek már befejeződtek.
A szoftverrendszer egyes moduljai közti összefüggésre és kommunikációra utal.
Meghatározza, hogy egy mérföldkő mikortól veheti kezdetét és milyen tevékenységektől függ.
Megadja, hogy a szoftverrendszer moduljainak integrálása során mely modulokat és milyen
sorrendben építsünk hozzá a rendszerhez.
Egy mérföldkőtől kiinduló tevékenységek csak akkor kezdődhetnek el, ha a mérföldkőbe befutó
tevékenységek már befejeződtek.
142
Hogyan ábrázoljuk a mérföldköveket?
Lekerekített sarkú téglalap
Lekerekített sarkú négyzet
Ellipszis
Téglalap
Négyzet
Lekerekített sarkú téglalap
143
Mire szolgál a tevékenységek és a mérföldkövek grafikus ábrázolása?
Időbeli összefüggések, időbeli kapcsolatok leírására.
A rendszer modulok összeintegrálásának menetét határozza meg.
A különböző életciklus modellek grafikus ábrázolására.
Meghatározza a tevékenységek végrehajtásának sorrendjét.
Időbeli összefüggések, időbeli kapcsolatok leírására.
144
Mi igaz az alábbi jelölés esetén?
T3, T6 (M3)
Az M3 mérföldkő teljesüléséhez T3 és T6 tevékenységek teljesítése szükséges.
Az M3 mérföldkőből kiinduló tevékenységekhez T6 teljesülése szükséges.
Az M3 mérföldkőből kiinduló tevékenységekhez T3 és T6 tevékenységek teljesülése szükséges.
T3 független tevékenység. T6 tevékenység M3 mérföldkő teljesülésétől függ.
Az M3 mérföldkő teljesüléséhez T3 és T6 tevékenységek teljesítése szükséges.
Az M3 mérföldkőből kiinduló tevékenységekhez T6 teljesülése szükséges.
Az M3 mérföldkőből kiinduló tevékenységekhez T3 és T6 tevékenységek teljesülése szükséges.
145
Mi igaz az ütemezési terv esetén?
Felsoroljuk a tevékenységeket, meghatározzuk mindegyiknek az időtartamát.
Megadjuk a mérföldköveket.
Megadjuk a tevékenységek összefüggését.
Grafikusan ábrázolhatjuk az ütemezési gráf segítségével.
Megadja, hogy milyen modulokból épül fel a szoftver rendszer.
Felsoroljuk a tevékenységeket, meghatározzuk mindegyiknek az időtartamát.
Megadjuk a mérföldköveket.
Megadjuk a tevékenységek összefüggését.
146
Mivel ábrázolhatjuk grafikusan az ütemezési tervet?
Tevékenységi diagram
Tevékenységi hálózat
Tevékenységi gráf
Ütemezési gráf
Egyik sem
Tevékenységi diagram
Tevékenységi hálózat
Tevékenységi gráf
147
Mi igaz a projekt-ütemezési táblázat esetén?
Tevékenységenként tartalmazza a tevékenységhez szükséges időt.
Tevékenységenként tartalmazza a függőségeket, mely megadja a tevékenység megkezdéséhez
szükséges mérföldkövet és a mérföldkő eléréséhez szükséges tevékenységeket.
Mérföldkövenként tartalmazza a mérföldkő eléréséhez szükséges időt.
Mérföldkövenként tartalmazza a mérföldkő eléréséhez szükséges tevékenységeket.
Megadja a projekt tevékenységeinek időrendi lefutását.
Tevékenységenként tartalmazza a tevékenységhez szükséges időt.
Tevékenységenként tartalmazza a függőségeket, mely megadja a tevékenység megkezdéséhez
szükséges mérföldkövet és a mérföldkő eléréséhez szükséges tevékenységeket.
148
Mit nevezünk kritikus útnak?
Az egymás után elvégzendő tevékenységek azon sorozata, amely meghatározza a projekt teljes
időtartamát.
Azon tevékenységek sorozata, melyek biztonsági szempontból kiemelt hangsúlyt kapnak a fejlesztés
során.
Időrendben elvégzendő tevékenységek olyan sorozata, melyek összideje a projekt teljesítéséhez
szükséges minimális időt definiálják.
A fejlesztés azon tevékenységeinek halmazát, melyek nagymértékben befolyásolják a projekt
befejezéséhez szükséges időt.
Az egymás után elvégzendő tevékenységek azon sorozata, amely meghatározza a projekt teljes
időtartamát.
149
Mi igaz az alábbi kifejezés esetén?
CP = T2 + T4 + T7 = 5 + 12 + 9 = 26
A projektben három kritikus tevékenység található.
A kritikus út hossza 26 időegység.
A projekt teljes időtartama 26 időegység.
A három kritikus tevékenység időtartama 26 időegység.
A projektben három tevékenység található.
A projektben három kritikus tevékenység található.
A kritikus út hossza 26 időegység.
A projekt teljes időtartama 26 időegység.
A három kritikus tevékenység időtartama 26 időegység.
150
Mit nevezünk pszeudó-mérföldkőnek?
Tevékenységi diagramon a START állapotot.
Tevékenységi diagramon az END állapotot.
Tevékenységi diagramon a nem valódi mérföldköveket.
Tevékenységi diagramon azokat az állapotokat, melyek a fejlesztés sikeressége szempontjából
minimális kockázatot jelentenek.
Tevékenységi diagram tervezése során olyan mérföldkövek, melyek a végleges diagramon nem
szerepelnek, csak a tervezést segítik.
Tevékenységi diagramon az egyes tevékenységeket.
Tevékenységi diagramon a START állapotot.
Tevékenységi diagramon az END állapotot.
Tevékenységi diagramon a nem valódi mérföldköveket.
151
Mi igaz a Gantt-diagram esetén?
Az egyes tevékenységeket egy vízszintes szakaszon ábrázoljuk.
A különböző szakaszok úgy vannak eltolva egymáshoz képest, ahogyan a projektben tolódnak el az
időben.
A projekt ütemezési tervének grafikus megjelenésére szolgál.
Egy tevékenység jele egy téglalap.
Az egymás után követő tevékenységeket az őket ábrázoló téglalapok összekötésével fejezzük ki.
Az egyes tevékenységeket egy vízszintes szakaszon ábrázoljuk.
A különböző szakaszok úgy vannak eltolva egymáshoz képest, ahogyan a projektben tolódnak el az
időben.
A projekt ütemezési tervének grafikus megjelenésére szolgál.
152
A tevékenységi diagram és a Gantt-diagram információ hordozás szempontjából egymással
ekvivalens?
Igen, mindkettő segítségével az ütemezési tervet ábrázolhatjuk.
Igen, mindkettő segítségével a projekt életciklus modelljét ábrázolhatjuk.
Igen, a két megnevezés ugyanarra a jelölésmódra utal.
Nem, a Gantt-diagram nem ábrázolja a mérföldköveket, szemben az ütemezési diagrammal.
Nem, az ütemezési diagram nem ábrázolja a párhuzamosan végzendő tevékenységeket, szemben a
Gantt-diagrammal.
Igen, mindkettő segítségével az ütemezési tervet ábrázolhatjuk.
153
Mi igaz a tartalékidő esetén?
Angol megnevezése a slack time.
Tartalék időnek nevezzük, amikor egy tevékenység befejezéséhez a szükséges időn felül további
korlátozott idő is rendelkezésre áll úgy, hogy a projekt befejezési idejét nem befolyásolja.
A tartalékidőt a Gantt-diagramon grafikusan ábrázoljuk.
Angol megnevezése a spare time.
A tartalékidőt a tevékenység diagramon grafikusan ábrázoljuk.
Tartalékidőnek nevezzük azt, amikor egy tevékenységet az előzetes tervekben megszabott időkorlát
alatt sikerül teljesíteni.
Angol megnevezése a slack time.
Tartalék időnek nevezzük, amikor egy tevékenység befejezéséhez a szükséges időn felül további
korlátozott idő is rendelkezésre áll úgy, hogy a projekt befejezési idejét nem befolyásolja.
A tartalékidőt a Gantt-diagramon grafikusan ábrázoljuk.
