@@ 5. sor: / 5. sor: @@
 ==UML/CLASS==
-* Late binding: probléma: több ugyanolyan nevű függvény → objektumhoz kötődik runtime a függvény!
+* '''Late binding''': probléma: több ugyanolyan nevű függvény → objektumhoz kötődik runtime a függvény!
 * UML diagram elemek: vizuális relációk:
 ** kapcsolat (connection)
 ** tartalmazás (containment)
 ** vizuális kapcsolás (közelség, visual attachment)
-* UML 3 kiterjesztő mechanizmus
+* UML 2 kiterjesztő mechanizmus
 ** korlátozás (constraints)
 ** sztereotípia (speciális név-érték/tagged value/ pár (bool))
@@ 24. sor: / 24. sor: @@
 * Class metódus property(tulajdonság) módosítók:
 ** query, redefines, ordered, unique, oper-constraint(kényszer)
-* Operációk konkurenciája:
+* Operációk konkurenciája (konkurenciaszemantikák, concurrency semantics):
-** szekvenciális(sequential) - elméletileg nem lehet, hogy más hívja meg az operációt
+** '''szekvenciális/sorrendi (sequential)''' - elméletileg nem lehet, hogy más hívja meg az operációt, nem fordulhat elő konkurencia (''"callers must coordinate outside the object so that only one flow is in the object at a time."'')
-** guarded(őrzött) - jöhet ilyen hívás, de megoldott a kezelése
+** '''őrzött (guarded)''' - jöhet ilyen hívás, előfordulhat konkurencia, de megoldott a kezelése; pl. ha befejezte a működését, csak akkor jöhet a következő (''"multiple calls from concurrent threads may occur simultaneously to one instance, but only one is allowed to commence. Others are blocked."'')
-** konkurens(concurrent) - bejöhet hívás, azonnal lekezelődik, nem jó
+** '''konkurens (concurrent)''' - bejöhet hívás, azonnal lekezelődik, nem jó, mert félbeszakíthat folyamatokat (''"multiple calls from concurrent threads may occur simultaneously to one object on any concurrent operation, and all may proceed concurrently with correct semantics"'')
-* Active Object: saját szála van az objektumnak.
+* '''Active Object''': saját szála van az objektumnak.
-* Mi az a classifier?
+* Mi az a '''classifier'''?
 ** osztályszerű: osztálynak kinéző dolgok felett metaosztály(class, interface, datatype..)
 * UML diagramon mi a role, asszociáció?
 ** CLASSIFIER!
-* UML class diagramon az asszociációnál mi a “/”?
+* UML class diagramon az '''asszociáció'''nál mi a "'''/'''"?
 ** AZ ASSZOCIÁCIÓ LE VAN SZÁRMAZTATVA!
-* Mit jelent, ha egy pont van az asszociáció végen?
+* Mit jelent, ha egy '''pont''' van az '''asszociáció valamelyik végén'''?
 ** OWNERSHIP! Ki birtokolja az osztályt.
-* Hogyan lehet UML class-szal ábrázolni, hogy valami tartalmaz valamit?
+* Hogyan lehet UML class-szal ábrázolni, hogy valami '''tartalmaz''' valamit?
 ** karika, benne plus sign, inner class, tagváltozó, aggregáció
@@ 73. sor: / 73. sor: @@
 ==UML/Szekvencia, Kommunikáció, Interaction Overview==
+* '''Interakció diagramon''' mik a '''felelősségek'''?
+** '''Doing''' (csinálni valamit): valamit önmagában, más objektumok tevékenységeinek irányítása/koordinálása, más objektumokban művelet kezdeményezése
+** '''Knowing about''' (valamiről tudni): private encapsulated data, kapcsolódó objektumok, dolgok amiket ki tud számolni
 * Mi a különbség üzenet és jel között interakció-diagrammokon?
 ** üzenettel operációt hajtatunk végre, jellel állapotváltozást jelzünk.
@@ 92. sor: / 95. sor: @@
 * Állapotdiagramon milyen kompozit állapotokat ismer?
