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

A VIK Wikiből
Harapeti (vitalap | szerkesztései)
válasz külön sorban
Harapeti (vitalap | szerkesztései)
válasz külön sorban
253. sor: 253. sor:
==V&V==
==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==
==Design==

A lap 2013. június 15., 22:13-kori változata


Korábbi Google Docs-segédlet (Lehetséges vizsgakérdések) Wikis változata. Innentől szerkesszük itt, köszi! (Hint az ilyen doksik Wikis átalakításához: docx-ben letölt, Microsoft Office Word Add-in For MediaWiki felrak, majd MediaWiki-formátumban elmentés (txt), majd annak Wikire történő bemásolása, némi korrekciók, és kész.) --Haraszin Péter (vita) 2013. június 15., 20:48 (UTC)

UML/CLASS

  • 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
    • korlátozás (constraints)
    • sztereotípia (speciális név-érték/tagged value/ pár (bool))
    • tagged value (név-érték pár)
  • Osztálydiagrammra standard sztereotípiák
    • utility - az osztály minden változója és metódusa statikus (osztály szkóp)
    • metaclass - olyan osztály, amelynek példányai osztályok
    • interface, enumeration
  • Class attribútum property(tulajdonság) módosítók:
    • readOnly, subsets, union, redefines, ordered, unique, valami expression
  • Class collection types:
    • Set, OrderedSet, Bag, Sequence
  • Class metódus property(tulajdonság) módosítók:
    • query, redefines, ordered, unique, oper-constraint(kényszer)
  • Operációk konkurenciája:
    • szekvenciális(sequential) - elméletileg nem lehet, hogy más hívja meg az operációt
    • guarded(őrzött) - jöhet ilyen hívás, de megoldott a kezelése
    • konkurens(concurrent) - bejöhet hívás, azonnal lekezelődik, nem jó
  • Active Object: saját szála van az objektumnak.
  • 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 “/”?
    • AZ ASSZOCIÁCIÓ LE VAN SZÁRMAZTATVA!
  • Mit jelent, ha egy pont van az asszociáció végen?
    • OWNERSHIP! Ki birtokolja az osztályt.
  • Hogyan lehet UML class-szal ábrázolni, hogy valami tartalmaz valamit?
    • karika, benne plus sign, inner class, tagváltozó, aggregáció

UML/PACKAGE,Component, Composite Structure, Deployment, Use Case

  • Milyen package importokat ismer?
    • import: fölötte lévő import/access is látja;
    • access: fölötte lévő import/access NEM LÁTJA!! //megj.: merge: több package-ben lévő dolgokat valahogy egyesítem
  • Components vs Class
    • komponensek csak interfészen keresztül érhető el, komponens önállóan kezelhető (class nem!)
  • Milyen fajtái vannak a komponenseknek?
    • telepítendő (deployment): az installáláshoz szükségesek
    • fejlesztés során keletkező (work product): felhasználónak nem szabad kiadni
    • execution: runtime jön létre (pl. fájl)
  • Milyen connectorokat ismer component világban?
    • assembly: komponenseket összekötő konnektor, elvárt, megkövetelt interfészek megfelelnek (sima vonal)
    • delegation connector: bonyolult dolgot zár be "dobozba"
  • <<delegate>> sztereotípia? szaggatott vonal!
  • Kompozit struktúrák esetén mit nevezünk kollaborációnak?
    • egy meghatározott funkcionalitás megvalósításához szükséges együttműködő elemek
  • Deployment diagram elemei?
    • artifact /komponenshez termék/,
    • node /logikai erőforrás/,
    • device /fizikai erőforrás/,
    • executionEnvironment /végrehajtási környezet/
  • Milyen Use Case kapcsolatokat (relációkat) ismer?
    • asszociáció
    • include - mindenféleképpen kiegészítjük bizonyos funkcionalitásokkal,
    • extend - bizonyos körülmények között egészítjük csak ki a megcélzott elemet
  • Mikor használjuk use case-ben actor-jelölésnek a pálcikaember helyett a doboz/<<actor>> sztereotípiás jelölést?
    • Ha egy actoron belül el tudunk képzelni egy másik actort /pl.: tetrisben egy elem, amelyik esik lefele, lehet, hogy nem esik lefele, hanem egy actor ejti lefele. Ekkor lehet azt mondani, hogy egy "belső actor" lépteti folyamatosan/
  • Mi a különbség Use Case include és extend sztereotípia között?
  • Use Case tulajdonságok (propertyk)?

UML/Szekvencia, Kommunikáció, Interaction Overview

  • 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.
  • Milyen Event-ek vannak Interaction diagramokon?
    • ExecutionEvent,
    • CreationEvent,
    • DestructionEvent,
    • MessageEvent
  • Milyen 2 fontos elvet ismer interakció-diagrammokon eseménysorozat értelemben?
    • Compositional: összemerge-ölök különböző eseménysorozatokat.
    • Átlapoló szemantika: ugyanúgy összemerge-ölök, de egy eseménysoron belül a sorozat sorrendje változatlan!
  • Mire jó az Interaction Overview Diagram?
    • magasszintű kép, ahol egy-egy doboz lehet akármilyen interakció, és időzítési előírás is lehet közöttük.
  • Milyen dobozok lehetnek szekvenciadiagramon? Mit jelentenek?

UML/State machine, Activity, Beyond UML

  • Állapotdiagramon milyen kompozit állapotokat ismer?
    • TODO
  • Mik az állapotdiagram elemei?
    • alaktivitások (procedúra), döntések, fork és join, úszósávok, object-action flow
  • Mi az Eclipse Modeling Framework(EMF)?
    • Modellező eszköz (pl. UML-hez hasonló (MOF) diagramokat lehet csinálni), kódgeneráló is!
  • Mi az XMI?
    • XML Metadata Interchange: XML-ben leírt UML/MOF diagram

JAVA

  • Singleton vs static class:
    • static classban csak static metódusok lehetnek!
  • 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!
    • pl null, stb..
  • Mit vár a Thread.sleep()?
    • long-ot!!!!
  • Thread-ek között hogyan lehet kommunikálni, honnan öröklődik ez?
    • Object.notify(), .notifyAll() és .wait()
  • Thread osztály metódusai?
    • isAlive(), join(), resume(), suspend(), stop(), start(), sleep(), destroy(), yield(),
  • Multitasking 2 fajtája?
    • process-based
    • thread-based
  • Hogy lehet meghívni az ős egy attribútumát/függvényét?
    • super.attrName / super.function()
  • Object class-ban mik final-ok?
    • getClass(), notify(), notifyAll(), wait()
  • Lehet egy osztály final ÉS abstract?
    • NEM!!!
  • Milyen típusai vannak a szálaknak?
    • Daemon és nem daemon (daemon gyakorlatilag háttérben futó szál)
  • Milyen synchronized-ok vannak?
    • blokk ... Object o = new Object();
    • .. 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
  • 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
  • Mikor lehet a wait(...), notify(),notifyAll() függvényeket meghívni?
    • Ha az objektum monitorának birtokában vagyunk.
  • Mi a különbség early (static) binding és late binding között?
    • TODO
  • Mikor mit jelent a final?
    • osztály előtt: nem lehet leszármaztatni + egyszer lehet példányosítani!;
    • metódus előtt: nem lehet felüldefiniálni leszármazottban;
    • változó előtt: konstans
  • 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).
  • Mit jelent, hogy a változó statikus/dinamikus része?
    • List x = new ArrayList();
      • egyenlőségjel bal oldala a statikus rész, ő lehet absztrakt is (tehát interfész is, mint a List is az);
      • jobb oldal a dinamikus, nem lehet absztrakt/interfész!!
  • Lehet konstruktor static?
    • NEM!!!!!
  • Mit nevezünk kiterjesztésnek JAVA nyelvben?
    • ha több interfészt valósít meg egy osztály

JUnit:

  • @Before, @Test, @After
  • Hogyan lehet jelölni, hogy pl. IOException-t várok?
    • test függvény előtt @Test(expected=IOException.class)
  • Hogyan lehet parametrizált teszteket csinálni?
    • osztály előtt: @RunWith(Parameterized.class)
 @RunWith(value = Parameterized.class)
 public class JunitTest6 {
    private int number;
    public JunitTest6(int number) {
       this.number = number;
    }
    @Parameters
    public static Collection<Object[]> data() {
      Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
      return Arrays.asList(data);
    }
    @Test
    public void pushTest() {
      System.out.println("Parameterized Number is : " + number);
    }
 }
  • assertEquals(elvárt, aktuális);
  • Milyen kimenetelei lehetnek a tesztnek?
    • pass: megfelel,
    • failure: nem az elvárt eredményt kapjuk valamilyen tesztre,
    • error: Exception dobódik, és nem kezelődik le
  • Hogyan lehet vizsgálni, hogy egy teszt tovább fut bizonyos időnél(pl 1 mp)?
    • @Test(timeout=1000)
  • Főbb függvények?
    • assertTrue(..), assertFalse(..), assertNull(..), assertNotNull(..), assertSame(..), assertNotSame(..), assertEquals(..), assertNotEquals(..), fail([String msg])