-** TODO
+** simple (1 régió), orthogonal (1-nél több régió)
-* Mik az állapotdiagram elemei?
+* Mik az Activity diagram elemei?
 ** alaktivitások (procedúra), döntések, fork és join, úszósávok, object-action flow
+* Mik az állapotgép diagram elemei?
+** entry/exit-action, állapotátmenet (esemény(arg?)/tranzakció), deep/shallow-history indicator, fork-join
 * Mi az Eclipse Modeling Framework(EMF)?
 ** Modellező eszköz (pl. UML-hez hasonló (MOF) diagramokat lehet csinálni), kódgeneráló is!
@@ 106. sor: / 111. sor: @@
 * Class nem lehet static, csak INNER CLASS!!!!!!!!!
 * Array length-je megmondja, mekkora a MÉRETE! Nem azt, hogy mennyi értelmes adat van benne!
-* Nézd meg a Strin == és equalsTo miket csinál!
+* Nézd meg a String == és equalsTo miket csinál!
 ** pl null, stb..
 * Mit vár a Thread.sleep()?
@@ 126. sor: / 131. sor: @@
 ** Daemon és nem daemon (daemon gyakorlatilag háttérben futó szál)
 * Milyen synchronized-ok vannak?
-** blokk ... Object o = new Object();
+** blokk: <code>synchronized (o) { ... }</code> ahol <code>o</code> valami Object (vagy abból leszármazott, int/long/double/etc nem)
-** .. function...{ synchronized(o){..}}, METÓDUS: public synchronized int valami(){} . Mindkettőnél egyszerre csak egy szál tartózkodhat az adott blokkban/függvényben
+** method: <code>public synchronized void foo() { ... }</code>
+** Egyszerre csak 1 szál tartózkodhat az adott objektum (methodnál this) synchronized blokkjában/methodjában, a többi blokkol addig
 * Mi az az atomi művelet?
 ** Guarded :) ha valaki módosítja, akkor más metódus nem lát inkonzisztens állapotot. primitív adattípusokra, kivéve long és double
@@ 135. sor: / 141. sor: @@
 ** TODO
 * Mikor mit jelent a final?
-** osztály előtt: nem lehet leszármaztatni + egyszer lehet példányosítani!;
+** osztály előtt: nem lehet leszármaztatni
 ** metódus előtt: nem lehet felüldefiniálni leszármazottban;
-** változó előtt: konstans
+** változó előtt: nem lehet neki értéket adni (csak <code>public final int i = 7;</code> vagy konstruktorban)
 * Mikor mit jelent az abstract?
-** Osztály előtt: nem lehet példányosítani, van benne legalább 1 olyan metódus, amely abstract (nem implementált), leszármazottnak implementálni kell (vagy ő is abstract lesz).
+** Osztály előtt: nem lehet példányosítani, NEM KÖTELEZŐ, HOGY LEGYEN BENNE ABSZTRAKT METÓDUS
+** Metódus előtt: leszármazottnak implementálni kell.
 * Mit jelent, hogy a változó statikus/dinamikus része?
 ** List x = new ArrayList();
@@ 147. sor: / 154. sor: @@
 ** NEM!!!!!
 * Mit nevezünk kiterjesztésnek JAVA nyelvben?
-** ha több interfészt valósít meg egy osztály
+** ha egy vagy több interfészt valósít meg egy osztály
 === JUnit: ===
@@ 214. sor: / 221. sor: @@
 ==RUP==
-* Milyen workflow-hoz milyen modell tartozik?
+* Milyen '''workflow-hoz''' milyen '''modell''' tartozik?
 ** Követelmények: Use Case Model,
 ** Analízis: Analízis model,
@@ 221. sor: / 228. sor: @@
 ** Deployment: Deployment diagram
 * Az egyes modellek milyen UML diagrammokat tartalmaznak?
-** Use Case: {Use Case,Sequence};
+** Use Case: {Use Case, Sequence};
 ** Analízis: {static structure diagram, sequence};