Bevezetés

  • Evolution of engineering discipline:
    • production+craft → commercial;
    • commercial+science → professional engineering
  • Mi a szoftverkészítés 4P-je?
    • People, Problem, Process, Product
  • Milyen minőségi képeket ismer?
    • transzcendentális, felhasználói, gyártás, termék, értékarányosság
  • ICOM-modellnél mi az input, kontrol(vezérlés), erőforrások, kimenet?
    • input: követelmények,
    • kontrol: {pénz,szabványok},
    • erőforrás: {csapat,eszközök},
    • kimenet: {kód,dokumentáció}
  • A vízesés modellben hogyan lehet visszalépni?
    • Az előzőre mindig + Validation → specification && M → R
  • Prototípus modellnél mik az egyes fázisok / hogyan lehet visszalépni?
    • Requirement → Specification → Quick design → Implementation → Evaluation.
    • Evaluation → Requirement
  • CMM-ben milyen Maturity (érettségi) szinteket ismer?
    • (1)Kezdetleges
    • (2)Ismétlődő
    • (3)Definiált
    • (4)Menedzselt
    • (5)Optimalizált
  • Spirál modellben milyen síknegyedek vannak jobbról balra körbe?
    • Követelmények meghatározása, kockázatelemzés, engineering (technológia), kiértékelés

RUP

  • Milyen workflow-hoz milyen modell tartozik?
    • Követelmények: Use Case Model,
    • Analízis: Analízis model,
    • Tervezés: Tervezési model,
    • Implementation: Implementation diagram,
    • Deployment: Deployment diagram
  • Az egyes modellek milyen UML diagrammokat tartalmaznak?
    • Use Case: {Use Case,Sequence};
    • Analízis: {static structure diagram, sequence};
    • Tervezési modell: {static structure, kommunikációs, állapotdiagram,activity};
    • Implementációs modell: {komponens,szekvencia};
    • Deployment: {Deployment, sequence}
  • Milyen típusú use case-ek vannak?
    • Event based, actor based
  • Milyen dimenziói vannak a use case formátumoknak?
    • (1) Leírás részletezettsége(magas szintű/kiterjesztett)
    • (2) Fogalmi/valóságos
    • (3)Prioritás(elsőrendű/másodrendű/opcionális)
  • Hogyan rangsorolunk use case-eket (iterációknak)?
    • (1)időben kritikus
    • (2)kockázatosak
    • (3)alapvető kutatást igénylők
    • (4)alkalmazás szempontjából legfontosabbak
    • (5)üzleti élet szempontjából fontosak
  • 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!
  • Mik a mutátorok?
    • Olyan objektumok, amelyek képesek megváltoztatni, hogy melyik osztályból származnak le.
  • Interakció diagramon mik a felelősségek?
    • Doing: valamit kell tudni;
    • Knowing: kiről mit tud

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)
  • 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
  • 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
  • Hogyan lehet becsülni, hogy mennyi hiba van a programban?
    • elrejtünk hibákat, mennyit találnak meg..
  • 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
  • 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
  • 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 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
  • 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(ö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 -.-)
  • 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), 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ű
  • 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?
    • Adatfolyam szerkezetek → Batch, Pipes and filters
    • 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..

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)
  • 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)
      • product owner: ügyfél, product backlog felügyelete, átveszi/elfogadja a munkát
      • scrummaster: adminisztrátor, felel a projektért
      • team: 5-9 ember, önszervező, önvezérlő
    • chickens (csak hozzájárulnak a projekt sikeréhez)
      • stakeholders (érdekeltek)
      • managers
  • Milyen események vanna Scrumban? 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?

Management

  • Milyen típusú projekt planek vannak? long term, short term
  • 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
  • Milyen erőforrások vannak? emberek, szoftver, hardver
  • Mit kell menedzselni? időt,információt,szervezet,minőség,pénz
  • Hogyan kell ütemezni egy projektet? DIAGRAM → requirements, Identify activities, Identify dependencies...
  • Mik a kockázat menedzsment 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? → 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?)

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
  • Milyen elemeket kell azonosítani? configuration item, communication(email ..), dokumentáció, implementáció
  • 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
  • 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? working copy, repository, check-out: r → wc, check-in/commit: wc → r, 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? fa struktúrába szedett verziók változása az idő során. trunk: a fővonal, tag: pillanatkép
  • Lock-modify-unlock
  • Copy-modify-merge
  • Three-way merge algorithm
    • A' = A = A → A* = A
    • A' = A != A → A* = A
    • A' != A = A → A* = A'
    • A' != A != Aconflict {A, A', A}A* manual resolve
  • CM / Version Control - Subversion – working copy vs. repository
unchanged changed
current commit -

update -

commit publish

update -

out of date commit -

update reread

commit out of date error

update - merge