-** Tervezési modell: {static structure, kommunikációs, állapotdiagram,activity};
+** Tervezési modell: {static structure, kommunikációs, állapotdiagram, activity};
-** Implementációs modell: {komponens,szekvencia};
+** Implementációs modell: {komponens, szekvencia};
 ** Deployment: {Deployment, sequence}
 * [[File:Szofttech_Vizsga_Lehetséges_vizsgakérdések_02.RUP_Structuring the process.png|400px]]
-* Milyen típusú use case-ek vannak?
+* '''Milyen típusú use case-ek''' vannak?
 ** Event based, actor based
-* Milyen dimenziói vannak a use case formátumoknak?
+* Milyen '''dimenziói''' vannak a '''use case-formátumoknak'''?
-** (1) Leírás részletezettsége(magas szintű/kiterjesztett)
+** (1) Leírás részletezettsége (magas szintű/kiterjesztett)
 ** (2) Fogalmi/valóságos
-** (3)Prioritás(elsőrendű/másodrendű/opcionális)
+** (3) Prioritás (elsőrendű/másodrendű/opcionális)
+* Miben különbözik a magas szintű (high level) és a kiterjesztett (expanded) use-case ?
+** A leírás részletezettségében
+*** magas szintű: név, aktorok, cél, áttekintés, referencia
+*** kiterjesztett: eseményfolyam, elő- és utófeltételek, kiterjesztési pontok, relációk, aktivitás és use-case diagram, referenciák)
+* Miben különbözik a lényeges (essential) és a valóságos (real) use-case ?
+** A technológia függőségében
+*** lényeges: eszköz-, implementációfüggetlen
+*** valóságos: implementáció (ablakok, mezők, triggerek)
 * Hogyan rangsorolunk use case-eket (iterációknak)?
-** (1)időben kritikus
+** (1) időben kritikus
-** (2)kockázatosak
+** (2) kockázatosak
-** (3)alapvető kutatást igénylők
+** (3) alapvető kutatást igénylők
-** (4)alkalmazás szempontjából legfontosabbak
+** (4) alkalmazás szempontjából legfontosabbak
-** (5)üzleti élet szempontjából fontosak
+** (5) üzleti élet szempontjából fontosak
-* Fogalmi modellnél mi a térképész elv?
+* Fogalmi modellnél mi a '''térképész elv'''?
 ** Használjuk a területen alkalmazott neveket!
 ** ne kreáljunk olyan dolgokat, amik nincsenek ott!
-** Értelmetlen részleteket hagyjuk ki!
+** Lényegtelen részleteket hagyjuk ki!
-* Mik a mutátorok?
+* Mik a '''mutátorok'''?
-** Olyan objektumok, amelyek képesek megváltoztatni, hogy melyik osztályból származnak le.
+** típusok amik megváltoztathatják a típusukat vagy szerepüket
-* Interakció diagramon mik a felelősségek?
+* '''Interakció diagramon''' mik a '''felelősségek'''?
-** Doing: valamit kell tudni;
+** '''Doing''' (csinálni valamit): valamit önmagában, más objektumok tevékenységeinek irányítása/koordinálása, más objektumokban művelet kezdeményezése
-** Knowing: kiről mit tud
+** '''Knowing about''' (valamiről tudni): private encapsulated data, kapcsolódó objektumok, dolgok amiket ki tud számolni
 ==V&V==
-* Review definíciók? Review, Review item, Audit, Walkthrough(az anyag készítője bemutatja a munkáját(, Inspection(reviewereknek kiosztanak anyagot, ők jelentést tesznek róla, majd ezt egy bizottság megvitatja a szerző jelenlétében. pl egyetemi diplomavédés)
+* Review definíciók?
-* Kik a meeting szereplői? Koordinátor(felelős a meetingért), Lead reader(anyag működésével tisztában van), jegyzőkönyvvezető, megbízó képviselői
+** Review, Review item, Audit, Walkthrough (az anyag készítője bemutatja a munkáját, Inspection (reviewereknek kiosztanak anyagot, ők jelentést tesznek róla, majd ezt egy bizottság megvitatja a szerző jelenlétében. Pl. egyetemi diplomavédés)
-* Mit kell tenni, ha hibát találunk a meetingen? (1) kijelölni egy felelős személyt (2) meghatározni, mi a teendő (3) problémák osztályozása
+* Kik a meeting szereplői?
-* Hogyan lehet becsülni, hogy mennyi hiba van a programban? elrejtünk hibákat, mennyit találnak meg..
+** Koordinátor (felelős a meetingért),
-* Konformanciatesztelés vs hibadetektálás? 1.: a szoftvernek bizonyos feltételeknek kell eleget tennie, a 2-nél programo futása közben tesztelünk
+** Lead reader (anyag működésével tisztában van),
-* Mi az a Pareto-elv? 80-20 szabály: a programhibák 80%-ért a program 20%-a okolható
+** jegyzőkönyvvezető,
-* Integrációs tesztre milyen stratégiák vannak? top-down(GUI-menüt rakom először össze, a még nem ismert funkcióknak “not yet implemented” - ez a test stub),bottom-up(legozás)
+** megbízó képviselői
-* Funkcionalitás teszt esetei? funkcionális teszt, biztonsági teszt, mennyiségi teszt(hatalmas adattal elárasztás)
+* Mit kell tenni, ha hibát találunk a meetingen?
-* Megbízhatósági teszt esetei?integritási(kibírja-e hiba nélkül?), struktúra(ismerem a program belsejét, erre alapozva végzek idétlen teszteket), stressz
+** (1) kijelölni egy felelős személyt
-* Teljesítmény tesztek? benchmark(összehasonlítás referencia szoftverrel), contention(stressz teszt alfaja, több actor versenyez ugyanazokért az adatokért), load teszt(működési limit környékén működés), teljesítmény profil
+** (2) meghatározni, mi a teendő
-* Támogatottság teszt? hogyan konfigurálható/installálható
+** (3) problémák osztályozása
-* Teszt mértékek? követelmény-alapozott, kód-alapozott, hiba analízis
+* Hogyan lehet becsülni, hogy mennyi hiba van a programban?
-* Mi jellemző a teszt stratégiákra? Megmondja az általános megközelítést, milyen technikákat/eszközöket használunk, mi a teszt sikeressége, hogyan teszteljük a számunkra külső dolgokkal (teszt segédprogramok)
+** elrejtünk hibákat, mennyit találnak meg..
-* Milyen teszt eseteket ismer? White-box: minden lehetséges döntési ágon, minden lehetséges adattal végigmegyünk (gyakorlatilag biztosan lehetetlen), ismerjük a szoftver belső szerkezetét; Black-box test: !!ekvivalencia-osztályozás!!: tudunk azonosítani bizonyos tevékenységeket, boundary value(határérték) tesztelés: ekvivalencia osztály határok tesztelése, speciális érték tesztelés.
+* Konformanciatesztelés vs hibadetektálás?
+** Konformanciatesztelés: a szoftvernek bizonyos feltételeknek kell eleget tennie,
+** hibadetektálás: program futása közben tesztelünk
+* Mi az a Pareto-elv?
+** 80-20 szabály: a programhibák 80%-ért a program 20%-a okolható
+* Integrációs tesztre milyen stratégiák vannak?
+** top-down (GUI-menüt rakom először össze, a még nem ismert funkcióknak "not yet implemented" - ez a test stub),
+** bottom-up (legózás)
+* Funkcionalitás teszt esetei?
+** funkcionális teszt,
+** biztonsági teszt,
+** mennyiségi teszt (hatalmas adattal elárasztás)
+* Megbízhatósági teszt esetei?
+** integritási (kibírja-e hiba nélkül?),
+** struktúra (ismerem a program belsejét, erre alapozva végzek idétlen teszteket),
+** stresszteszt
+* Teljesítménytesztek?
+** benchmark (összehasonlítás referenciaszoftverrel),
+** contention (stressz teszt alfaja, több actor versenyez ugyanazokért az adatokért),
+** load-teszt (működési limit környékén működés),
+** teljesítményprofil
+* Támogatottság-teszt?
+** hogyan konfigurálható/installálható
+* Tesztmértékek?
+** követelmény-alapozott,
+** kód-alapozott,
+** hibaanalízis
+* Mi jellemző a tesztstratégiákra?
+** Megmondja az általános megközelítést,
+** milyen technikákat/eszközöket használunk,
+** mi a teszt sikeressége,
+** hogyan teszteljük a számunkra külső dolgokkal (tesztsegédprogramok)
+* Milyen teszteseteket ismer?
+** White-box: minden lehetséges döntési ágon, minden lehetséges adattal végigmegyünk (gyakorlatilag biztosan lehetetlen), ismerjük a szoftver belső szerkezetét;
+** Black-box test: !!ekvivalencia-osztályozás!!: tudunk azonosítani bizonyos tevékenységeket,
+** boundary value(határérték) tesztelés: ekvivalencia osztály határok tesztelése,
+** speciálisérték-tesztelés.
 ==Design==
-* Informatikai szemléletben mi köré szoktunk absztrakciót húzni(absztrakció típusai)? funkcionalitás, adat, kontrol
+* Informatikai szemléletben mi köré szoktunk absztrakciót húzni(absztrakció típusai)?
-* Mi az, hogy afferens/efferens egy adatáramlás? Afferens: az adat a felfele halad(arra halad, amerre bonyolultabb/összetettebb problémák vannak, amelyből szétszedtem kisebb problémákra); efferens fordítva
+** funkcionalitás, adat, kontroll
-* Mi a fan-out/fan-in szám? Fan-out: egy modult hány részre szedem szét, fan-in: modult hányan hívnak fentről
+* Mi az, hogy afferens/efferens egy adatáramlás?
-* Mi a vezérlési/döntési hatáskör? Mi a döntési hasítás? vezérlési: maga a modul, és mindenki, aki alá tartozik; döntési: azon modulok, akiket érint az adott modul döntése. döntési hasítás: ha a döntési hatáskör nagyobb, mint a vezérlési
+** Afferens: az adat felfelé halad (arra halad, amerre bonyolultabb/összetettebb problémák vannak, amelyből szétszedtem kisebb problémákra);
-* Mik a dimenziói a csatolásnak? Mit kommunikálunk? Milyen nagy a kapcsolat? Mennyi ideig tart a kapcsolat?
+** efferens: fordítva
-* Mik a csatolás dimenziói? kapcsolat tárgya, kapcsolat mérete, kapcsolat ideje
+* Mi a fan-out/fan-in szám?
-* A kapcsolat tárgya alapján hogyan lehet csoportosítani a csatolásokat? laza csatolás(primitív adat/tömbje), stamp csatolás(összetette adatok, record, struct), control csatolás(vezérlést adunk át), közös adat(nem tudjuk, kinek a kezében van, bárki hozzáférhet), tartalmi jellegű csatolás(a másik programrészletet mint erőforrás kezelem -.-)
+** Fan-out: egy modult hány részre szedem szét,
-* Hogyan lehet osztályozni a csatolást az időtartam alapján? writing, compiling, linking, loading, running
+** fan-in: modult hányan hívnak fentről
-* Hogyan lehet a kohéziót osztályozni? /egyre gyengébb/ funkcionális(oszthatatlan), szekvenciális(több funkcionális egymás után), kommunikációs(egy adatszerkezeten műveleteket végzünk, a kohézió itt az, hogy egy adatszerkezeten dolgoznak), procedurális(printf: double és String is elfogad, de a két paraméternek nincs köze egymáshoz. typusfüggő switch), temporális(időbeliség tart össze), logikai, véletlenszerű
+* Mi a vezérlési/döntési hatáskör? / Mi a döntési hasítás?
-* Ha több helyről öröklünk, mi vonatkozik az invariánsokra? az invariáns a többszörös öröklésekből származó kondíciók ÉS kapcsolata
+** vezérlési: maga a modul, és mindenki, aki alá tartozik;
-* Mi a redeklarációs szabály? Az előfeltételnek a leszármazottban gyengébbnek(vagy egyenlőnek) kell lennie, az utófeltételnek erősebbnek(vagy egyenlőnek).
+** döntési: azon modulok, akiket érint az adott modul döntése.
+** döntési hasítás: ha a döntési hatáskör nagyobb, mint a vezérlési
+* Mik a dimenziói a csatolásnak?
+** Mit kommunikálunk? Milyen nagy a kapcsolat? Mennyi ideig tart a kapcsolat?
+* Mik a csatolás dimenziói?
+** kapcsolat tárgya, kapcsolat mérete, kapcsolat ideje
+* A kapcsolat tárgya alapján hogyan lehet csoportosítani a csatolásokat?
+** laza csatolás (primitív adat/tömbje),
+** stamp csatolás (összetett adatok, record, struct),
+** control csatolás (vezérlést adunk át),
+** közös adat (nem tudjuk, kinek a kezében van, bárki hozzáférhet),
+** tartalmi jellegű csatolás (a másik programrészletet, mint erőforrást kezelem -.-)
+* Hogyan lehet osztályozni a csatolást az időtartam alapján?
+** writing, compiling, linking, loading, running
+* Hogyan lehet a kohéziót osztályozni?
+** ↓ /egyre gyengébb/ funkcionális (oszthatatlan; pl. sqrt() függvény),
+** szekvenciális (több funkcionális egymás után),
+** kommunikációs (egy adatszerkezeten műveleteket végzünk, a kohézió itt az, hogy egy adatszerkezeten dolgoznak),
+** procedurális (printf: double és String is elfogad, de a két paraméternek nincs köze egymáshoz. típusfüggő switch),
+** temporális(időbeliség tart össze),
+** logikai,
+** véletlenszerű
+* Ha több helyről öröklünk, mi vonatkozik az invariánsokra?
+** az invariáns a többszörös öröklésekből származó kondíciók ÉS-kapcsolata
+* Mi a redeklarációs szabály?
+** Az előfeltételnek a leszármazottban gyengébbnek (vagy egyenlőnek) kell lennie, az utófeltételnek erősebbnek (vagy egyenlőnek).
 ==Design/Software architectures==
-* Milyen főbb kategóriáit ismeri a szoftver architektúrális mintáknak?
+* Milyen főbb kategóriáit ismeri a szoftverarchitekturális mintáknak?
-** Adatfolyam szerkezetek → Batch, Pipes and filters
+** Adatfolyam-szerkezetek → Batch, Pipes and filters
-** Call-and-return rendszerek → Main program és szubrutin, OO rendszerek, hierarchikusan rétegelt
+** Call-and-return-rendszerek → Main program és szubrutin, OO rendszerek, hierarchikusan rétegelt
 ** Adatközpontú rendszerek → adatbázisok, Hypertext rendszerek, Blackboards
 ** Virtuális gép → Interpreter, Rule-based system
 ** Független komponensek → Communicating processes, esemény-alapú rendszerek
-* Mi a BPEL? Milyen fajtái vannak? Business Process Execution Language → le lehet írni üzleti folyamatokat vele. 2 fajtája: orchestration & choreography. Orchestration: centralizált folyamatvégrehajtás, choreography: folyamatot küldhetek másnak, aki továbbküldheti stb..
+* Mi a BPEL? Milyen fajtái vannak?
+** Business Process Execution Language → le lehet írni üzleti folyamatokat vele.
+** 2 fajtája:
+*** orchestration & choreography.
+**** Orchestration (orkesztráció): centralizált folyamatvégrehajtás.  Egy központ ismeri a teljes folyamatot, az kér szolgáltatást az együttműködőktől, akik csak a saját dolgukat végzik.
+**** Choreography (koreográfia): folyamatot küldhetek másnak, aki továbbküldheti stb. a folyamat nincs központosítva, minden résztvevő a dolgát elvégezve az általa ismert következő résztvevő(ke)t aktivizálja.
 ==Agilis==
-* Mik a Scrum alappillérei? átláthatóság(business világ és fejlesztői világ között), folyamatos felülvizsgálat, Adaptáció(eltérést gyorsan fel kell számolni)
+* Mik a Scrum alappillérei?
-* mit jelent a grooming? a termék tulajdonságainak folyamatos finomítása
+** átláthatóság (business világ és fejlesztői világ között),
+** folyamatos felülvizsgálat,
+** Adaptáció (eltérést gyorsan fel kell számolni)
+* mit jelent a grooming?
+** a termék tulajdonságainak folyamatos finomítása
 * Milyen szerepek vannak a scrumban egy sprintben?
 ** pigs (életükkel fizetnek a projektért)
@@ 304. sor: / 389. sor: @@
 *** stakeholders (érdekeltek)
 *** managers
-* Milyen események vanna Scrumban? sprint tervezés, áttekintés, visszatekintés és napi scrum meeting
+* Milyen események vannak a Scrumban?
-* Milyen termékek vannak Scrumban? Product backlog(user story-k összegyűjtése/wishlist/ → product owner a felelős érte), sprint backlog(a product backlogból elfogadott kívánságok/user story-k), burndown chart(Y:work remaining, X: time; naponta megnézzük, mennyi munka van még hátra, ebből tudunk becsülni, mikor készül el/mikor lesz 0 a work remaining)
+** sprint tervezés, áttekintés, visszatekintés és napi Scrum-meeting
+* Milyen termékek vannak Scrumban?
+** Product backlog (user story-k összegyűjtése/wishlist/ → product owner a felelős érte),
+** sprint backlog (a product backlogból elfogadott kívánságok/user story-k),
+** burndown chart (Y:work remaining, X: time; naponta megnézzük, mennyi munka van még hátra, ebből tudunk becsülni, mikor készül el/mikor lesz 0 a work remaining)
 * Milyen elemei vannak egy XP projectnek?
 ** [[File:Szofttech_Vizsga_Lehetséges_vizsgakérdések_03.XP_project.png|400px]]
@@ 311. sor: / 400. sor: @@
 ==Management==
-* Milyen típusú projekt planek vannak? long term, short term
+* Milyen típusú projekt planek vannak?
-* Mi a projekt menedzsment feladata? felelősségvállalás, erőforrás újraosztása, ütemezés, követelményeken lazítani, oktatásra küldeni a munkatársakat
+** long term, short term
-* Milyen erőforrások vannak? emberek, szoftver, hardver
+* Mi a projektmenedzsment feladata?
-* Mit kell menedzselni? időt,információt,szervezet,minőség,pénz
+** felelősségvállalás, erőforrás újraosztása, ütemezés, követelményeken lazítani, oktatásra küldeni a munkatársakat
-* Hogyan kell ütemezni egy projektet? DIAGRAM → requirements, Identify activities, Identify dependencies...
+* Milyen erőforrások vannak?
-* Mik a kockázat menedzsment lépései? Kockzatok azonosítása, kockázatok elemzése, kockázattervezés, kockázatok monitorozása
+** emberek, szoftver, hardver
-* Milyen mérések/becslések vannak? → válasz:  a fejlesztéshez mennyi erőfeszítés kell?, mértékek(LOC-line of code,FPA-funkciónt elemzés), komplexitás(hogyan mérjük, hogy mennyire bonyolult valami?)
+* Mit kell menedzselni?
+** idő, információ, szervezet, minőség, pénz
+* Hogyan kell ütemezni egy projektet?
+** DIAGRAM → requirements, Identify activities, Identify dependencies...
+* Mik a kockázatmenedzsment lépései?
+** Kockzatok azonosítása, kockázatok elemzése, kockázattervezés, kockázatok monitorozása
+* Milyen mérések/becslések vannak?
+** a fejlesztéshez mennyi erőfeszítés kell?,
+** mértékek (LOC - Lines of Code, FPA - funkciópontelemzés),
+** komplexitás (hogyan mérjük, hogy mennyire bonyolult valami?)
 ==CM==
-* Mi a 3 nézete a CM-nek? Change Request Management: változások kezelés, Configuration Management: különböző dokumentumok/kódok egy programmá állnak össze, Mérések
+* Mi a 3 nézete a CM-nek?
-* Milyen elemeket kell azonosítani? configuration item, communication(email ..), dokumentáció, implementáció
+** Change Request Management: változások kezelése,
-* Miért felelős a Change Request Management? hogyan kezeljük a változásokat, Change Control Board-változás kezelő bizottság, defect management-mikor hogyan ki milyen prioritással kezeli a problémákat
+** Configuration Management: különböző dokumentumok/kódok egy programmá állnak össze,
-* Miért felelős a Build management? Milyen alapanyagokból hogyan rakjuk össze a programot
+** Mérések
-* Mi az a baseline? pillanatkép a projektről. Ha valami változtatás történik, azt deltának hívjuk.
+* Milyen elemeket kell azonosítani?
-* Release management definíciók? verzió: funcionálisan különböző, variáns: funkcionalitásban nem különbözik, release: verzió, amit kiad a team; revision: verzió+variáns
+** configuration item, communication (email ..), dokumentáció, implementáció
-* Mivel kell foglalkozni source szinten egy projekt életciklusában? Backup, change logs, együttműködés(több verzió egy source-ra), helyileg eltérő file-ok, branching
+* Miért felelős a Change Request Management?
-* Milyen delta kezeléseket ismer? reverse delta: a legújabb verzió van elmentve, a változások(delták) ehhez viszonyulnak; forward delta: az első verzió az alap, ehhez jönnek a delták(tehát a legújabb verzió sok-sok delta után derül ki, hogy micsoda.. nem praktikus, bár a commit-ok gyorsabbak lehetnek); skip-delta
+** hogyan kezeljük a változásokat,
-* Mi a szótára a VC-nek? working copy, repository, check-out: r → wc, check-in/commit: wc → r, update: wc szinkronizálása a repo-val
+** Change Control Board - változáskezelő bizottság,
-* Milyen metodikákat ismer konkurens hozzáféréshez? lock-modify-unlock, copy-modify-merge
+** defect management - mikor, hogyan, ki, milyen prioritással kezeli a problémákat
-* Mi az a branch? fa struktúrába szedett verziók változása az idő során. trunk: a fővonal, tag: pillanatkép
+* Miért felelős a Build management?
+** Milyen alapanyagokból hogyan rakjuk össze a programot
+* Mi az a baseline?
+** pillanatkép a projektről. Ha valami változtatás történik, azt deltának hívjuk.
+* Release management definíciók?
+** verzió: funcionálisan különböző,
+** variáns: funkcionalitásban nem különbözik,
+** release: verzió, amit kiad a team;
+** revision: verzió+variáns
+* Mivel kell foglalkozni source-szinten egy projekt életciklusában?
+** Backup, change logs, együttműködés (több verzió egy source-ra), helyileg eltérő file-ok, branching
+* Milyen delta-kezeléseket ismer?
+** reverse delta: a legújabb verzió van elmentve, a változások (delták) ehhez viszonyulnak;
+** forward delta: az első verzió az alap, ehhez jönnek a delták (tehát a legújabb verzió sok-sok delta után derül ki, hogy micsoda... nem praktikus, bár a commit-ok gyorsabbak lehetnek);
+** skip-delta
+* Mi a szótára a VC-nek? (Version Control)
+** working copy,
+** repository,
+** check-out: r → wc (kezelt elem kiemelése felhasználásra a közös tárból),
+** check-in/commit: wc → r (kezelt elem visszahelyezése a közös tárba),
+** update: wc szinkronizálása a repo-val
+* Milyen metodikákat ismer konkurens hozzáféréshez?
+** lock-modify-unlock, copy-modify-merge
+* Mi az a branch?
+** fastruktúrába szedett verziók változása az idő során.
+** trunk: a fővonal,
+** tag: pillanatkép
 * Lock-modify-unlock
 ** [[File:Szofttech_Vizsga_Lehetséges_vizsgakérdések_04.Lock_modify_unlock.png|400px]]
@@ 363. sor: / 487. sor: @@
 |}
-*
+* Mire szolgál a verziókezelésben alkalmazott „modify-update-merge” stratégia ? Röviden írja le a működésének lényegét ! (3 pont)
+** mire: termékekhez történő konkurens hozzáférés szabályozása
+** lényeg: párh. check-out, check-in-kor összefésülés, konfliktusfelold.
+[[Kategória:Infoalap]]

„Szoftvertechnológia - Lehetséges vizsgakérdések” változatai közötti eltérés