VIK Wiki - Felhasználó közreműködései [hu]

Szoftver projekt laboratórium

2018-05-28T09:28:45Z

Schulcz Ferenc: 2018-as galéria hozzáadva

{{Tantárgy
|név=Szoftver projekt laboratórium
|tárgykód=VIIIAB06
|régitárgykód=VIIIAB02, VIIIA220
|kredit=3
|felev=4
|kereszt=nincs
|tanszék=IIT
|kiszh=nincs
|vizsga=nincs
|nagyzh=nincs
|hf=11 db
|szak=info
|targyhonlap=https://www.iit.bme.hu/targyak/BMEVIIIAB02
|levlista=szoftlab4{{kukac}}sch.bme.hu }}

{{Átnevezett tárgy|Szoftver laboratórium 4}}

A labor célja objektum orientált alkalmazás készítése UML (Unified Modeling Language) leírással, JAVA-ban megvalósítva, RUP (Rational Unified Process) processz szerint. A hallgatók 4-5 fős csoportokban dolgoznak és készítik el a dokumentumokat a megadott ütemezés szerint (a félév során 11 beadandó feladat lesz). A dokumentumokat a megadott formátumban, az összefoglalás és a programkód kivételével nyomtatott változatban kell beadni.

==Követelmények==
===Előtanulmányi rend===
[[Szoftvertechnológia]] tárgyból aláírás és [[A programozás alapjai 3]] tárgyból kredit megszerzése szükséges a tárgy felvételéhez.

(A VIIIA220 tárgy felvételéhez [[Szoftvertechnológia]] tárgyból kredit megszerzése szükséges.)

===Szorgalmi időszakban===
*A kezdés feltétele, hogy az egyes hallgatók ''csapatokba szerveződjenek (4-5 fő)'', és ''konzultációs időpontot válasszanak'' maguknak. Ha ez explicit nem történik meg, a tárgyfelelős implicit módon a maradék embereket csapatokká kasztolja.
*A min. elégséges '''félévvégi jegy''' feltételei:
**A félév során kiadott '''11 feladat leadása''' (8 dokumentáció, 3 dokumentáció+szoftver). Egy feladat leadásának feltétele ''az összes előző feladat sikeres teljesítése''. A teljesítés feltétele a 3 szoftver fázisnál (Szkeleton, Proto, Grafikus) a kapható pontok 41%-nak teljesítése (ez rendre 9, 15, 17 pontot jelent), a többi feladatnál, hogy a konzulens a feladatot elfogadja (tehát itt nincs minimum pont követelmény).
*'''Pótlási lehetőségek:'''
**Késedelmes leadás esetén a kapható pontok ''naponta 10%-kal csökkennek'', tehát 10 nap késés esetén már biztosan nem jár pont (de ebben az esetben is le lehet adni a feladatot, hiszen ez a többi feladat teljesítésének feltétele). Késés esetén közvetlenül a konzulensnek, vagy a tanszéken lehet leadni az anyagot.
**Ha a konzulens egy feladatot ''nem'' fogad el, úgy azt a következő hétre (a következő beadandó feladattal együtt) újra be kell adni, ilyenkor a rá kapható pont a maximális pontszám 40%-a. Pótolni egy alkalommal lehet.
*'''Kontakt órák'''
**'''Gyakorlat:''' Heti egy alkalom (nem kötelező minden csapattagnak a részvétel).

===A vizsgaidőszakban===
*'''Vizsga:''' nincs.

===Félévvégi jegy===
*A feladatok részletes pontozása:
# Szkeleton (összesen 100 pont, ''min 41 pont'')
#* Követelmény, projekt, funkcionalitás (10 pont)
#* Analízis modell kidolgozása 1. (20 pont)
#* Analízis modell kidolgozása 2. (30 pont)
#* Szkeleton tervezése (20 pont)
#* Szkeleton beadása (20 pont, ''min 9 pont'')
# Proto (összesen 100 pont, ''min 41 pont'')
#* Prototípus koncepciója (20 pont)
#* Részletes tervek (45 pont)
#* Prototípus beadása (35 pont, ''min 15 pont'')
# Grafikus (összesen 100 pont, ''min 41 pont'')
#* Grafikus felület specifikálása (30 pont)
#* Grafikus változat beadása (40 pont, ''min 17 pont'')
#* Összefoglalás (30 pont)
*Mindhárom feladatrész 100 pontot ér. A sikeres teljesítéshez szükséges, hogy ''mindegyik ilyen blokkból a csapat legalább 41 pontot elér'' (és a ''blokkok végén található szoftver beadásra is legalább 41%-ot kap''). Ha ez a feltétel ''nem'' teljesül, az ''egyéni teljesítménytől függetlenül mindenki elégtelent kap'' a csapatban! Ha a minimum követelmények teljesülnek, úgy a Szkeleton (Sc), Proto (Pr), illetve Grafikus (Gr) feladatrészekre kapott pontok súlyozott átlagát kell venni, ahol a súlyok:
*<math>P= 0,3*Sc+0,5*Pr+0,2*Gr</math>
*Az így képzett átlag a csapat pontszáma. Ez a pontszám végül az egyes csapattagok kontribúciójának arányában oszlik el (ezt az arányt a csapat állapítja meg). Amennyiben ez az arány nem tükrözi a napló tartalmát, úgy a konzulens ezt az arányt a csapattagok részvételével (vagy akár anélkül) megváltoztathatja. A végső pontszám jegyre konvertálása az alábbi táblázat szerint működik:
:{|class="wikitable" align="center"
!P !!Jegy
|-
| 0 - 40 || 1
|-
| 41 - 54 || 2
|-
| 55 - 68 || 3
|-
| 69 - 82 || 4
|-
| 83 - 100|| 5
|}

==Jótanácsok==
* [[Szerkesztő:Madbence/Szoftver labor 4 tanácsok|Lennon tanácsai]] a tárgyhoz

=== Verzókezelés ===
Mindenképpen kell egy értelmes verzókezelő rendszer, ha dropboxon vagy haosnlón küldözgetitek, csak magatokkal toltok ki. Jelenleg (2014) működik a [https://git.sch.bme.hu kszk git verziókezelője], pár perc alatt el lehet sajátitani hozzá az alapokat: [https://www.atlassian.com/git/tutorials tutorial]

=== Doksi írás===
Érdemes olyan platformot választani, amit egyszerre mindenki tud használni, nem kell várni a másikra, illetve utólag összeollózni. Jelenleg a [https://drive.google.com Google Drive]nál nem tudok jobbat ajánlani.

=== Kommunikáció ===
Nem kell mindig találkozni, a lényeg, hogy legyen egy olyan közös csatorna, amit mindenki tud követni. Akár facebookbeszélgetés, akár levlista, a lényeg hogy mindig, mindenki kapja meg. (A kódokat viszont ne itt küldözgessétek...)

=== Kommentezés ===
Bármilyen függvényt írsz, mindig kommenteld oda, hogyan kell használni, mire szánod, mert a csapattársad nem tud olvasni a gondolataid között

=== Beadandó tartalmi követelménye ===
2017 tavaszán nekünk Goldschmidt Balázs volt a labvezünk, ezek az információk főleg tőle származnak.
* 2. Követelmény, projekt, funkcionalitás:
** Ennek a dokumentumnak a legfontosabb részei:
*** Funkciók: A feladat szövegében sok olyan részlet van, ami nincsen kifejtve, a csapatra van bízva, hogy ők hogyan képzelik el. Ebben a részben főleg az ilyen részleteket kell kifejteni, azaz úgy kell átfogalmazni a feladat szövegét, hogy abból minden egyértelmű legyen, ne lehessen részeket többféleképpen értelmezni.
*** Követelmények: Ennek összhangban kell lennie a Funkciók résszel, a szövegben főleg az igékre fókuszálva célszerű kigyűjteni ezeket. (ajánlott legalább 15-20 követelmény megfogalmazása) Ez alapján a use-case-ek meghatározása már könnyű.
*** Szótár: Mindent fontos benne meghatározni, nem szabad olyan fogalomnak maradnia a korábbi részekben, ami itt nincsen egyértelműen meghatározva. Természetesen nem csak a mennyiség, hanem a minőség is fontos. A funkciók olvasása közben könnyen kigyűjthetőek ezek a fogalmak. Ajánlott, hogy több ember is olvassa át ezt, mert ekkor még a csapatban nem alakul ki egy tlejesen közös kép a feladatról, és emiatt mindenki a saját elképzelését fogalmazza meg, így fellelhetőek az olyan részek, amik nem lettek még a csapaton belül normálisan tisztázva.
** Többi rész főleg a dokumentum keretbe foglalásáért felelős, de azok kitöltése is követelmény.
* 3. Analízis modell kidolgozása 1:
** Objektum katalógus: Ennél a résznél még nem osztályokban kell gondolkodni, hanem a feladatot olvasva ki kell gyűjteni az entitásokat. Ez alapján utána könnyebben lehet az osztályokat meghatározni. Itt még nem szabad az osztályoknak, interfészeknek, öröklésnek megjelennie.
** Statikus struktúra diagram (osztály diagram), szekvencia diagram: Ezt a két részt együtt ajánlott készíteni, hiszen az osztálydiagram hibái előkerülnek a szekvenciák megfogalmazása közben és fordítva is igaz. Fontos az összhang, azaz ami megjelenik az osztálydiagramon, az legalább egy szekvencián is szerepeljen, és ami a szekvencia diagramokon rajta van, az az osztálydiagramon is kell, hogy szerepeljen. Nagyságrendileg 20 szekvenciadiagram ajánlott.
** Osztályok leírása: Jellemzően csak szöveg gyártásáról szól ez a rész az eddig elkészítettek alapján.
** State-chartok: Nálunk az hangzott el, hogy nem túl fontos, csak tényleg akkor rakjunk bele, hogyha van olyan része a feladatnak, amit jól jellemez.
* 4. Analízis modell kidolgozása 2:
** Általában az előző részt nem szokta senki sem elsőre jól megcsinálni, emiatt mégegyszer meg lehet próbálni. A labor vezetők rá fognak mutatni az előző beadandó hibáira, és legalább azokat ajánlott javítani a jó pontért. Természetesen aki az előzőt jobbra megcsinálta, annak itt kvesebb tennivalója van.
* 5. Szkeleton tervezése:
** A szekelton lényege, hogy a korábban megfogalmazott működést kellene egyszerű konzolos felületen keresztül bemutatnia, azaz nyomon kell tudni követni egy adott szekvenciát például.
** Sok (>10) use-case-t ajánlott megfogalmazni, nagyjából a program teljes működését le kellene velük fedni.
** A menüben az előtte megfogalmazott use-case-ek közül kell tudni választani, aminek hatására elindul egy szekvencia végrehajtása. Fontos, hogyha a szekvenciát valamilyen döntési feltétel van (opt, alt), akkor azt a felhasználótól meg kell kérdezni, hogy ez most igaz vagy hamis. Akár az is lehetséges, hogy a felhasználónak előre elmondjuk (kiírjuk), hogy a várt végrahajtáshoz milyen válaszokat kell adnia a megjelenő kérdésekre.
** A konzolra a függvény meghívását (a paramétereivel együtt akár) és a visszatérését is ki kell írni (identálás - tabulátorok használata erősen javasolt).
** Kommunikációs diagramok: UML2-ben objektum diagram nincsen, és ennek a résznek az lenne a lényege, hogy az objektumok közötti kapcsolatokat megjelenítse, azaz a szekvencia diagramok felülnézetét. Nálunk azt mondta Goldschmidt Balázs, hogy itt nem kell megjelennie az üzenetváltásoknak, hiszen azok a szekvencia diagramokon már szerepelnek, azaz itt csak össze kell kötni azokat az objektumokat (nem osztályokat), amik a szekvencia diagramokon szerepelnek, tehát egy szekvencia diagramhoz alapvetően tartozik egy "kommunikációs diagram" is.
* 6. Szkeleton beadása:
** Az első rész vége, tartalmaznia kell egy értékelést is, ahol a tagokra bontva megjelenik, hogy ki mekkora százalékban járúlt hozzá az első rész elkészítéséhez (aláírás javasolt a nevek mellé).
** A dokumentum többi részének a kitöltése értelemszerű.
** Ennél a résznél a program elkészítése az, amire több időt kell fordítani.
* VÁLTOZÁSOK:
** A szekelton beadását követően előszeretettel csinálnak valami módosítást a feladat kiírásában (erről emailben értesítenek mindenkit). Általában ez olyan változás, amit jól elkészített modell esetén könnyű elkészíteni. A következő dokumentum elején ezeket a változásokat meg kell jeleníteni, azaz célszerű egy összefoglalást írni a változásról, majd utána a módosított/új osztály és szekvencia diagramokat kell elhelyezni a dokumentumban.
* 7. Prototípus koncepciója:
** Nagyjából ezt a részt úgy kell elképzelni, mint a szkeleton általánosítását, azaz adott funkciók nem "bedrótozva" vannak, hanem a programunk parancsokat értelmez, és a parancsoknak megfelelő funkcionalitást hajtja végre. Gyakorlatilag ezzel a programnak a modell része majdhogynem teljesen kész lesz, csak a grafikus rész fog hozzákerülni, de az is ehhez hasonló interfészt fog használni.
** A parancsok beolvasására a konzolról célszerű egy segéd osztályt felvenni, amire jó eséllyel nem lesz már szükség a grafikus résznél.
** A parancsok definiálásának egyértelműnek kell lennie, azaz még azt is jelölni, kell, hogy a parancs paraméterezésénél milyen elválaszt karakter van, mi a paraméterek sorrendje, azok mit jelentenek.
** A use-case-ek megfogalmazása ezek alapján nem túl nehéz feladat.
** Tesztelési tervnél a program fontosabb funkcióit legalább le kell fedni. Hogyha van olyan rész, ami több esetben ugyanúgy működik és lényegében csak a megjelenítésben lesz különbség, akkor nem kell többszörösen elkészíteni az adott tesztet.
** Nem ajánlott JUnit vagy valami ehhez hasonló környezetben gondolkodni, mert csak feleslegesen elbonyolítja a helyzetet, bőven elég karakterese bemenetre és kimenetre gondolni.
* 8. Részletes tervek:
** Az előző rész részletezéséről szól ez a dokumentum.
** Az osztályok leírása nagyrészt csak copy-paste a korábban beadott leírásokból.
** Tesztek részletes terveinél az előző dokumentumban definiált nyelvnek megfelelően kell megfogalmazni. Ajánlott tesztenként külön txt-be gyűjteni (főleg a bemenetet), mert később jól fog jönni.
* 10. Prototípus beadása:
** A második blokk vége ez a doksi, úgyhogy ismét kell bele értékelést rakni.
** A dokumentum kitöltése nagyjából értelemszerű, hasonlít az előző ilyenhez.
** Tesztelési jegyzőkönyveknél ajánlott nem csak sikereseket belerakni (mindegyik definiált teszthez kell lennie sikeresnek), hanem egy-két hibás is legyen, hogy látszódjon, hogy van értelme a teszteknek, meg az azért valószínű, hogy elsőre úgysem volt hibátlan a kód, és ez látszódjon a dokumentációban is.
** Teszt bemeneteket ajánlott txt formátumban is mellékelni a beadásnál, mert a tesztelést végző csapatnak nem túl kellemes élmény lehet mindent kézzel beírni.
** A programnak működnie kell úgy is, hogy a bemenetét szöveg fájlból kapja, azaz parancssorban a mellékelt txt fájlokat beleirányítjuk. (nem fájlbeolvasó függvényekre kell gondolni)
* 11. Grafikus felület specifikációja:
** Java Swing-ben kötelező gondolkozni, JavaFX-et el kell felejteni!
** Grafikus interfésznél ajánlott szövegesen leírni, hogy a funkciót hogyan képzeljük el, és néhány (akár paint-ben készült) képpel illusztrálni.
** Felület működési elvénél meg kell fogalmazni, hogy a grafikus megjelenítésért felelős osztályok és a modell osztályok között milyen jellegű kapcsolat van. Alapvetően mindegyik osztályhoz tartozik egy csomagoló/wrapper osztály, amiben a grafikus megjelenítésért felelős kódrészek vannak, de a működésért felelős információk továbbra is a modell osztályban kell maradniuk, azaz az eddig elkészített kódrészekhez nem igazán kell hozzányúlni majd. Alapvetően kétféle megközelítés van: a garfikus rész kérdezi le a modell osztályoktól, hogy hogyan rajzolja ki magát vagy a modell osztályok szólnak, hogy változás történt és rajzold ki magad. A szekvenciáknál az elképzelt elvet be kell mutatni, hogy hogyan fog majd működni, tehát legalább 5-10 diagram kellhet a normális részletezettséghez.
* 13. Grafikus változat beadása:
** Ezzel együtt kell beadni a kész programot is.
** Ismét kell bele értékelést írni a tagok hozzájárulásáról.
* 14. Összefoglalás
** A ráfordított munkaórák alapján a korábban megadott százalékokon akár módosíthat a labvez, hogyha úgy látja, hogy a kettő nincs összhangban.
** A vélemény nem számít bele a kapott jegybe, de azért illik normálisan kitölteni.
(A leírtakért felelősséget nem vállalok, nálunk ezek az elvek voltak igazak, bár tapasztaltuk, hogy labvezenként kisebb/nagyobb eltérés volt, de nincs rá garancia, hogy nálatok is ezek igazak lesznek. Ajánlott laborra úgy menni, hogy előre megnézitek, hogy mit kell a héten csinálni, és akár az itt felsoroltak segítségével kérdéseket fogalmazzatok meg magatokban, és ezekre a kérdésekre a labvezek egyértelmű választ tudnak adni. Csak a doksiban leírt kék szövegek alapján elég nehéz a doksi elkészítése. Tényleg ajánlott figyelni a labor során, mert kellemetlen, amikor másoktól kell információmorzsákat összeszedni, mert éppenséggel senki sem figyelt kellő mértékben a laboron, vagy mindenki másra emlékszik.)

==Feladatok==
{{Rejtett
|mutatott= '''2016/17 tavasz - Vonatos'''
|szöveg=
Sheldon terepasztalt épít vonatjai számára. A terepasztal széleiről időnként vonatok indulnak. Egy vonat egy mozdonyból és valahány kocsiból áll. A kocsikban utasok ülnek, akiket a megfelelő állomásokra kell eljuttatni a megfelelő sorrendben.

A terepasztalon sínek futnak, a vonatok csak a síneken közlekedhetnek. Elágazásoknál a síneket váltók kötik össze. Egy vonat mindig abba az irányba halad tovább, amerre a váltó áll. Bizonyos helyek különlegesek a pályán, ezeken a helyeken egy alagút száját lehet felépíteni vagy megszüntetni. Egyszerre maximum csak két alagútbejárat lehet megépítve a pályán. A két bejáratot egy speciális alagút köti össze, és ha a vonat bemegy az egyik szájon, akkor a másikon jön ki. Az alagút lehet rövidebb is, mint a vonat hossza, és a vonat alagútban lévő része nem látható.

A sínek mellett különböző színű állomások lehetnek. A vonatok kocsijainak is van színe, és amikor egy vonat egy állomáson átrobog, az állomáson csak azok az utasok ugranak le, akik ugyanolyan színű kocsiban utaznak, mint amilyen az állomás színe. A kocsik azonban csak a mozdonytól kezdődő sorrendben ürülnek ki. Tehát hiába ér a vonat egy olyan állomásra, amely megegyezik az utolsó kocsi színével, az utasok nem fognak onnan leszállni, amíg a korábbi kocsik még nem ürültek ki.

A játékos a váltókat tudja állítani, illetve alagútszájakat tud építeni vagy megszüntetni. A játék célja, hogy minden utas eljusson a megfelelő állomásra anélkül, hogy a vonatok egymással összeütköznének. Ha két vonat összeütközik, a játékos veszít. Miután egy terepasztalt sikerült teljesíteni, a játék a következő pályával folytatódik.

'''Módosítás'''
# Sheldon új pályaelemet, kereszteződő síneket vásárolt. A kereszteződés egyszintű, a különböző irányokból jövő vonatok a kereszteződésben ütköznek.
# Egyes állomásokon utasok a megfelelő színű üres kocsikba (a kocsi szerelvényben elfoglalt helyzetétől függetlenül) fel tudnak szállni.
# Sheldon bővítette a vagonkészletét. Vett szeneskocsikat, amiken nem utaznak utasok, nem is tudnak felszállni. Az utasok leszállásánál az ilyen vagonokat nem vesszük figyelembe.

A változásokkal kapcsolatos modellmódosításokat már a március 27-ei, Prototípus koncepciója c. beadandó anyagban is figyelembe kell venni. Az anyagnak legyen egy 0. fejezete, ami tartalmazza a módosítással kapcsolatos szöveges elemzést, a frissített osztálydiagramot, valamint a fenti pontok sorrendjében a módosult és új szekvenciadiagramokat.
}}

==Befejezett projektek galériái==
* [[Szoftlab4_Kindergarten_galéria_2006|Kindergarten Galéria 2006]]
* [[SzgLab4Galeria2008|SnakeFarm Galéria 2008]]
* [[SzgLab4Galeria2010|Bankrabló Galéria 2010]]
* [[SzgLab4Galeria2012|Continuity Galéria 2012]]
* [[Szoftlab4_AntFarm_galéria|AntFarm Galéria 2013]]
* [[Szoftlab4_Két_Torony_galéria|Két Torony Galéria 2014]]
* [[Szoftver projekt laboratórium - Killer sokoban galéria|Killer sokoban galéria 2018]]

==Csapattoborzás==
Ha nincs csapatod, [https://lists.sch.bme.hu/wws/arc/szoftlab4 levlistán] érdemes szóvá tenni, a legkönnyebben ott lehet csapatot verbuválni. Mivel a csapatban mindenképpen szükség lesz jó kóderre, dokumentálóra, érdemes az ilyen jellegű igényeket is beleírni a toborzó emailekbe. Viszont azt, hogy ''szeretném elvégezni a tárgyat'', lehetőleg ne, hisz én még nem találkoztam olyan emberrel, aki azért vette föl, mert ''nem'' szeretné elvégezni. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 21:32 (CET))

{{Lábléc_-_Mérnök_informatikus_alapszak_2014}}
{{Lábléc_-_Mérnök_informatikus_alapszak}}

Szoftver projekt laboratórium - Killer sokoban galéria

2018-05-28T09:27:11Z

Schulcz Ferenc: Lap létrehozva.

{{Vissza|Szoftver projekt laboratórium}}

==Feladat kiírás==
Egy raktárépületben ládákat tárolnak. A raktárépület padlója négyzetekre van osztva, ezeken állnak a négyzetekkel megegyező alapterületű ládák. A ládák eltolhatók, de egy mozgatással mindig csak egy szomszédos négyzetre kerülhetnek.

A raktárban többen dolgoznak, a játékosok őket irányítják. A cél a ládák előírt helyre tologatása. A raktárnak falai és oszlopai is vannak, ezeken a ládák nem tolhatók át. A ládák egymást el tudják tolni. Ha egy munkásra ládát tolunk, akkor a munkás automatikusan szomszédos négyzetre tolódik. Ha nem tud eltolódni (mert pl. fal van mellette), a munkás meghal. A ládák nem nyomhatók össze.

A padlón egyes helyeken lyukak találhatók, amelyekre ládát tolva a láda leesik (eltűnik). Ha munkás lép rá, meghal. Némelyik lyuk csak akkor viselkedik lyukként, ha egy kapcsolón láda áll, egyébként padlónak tűnik. A kapcsolón ládának kell állnia, hogy kinyissa a lyukat, ha munkás áll a kapcsolóra, akkor nem kapcsol.

A játék véget ér, ha az összes láda a helyén van, vagy ha már nem lehet többet tolni. Az nyer, aki ekkorra a legtöbb ládát a helyére tolta.
A játék során az ellenségek folyamatosan jönnek. A játék elején ritkábban, később gyakrabban és nagyobb csoportokban, azonban számuk véges, előbb-utóbb elfogynak. A játék akkor ér véget, ha egy ellenség eljut a Végzet Hegyéhez, vagy ha már sikerült az összes ellenséget kiirtani. Az első esetben Szauron és Szarumán megsemmisül, utóbbi esetben fényes győzelmet aratnak és örökké uralni fogják a világot.

=== Módosítás ===
* A munkások bár több ládát is eltolhatnak egyszerre, minden munkás rá jellemző erővel tol. Ha a ládák együttes tapadási súrlódási ereje ennél nagyobb, akkor a tolás nem sikerül.
* A padlóra különböző kenőanyagokat tehetnek a munkások: olajat, amitől csúszósabb lesz (csökken a tapadása) és mézet, amitől ragacsos (nő a tapadása).

== Single Point of Failure ==
=== A csapat ===
* Benkő Csaba
* Schulcz Ferenc
* Takács Ildikó
* Zalavári Márton
=== A játék, doksi és néhány jó tanács a tárgyhoz: ===
* https://git.sch.bme.hu/schulczf/killer_sokoban
* Mindenki 5-öst kapott a feladatra.

=== Képek a játékból ===
<gallery>
File:Projlab png 20180528 killersokoban1.png
File:Projlab 20180528 killersokoban2.png
File:Projlab 20180528 killersokoban3.png
</gallery>
[[Kategória:Mérnök informatikus]]

Fájl:Projlab 20180528 killersokoban3.png

2018-05-28T09:23:42Z

Schulcz Ferenc: Projlab feladatmegoldás screenshot3

Projlab feladatmegoldás screenshot3

Fájl:Projlab 20180528 killersokoban2.png

2018-05-28T09:23:27Z

Schulcz Ferenc: Projlab feladatmegoldás screenshot2

Projlab feladatmegoldás screenshot2

Fájl:Projlab png 20180528 killersokoban1.png

2018-05-28T09:22:19Z

Schulcz Ferenc: Projlab feladatmegoldás screenshot1

Projlab feladatmegoldás screenshot1

Szerkesztő:Madbence/Szoftver labor 4 tanácsok

2018-05-28T07:10:54Z

Schulcz Ferenc: Egy plusz megoldás belinkelve.

Személyes tapasztalataim, illetve tanácsaim az utókornak. Utoljára frissült: [[Szerkesztő:Madbence|lennon]][[Szerkesztővita:Madbence|(vita)]] 2013. január 21., 07:40 (CET)

=A csapat=
Ha levlistán vadászol csapattagokat, vagy akarsz csapatot találni magadnak, mindenképpen érdemes jelezni, hogy milyen területen tartod magad jónak, hiszen lehet, hogy 5 profi Java kóder zseniálisan jól összerakott, és megtervezett kódot tud írni, ha a dokumentáció rossz, nagyon le tudja rontani a teljesítményt. (oké, mondjuk öt jó Java kóder max egy hosszúhétvége alatt lefejleszti az egészet mindenestül, utána meg csak generálja a diagramokat :) )

===Államforma===
Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól. (Kivételek persze vannak.)

Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", (szinte) teljesen életképtelen, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''" (ha nem, miért nem, csinálnál-e helyette Z-t, ami W-re elkészül?). Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni). Amikor faszán működik a csapat, azt biztosan észre fogjátok venni, ugyanis olyankor nem akarjátok egymást vízbe fojtani.

===Kommunikáció===
Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).
A legjobb a napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor. Oké, a leadás dél körül szokott lenni, és reggel 8 és dél között kemény 4 óra van, de azért próbáljátok ne ilyenkor befejezni. Vagy ha már így jártok, mindenképpen nézzetek körül, hol fogjátok olyan gyorsan kinyomtatni (és műanyag bugyit szerezni hozzá! :D), hogy még vissza is érjetek.

Gyakorlatilag '''a siker kulcsa a kommunikáció''', minden ezen múlik. A feladatokat érdemesebb minél atomibb, minél kisebb részekre bontani, és '''folyamatosan''' egyeztetni. Máshogy nagyon nehéz (egész egyszerűen amiatt, hogy mindenki a saját munkatempójához, gondolkodásmódjához szokott, és a kooperációhoz meg kell ismerni egymást).

Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni.

=Kollaboráció=
Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni.

===Doksi===
Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ bitbucket] szolgáltatását használtuk, a repó mellé kap az ember egy wikit is, ami szintén repóként működik. Érdemes megoldani, hogy a Wikiből on-the-fly lehessen pdf doksit generálni, mi erre a célra egy Wiki2LaTeX toolt csináltunk (ha megtalálom a kódját, felrakom), ami a Wiki saját markupjából LaTeX kódot generált, így gyakorlatilag pár kattintás volt az aktuális Wiki tartalmából dokumentációt készíteni.

Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. El lehet kezdeni tanulni a [http://en.wikipedia.org/wiki/LaTeX LaTeX]-et ([[Dokumentumszerkesztés|Van is rá tárgy]]). A [https://www.sharelatex.com/ ShareLaTeX] oldalon lehet kollaborálkodni is, illetve ha éppen nincsenek kéznél a binárisok, neten, [http://manuels.github.com/texlive.js/website/ on-the-fly is lehet pdf-et generálni] (az [http://github.com/kripken/emscripten emscripten] csodákra képes :D).

'''''Update''' --[[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2018. május 28., 07:02 (UTC)'': Legalábbis 2018-ban már előre kiadott docx fájlokat kellett kiegészíteni, és ezeket kellett dokumentációként leadni. Mi az egészet felraktuk egy Google Drive mappába, és ott Google Docs-szal kényelmesen lehetett csapatban szerkesztgetni.

===UML===
Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ Enterprise Architect]-et választottuk (találtunk egy "ingyenes" letöltési lehetőséget), de igaziból úgyis csak nyilakat meg dobozokat kell rajzolni, szóval ami ezt tudja, az rendben van. Ha tud menteni vektoros formátumba, az külön orgazmus, mert még ki is fog nézni valahogy a doksi.

Mivel ha ezt a tárgyat csináljátok, mind átmentetek Szofttechből, tehát állítólag az UML a kisujjatokban van. Ez jól is fog jönni, mert tonnaszámra kell diagramokat csinálni (és olyan részleteseket, amiket a valóságban többet a büdös életben nem fogtok).

===Verziókezelés===
LZ biztos mindenkit bevezetett a verziókezelés rejtelmeibe Szofttechből, csak éppen a többség nem hitte el, hogy ez valami értelmes dolog. Értelmes dolog, és meg kell tanulni használni. '''Én a Git-et ajánlom'''.

====SVN====
Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek.

====Mercurial====
A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom.

====Git====
[http://git-scm.com/ Az áltimét verziókezelő] (szintén DVCS), '''ha tudod kezelni, mással nem is érdemes foglalkozni'''. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial|tutorialt]], még most is viszonylag használhatónak tartom.

=Konzultációk=
Itt többnyire az van, hogy meg lehet hallgatni, miért szar a munkátok, és hány pontot nem kaptatok meg. Jó beszélőkével rendelkezők itt még tudnak 1-2 pontot kisajtolni, a konzulens is emberből van, és nem gondolatolvasó, szóval az elmék egyeztetése esetenként jótékonyan tud hatni a pontszámra.

Amikor szoftvert kell bemutatni, mindenki legyen ott, egyébként irgumburgum jár (akár random mínuszjegy!). A szürke hétköznapokon elég, ha egy ember van ott, de ilyenkor célszerű olyan embernek bemenni, aki tudja, miről szólt az aktuális feladat, amit beadtatok.

Ilyenkor adják ki a következő heti feladatokat, és aki nem alszik éppen, az tippeket is hallhat ezzel kapcsolatban.

=Kód=
Előbb-utóbb kódolni is kell, érdemes nem szarozni vele túl sokat. Érdemes minél egyszerűbb, logikusabb kódot írni, aminek az előállítására az alábbi algoritmus rendkívül jó:

# Kódolj
# Ha kész van, nézd meg, hogy bonyolult-e. Ha igen, kezd elölről.
# Profit!

===Editor===
Érdemes a Notepadnál komolyabb cuccot használni, de azt figyelembe kell venni, hogy beadásnál parancssorból kell majd fordítani, szóval [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak.

Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket).

===Kommit-policy===
Mivel állítólag a kódolás csapatmunka, nem illik a master ágba csak úgy belekommitkodni, szóval érdemes mindenkinek saját ágon dolgoznia, és ott ''gyakran'' kommittolnia. A gyakran úgy van értve, hogy ha a kommit megfogalmazásában szerepel az és szó, akkor már elfelejtettél egy kommitot. Magyarul a kommitok atomiak, 5-10 sor kód legyen bennük max (nyilván lehet, hogy több is lesz, de célszer ilyen nagyságrendben mozogni).

Parasztság syntax erroros kódot kommittolni, ilyet ne tegyünk, ellenkező esetben a vétkes sarokba állítható tetszőleges időtartamra.

===Kódolni nehéz===
Fogadjuk el, hogy ''úgyis'' szar kódot fogunk írni elsőre, ne is próbáljunk mentegetőzni. Te sem, és én sem tudok ''elsőre'' jó kódot írni. Viszont a szar kódot újra kell írni, de minimum refaktorálni.

Ökölszabály, hogy ha egy egység (egy osztály) nem fér ki az editorban egy (max másfél) képernyőre, az a kód szar. Persze a szar kód is működhet, leadás előtt az ember meg annak is nagyon örül, ha egyáltalán lefordul, szóval ez a kód esztétikai értékét növelni, amire meg mondjuk a jó kóder tud áldozni az idejéből.

===Kommentok===
A kommentek alapvetően azért kellenek, hogy legyen miből doksit generálni. Ha kommentek nélkül nem érti valaki a kódot, akkor az a kód ismét csak szar, újra kell írni/tervezni.

===Kódolási stílus===
Többnyire minden editor csuklóból tud kódot formázni, ettől még érdemes valami egységes kódolási stílust betartani, és speciel sírva tudok fakadni a nem konzisztens whitespace használaton. Mindegy, hogy mit választotok, legyetek konzisztensek, a kód ne nézzen ki úgy, mint egy marék hányás.

===Debug===
Debuggolni nem könnyű, főleg egy grafikus játékot. Azért próbáljuk meg, és lehetőleg a ''System.out.println'' legyen az utolsó megoldás erre.

=Egyéb megfontolásra érdemes dolgok=
===Adatszerkezet===
Biztosan kell majd valamiféle adatokat tárolni, mondjuk egy játéktérképet, kapcsolási rajzot, stb. Ilyenkor az ember előveheti az XML-t, mint taktikai atomtöltetet, a JSON-t, mint ágyút, vagy kitalálhat valami kulcs:érték párokból álló saját hóttegyszerű szintaktikát, amivel lehet a verébre lövöldözni. A lényeg, hogy szerintem nem akartok kézzel XML-t írni.

===Magic!===
Ha nekiálltok tervezni UML diagramokat, ''mindig'' legyen fogalmatok arról, hogy ez kódban hogyan fog kinézni, illetve ''működni'' fog-e majd így a kódban. Ezzel a módszerrel elég sok alapvető hibát ki lehet szűrni. Ha ez nem megy, akkor jön az a szégyenteljes megoldás, hogy a cuccot le kell kódolni, majd a kódból kell előállítani a doksit (ugye alapvetően pont fordítva kéne). Ja és ezt nem tőlem hallottátok.

===Konzulens===
A konzulens tanácsait érdemes megfogadni, ő azért van ott, hogy ne csinálj hülyeséget (illetve megbasszon, ha hülyeséget csináltál).

A mi konzulensük tök jó fej volt, gyorsan válaszolt az emailekre (egyszer hajnali háromkor írtam neki, egy óra múlva már meg is jött válasz :D). Ha valami nem világos a feladatban, vagy nem vagytok biztosak benne, hogy jó úton haladtok, érdemes írni neki. Értékeléskor így is úgy is értékelni fogja a munkátokat, de olyankor már pontot fog levonni (kérdezni nem bűn). Ha olyan anyagot adtok be, amire már előtte is azt mondta, hogy ''begyere'', az csak jót jelenthet.

===Ha nem megy===
Ha nem tudtok együtt dolgozni (valaki képtelen kódolni, rendes UML doksit csinálni, stb), de azért a motiváció megvan, akkor érdemes valami hatékony megoldást keríteni. Ez kb úgy tud működni, hogy mindenki ''csak'' arra a területre fog korlátozódni, amihez ''tényleg'' ért, magyarán a balanszot (mindenki kódol, mindenki dokumentál, mindenki UMLezik) el kell tolni egy jobb irányba. Az ezzel járó lustálkodást, többletmunkát csapaton belül kell lerendezni.

===Értékelés===
Minden feladatra kaptok egy értékelés a konzulenstől, a doksiban be lesz karikázva mi nem tetszett neki. Ezt érdemes feljegyezni, ugyanis az összefoglalásban meg fogja nézni, hogy kijavítottátok-e.

=Feladatok=
Mire kell figyelni az egyes heti leadott anyagokban. (Majd lesz... [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET))

=Continuity=
2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon hipszter Helvetica] betűtípussal is). [https://github.com/madbence/fearlesscode_szoftlab Forráskód] (kizárólag okulási célokkal!)

''Update:'' mi pedig 2018 tavaszán csináltuk, a kód, a doksi és néhány bónusz jó tanács elérhető [https://git.sch.bme.hu/schulczf/killer_sokoban itt]. (Jeles értékelést kaptunk.)

Szerkesztő:Madbence/Szoftver labor 4 tanácsok

2018-05-28T07:02:36Z

Schulcz Ferenc: Update: Google Docs ötlete hozzáadva.

Szoftver projekt laboratórium

2018-05-28T06:50:07Z

Schulcz Ferenc: /* Szorgalmi időszakban */

{{Tantárgy
|név=Szoftver projekt laboratórium
|tárgykód=VIIIAB06
|régitárgykód=VIIIAB02, VIIIA220
|kredit=3
|felev=4
|kereszt=nincs
|tanszék=IIT
|kiszh=nincs
|vizsga=nincs
|nagyzh=nincs
|hf=11 db
|szak=info
|targyhonlap=https://www.iit.bme.hu/targyak/BMEVIIIAB02
|levlista=szoftlab4{{kukac}}sch.bme.hu }}

{{Átnevezett tárgy|Szoftver laboratórium 4}}

A labor célja objektum orientált alkalmazás készítése UML (Unified Modeling Language) leírással, JAVA-ban megvalósítva, RUP (Rational Unified Process) processz szerint. A hallgatók 4-5 fős csoportokban dolgoznak és készítik el a dokumentumokat a megadott ütemezés szerint (a félév során 11 beadandó feladat lesz). A dokumentumokat a megadott formátumban, az összefoglalás és a programkód kivételével nyomtatott változatban kell beadni.

==Követelmények==
===Előtanulmányi rend===
[[Szoftvertechnológia]] tárgyból aláírás és [[A programozás alapjai 3]] tárgyból kredit megszerzése szükséges a tárgy felvételéhez.

(A VIIIA220 tárgy felvételéhez [[Szoftvertechnológia]] tárgyból kredit megszerzése szükséges.)

===Szorgalmi időszakban===
*A kezdés feltétele, hogy az egyes hallgatók ''csapatokba szerveződjenek (4-5 fő)'', és ''konzultációs időpontot válasszanak'' maguknak. Ha ez explicit nem történik meg, a tárgyfelelős implicit módon a maradék embereket csapatokká kasztolja.
*A min. elégséges '''félévvégi jegy''' feltételei:
**A félév során kiadott '''11 feladat leadása''' (8 dokumentáció, 3 dokumentáció+szoftver). Egy feladat leadásának feltétele ''az összes előző feladat sikeres teljesítése''. A teljesítés feltétele a 3 szoftver fázisnál (Szkeleton, Proto, Grafikus) a kapható pontok 41%-nak teljesítése (ez rendre 9, 15, 17 pontot jelent), a többi feladatnál, hogy a konzulens a feladatot elfogadja (tehát itt nincs minimum pont követelmény).
*'''Pótlási lehetőségek:'''
**Késedelmes leadás esetén a kapható pontok ''naponta 10%-kal csökkennek'', tehát 10 nap késés esetén már biztosan nem jár pont (de ebben az esetben is le lehet adni a feladatot, hiszen ez a többi feladat teljesítésének feltétele). Késés esetén közvetlenül a konzulensnek, vagy a tanszéken lehet leadni az anyagot.
**Ha a konzulens egy feladatot ''nem'' fogad el, úgy azt a következő hétre (a következő beadandó feladattal együtt) újra be kell adni, ilyenkor a rá kapható pont a maximális pontszám 40%-a. Pótolni egy alkalommal lehet.
*'''Kontakt órák'''
**'''Gyakorlat:''' Heti egy alkalom (nem kötelező minden csapattagnak a részvétel).

===A vizsgaidőszakban===
*'''Vizsga:''' nincs.

===Félévvégi jegy===
*A feladatok részletes pontozása:
# Szkeleton (összesen 100 pont, ''min 41 pont'')
#* Követelmény, projekt, funkcionalitás (10 pont)
#* Analízis modell kidolgozása 1. (20 pont)
#* Analízis modell kidolgozása 2. (30 pont)
#* Szkeleton tervezése (20 pont)
#* Szkeleton beadása (20 pont, ''min 9 pont'')
# Proto (összesen 100 pont, ''min 41 pont'')
#* Prototípus koncepciója (20 pont)
#* Részletes tervek (45 pont)
#* Prototípus beadása (35 pont, ''min 15 pont'')
# Grafikus (összesen 100 pont, ''min 41 pont'')
#* Grafikus felület specifikálása (30 pont)
#* Grafikus változat beadása (40 pont, ''min 17 pont'')
#* Összefoglalás (30 pont)
*Mindhárom feladatrész 100 pontot ér. A sikeres teljesítéshez szükséges, hogy ''mindegyik ilyen blokkból a csapat legalább 41 pontot elér'' (és a ''blokkok végén található szoftver beadásra is legalább 41%-ot kap''). Ha ez a feltétel ''nem'' teljesül, az ''egyéni teljesítménytől függetlenül mindenki elégtelent kap'' a csapatban! Ha a minimum követelmények teljesülnek, úgy a Szkeleton (Sc), Proto (Pr), illetve Grafikus (Gr) feladatrészekre kapott pontok súlyozott átlagát kell venni, ahol a súlyok:
*<math>P= 0,3*Sc+0,5*Pr+0,2*Gr</math>
*Az így képzett átlag a csapat pontszáma. Ez a pontszám végül az egyes csapattagok kontribúciójának arányában oszlik el (ezt az arányt a csapat állapítja meg). Amennyiben ez az arány nem tükrözi a napló tartalmát, úgy a konzulens ezt az arányt a csapattagok részvételével (vagy akár anélkül) megváltoztathatja. A végső pontszám jegyre konvertálása az alábbi táblázat szerint működik:
:{|class="wikitable" align="center"
!P !!Jegy
|-
| 0 - 40 || 1
|-
| 41 - 54 || 2
|-
| 55 - 68 || 3
|-
| 69 - 82 || 4
|-
| 83 - 100|| 5
|}

==Jótanácsok==
* [[Szerkesztő:Madbence/Szoftver labor 4 tanácsok|Lennon tanácsai]] a tárgyhoz

=== Verzókezelés ===
Mindenképpen kell egy értelmes verzókezelő rendszer, ha dropboxon vagy haosnlón küldözgetitek, csak magatokkal toltok ki. Jelenleg (2014) működik a [https://git.sch.bme.hu kszk git verziókezelője], pár perc alatt el lehet sajátitani hozzá az alapokat: [https://www.atlassian.com/git/tutorials tutorial]

=== Doksi írás===
Érdemes olyan platformot választani, amit egyszerre mindenki tud használni, nem kell várni a másikra, illetve utólag összeollózni. Jelenleg a [https://drive.google.com Google Drive]nál nem tudok jobbat ajánlani.

=== Kommunikáció ===
Nem kell mindig találkozni, a lényeg, hogy legyen egy olyan közös csatorna, amit mindenki tud követni. Akár facebookbeszélgetés, akár levlista, a lényeg hogy mindig, mindenki kapja meg. (A kódokat viszont ne itt küldözgessétek...)

=== Kommentezés ===
Bármilyen függvényt írsz, mindig kommenteld oda, hogyan kell használni, mire szánod, mert a csapattársad nem tud olvasni a gondolataid között

=== Beadandó tartalmi követelménye ===
2017 tavaszán nekünk Goldschmidt Balázs volt a labvezünk, ezek az információk főleg tőle származnak.
* 2. Követelmény, projekt, funkcionalitás:
** Ennek a dokumentumnak a legfontosabb részei:
*** Funkciók: A feladat szövegében sok olyan részlet van, ami nincsen kifejtve, a csapatra van bízva, hogy ők hogyan képzelik el. Ebben a részben főleg az ilyen részleteket kell kifejteni, azaz úgy kell átfogalmazni a feladat szövegét, hogy abból minden egyértelmű legyen, ne lehessen részeket többféleképpen értelmezni.
*** Követelmények: Ennek összhangban kell lennie a Funkciók résszel, a szövegben főleg az igékre fókuszálva célszerű kigyűjteni ezeket. (ajánlott legalább 15-20 követelmény megfogalmazása) Ez alapján a use-case-ek meghatározása már könnyű.
*** Szótár: Mindent fontos benne meghatározni, nem szabad olyan fogalomnak maradnia a korábbi részekben, ami itt nincsen egyértelműen meghatározva. Természetesen nem csak a mennyiség, hanem a minőség is fontos. A funkciók olvasása közben könnyen kigyűjthetőek ezek a fogalmak. Ajánlott, hogy több ember is olvassa át ezt, mert ekkor még a csapatban nem alakul ki egy tlejesen közös kép a feladatról, és emiatt mindenki a saját elképzelését fogalmazza meg, így fellelhetőek az olyan részek, amik nem lettek még a csapaton belül normálisan tisztázva.
** Többi rész főleg a dokumentum keretbe foglalásáért felelős, de azok kitöltése is követelmény.
* 3. Analízis modell kidolgozása 1:
** Objektum katalógus: Ennél a résznél még nem osztályokban kell gondolkodni, hanem a feladatot olvasva ki kell gyűjteni az entitásokat. Ez alapján utána könnyebben lehet az osztályokat meghatározni. Itt még nem szabad az osztályoknak, interfészeknek, öröklésnek megjelennie.
** Statikus struktúra diagram (osztály diagram), szekvencia diagram: Ezt a két részt együtt ajánlott készíteni, hiszen az osztálydiagram hibái előkerülnek a szekvenciák megfogalmazása közben és fordítva is igaz. Fontos az összhang, azaz ami megjelenik az osztálydiagramon, az legalább egy szekvencián is szerepeljen, és ami a szekvencia diagramokon rajta van, az az osztálydiagramon is kell, hogy szerepeljen. Nagyságrendileg 20 szekvenciadiagram ajánlott.
** Osztályok leírása: Jellemzően csak szöveg gyártásáról szól ez a rész az eddig elkészítettek alapján.
** State-chartok: Nálunk az hangzott el, hogy nem túl fontos, csak tényleg akkor rakjunk bele, hogyha van olyan része a feladatnak, amit jól jellemez.
* 4. Analízis modell kidolgozása 2:
** Általában az előző részt nem szokta senki sem elsőre jól megcsinálni, emiatt mégegyszer meg lehet próbálni. A labor vezetők rá fognak mutatni az előző beadandó hibáira, és legalább azokat ajánlott javítani a jó pontért. Természetesen aki az előzőt jobbra megcsinálta, annak itt kvesebb tennivalója van.
* 5. Szkeleton tervezése:
** A szekelton lényege, hogy a korábban megfogalmazott működést kellene egyszerű konzolos felületen keresztül bemutatnia, azaz nyomon kell tudni követni egy adott szekvenciát például.
** Sok (>10) use-case-t ajánlott megfogalmazni, nagyjából a program teljes működését le kellene velük fedni.
** A menüben az előtte megfogalmazott use-case-ek közül kell tudni választani, aminek hatására elindul egy szekvencia végrehajtása. Fontos, hogyha a szekvenciát valamilyen döntési feltétel van (opt, alt), akkor azt a felhasználótól meg kell kérdezni, hogy ez most igaz vagy hamis. Akár az is lehetséges, hogy a felhasználónak előre elmondjuk (kiírjuk), hogy a várt végrahajtáshoz milyen válaszokat kell adnia a megjelenő kérdésekre.
** A konzolra a függvény meghívását (a paramétereivel együtt akár) és a visszatérését is ki kell írni (identálás - tabulátorok használata erősen javasolt).
** Kommunikációs diagramok: UML2-ben objektum diagram nincsen, és ennek a résznek az lenne a lényege, hogy az objektumok közötti kapcsolatokat megjelenítse, azaz a szekvencia diagramok felülnézetét. Nálunk azt mondta Goldschmidt Balázs, hogy itt nem kell megjelennie az üzenetváltásoknak, hiszen azok a szekvencia diagramokon már szerepelnek, azaz itt csak össze kell kötni azokat az objektumokat (nem osztályokat), amik a szekvencia diagramokon szerepelnek, tehát egy szekvencia diagramhoz alapvetően tartozik egy "kommunikációs diagram" is.
* 6. Szkeleton beadása:
** Az első rész vége, tartalmaznia kell egy értékelést is, ahol a tagokra bontva megjelenik, hogy ki mekkora százalékban járúlt hozzá az első rész elkészítéséhez (aláírás javasolt a nevek mellé).
** A dokumentum többi részének a kitöltése értelemszerű.
** Ennél a résznél a program elkészítése az, amire több időt kell fordítani.
* VÁLTOZÁSOK:
** A szekelton beadását követően előszeretettel csinálnak valami módosítást a feladat kiírásában (erről emailben értesítenek mindenkit). Általában ez olyan változás, amit jól elkészített modell esetén könnyű elkészíteni. A következő dokumentum elején ezeket a változásokat meg kell jeleníteni, azaz célszerű egy összefoglalást írni a változásról, majd utána a módosított/új osztály és szekvencia diagramokat kell elhelyezni a dokumentumban.
* 7. Prototípus koncepciója:
** Nagyjából ezt a részt úgy kell elképzelni, mint a szkeleton általánosítását, azaz adott funkciók nem "bedrótozva" vannak, hanem a programunk parancsokat értelmez, és a parancsoknak megfelelő funkcionalitást hajtja végre. Gyakorlatilag ezzel a programnak a modell része majdhogynem teljesen kész lesz, csak a grafikus rész fog hozzákerülni, de az is ehhez hasonló interfészt fog használni.
** A parancsok beolvasására a konzolról célszerű egy segéd osztályt felvenni, amire jó eséllyel nem lesz már szükség a grafikus résznél.
** A parancsok definiálásának egyértelműnek kell lennie, azaz még azt is jelölni, kell, hogy a parancs paraméterezésénél milyen elválaszt karakter van, mi a paraméterek sorrendje, azok mit jelentenek.
** A use-case-ek megfogalmazása ezek alapján nem túl nehéz feladat.
** Tesztelési tervnél a program fontosabb funkcióit legalább le kell fedni. Hogyha van olyan rész, ami több esetben ugyanúgy működik és lényegében csak a megjelenítésben lesz különbség, akkor nem kell többszörösen elkészíteni az adott tesztet.
** Nem ajánlott JUnit vagy valami ehhez hasonló környezetben gondolkodni, mert csak feleslegesen elbonyolítja a helyzetet, bőven elég karakterese bemenetre és kimenetre gondolni.
* 8. Részletes tervek:
** Az előző rész részletezéséről szól ez a dokumentum.
** Az osztályok leírása nagyrészt csak copy-paste a korábban beadott leírásokból.
** Tesztek részletes terveinél az előző dokumentumban definiált nyelvnek megfelelően kell megfogalmazni. Ajánlott tesztenként külön txt-be gyűjteni (főleg a bemenetet), mert később jól fog jönni.
* 10. Prototípus beadása:
** A második blokk vége ez a doksi, úgyhogy ismét kell bele értékelést rakni.
** A dokumentum kitöltése nagyjából értelemszerű, hasonlít az előző ilyenhez.
** Tesztelési jegyzőkönyveknél ajánlott nem csak sikereseket belerakni (mindegyik definiált teszthez kell lennie sikeresnek), hanem egy-két hibás is legyen, hogy látszódjon, hogy van értelme a teszteknek, meg az azért valószínű, hogy elsőre úgysem volt hibátlan a kód, és ez látszódjon a dokumentációban is.
** Teszt bemeneteket ajánlott txt formátumban is mellékelni a beadásnál, mert a tesztelést végző csapatnak nem túl kellemes élmény lehet mindent kézzel beírni.
** A programnak működnie kell úgy is, hogy a bemenetét szöveg fájlból kapja, azaz parancssorban a mellékelt txt fájlokat beleirányítjuk. (nem fájlbeolvasó függvényekre kell gondolni)
* 11. Grafikus felület specifikációja:
** Java Swing-ben kötelező gondolkozni, JavaFX-et el kell felejteni!
** Grafikus interfésznél ajánlott szövegesen leírni, hogy a funkciót hogyan képzeljük el, és néhány (akár paint-ben készült) képpel illusztrálni.
** Felület működési elvénél meg kell fogalmazni, hogy a grafikus megjelenítésért felelős osztályok és a modell osztályok között milyen jellegű kapcsolat van. Alapvetően mindegyik osztályhoz tartozik egy csomagoló/wrapper osztály, amiben a grafikus megjelenítésért felelős kódrészek vannak, de a működésért felelős információk továbbra is a modell osztályban kell maradniuk, azaz az eddig elkészített kódrészekhez nem igazán kell hozzányúlni majd. Alapvetően kétféle megközelítés van: a garfikus rész kérdezi le a modell osztályoktól, hogy hogyan rajzolja ki magát vagy a modell osztályok szólnak, hogy változás történt és rajzold ki magad. A szekvenciáknál az elképzelt elvet be kell mutatni, hogy hogyan fog majd működni, tehát legalább 5-10 diagram kellhet a normális részletezettséghez.
* 13. Grafikus változat beadása:
** Ezzel együtt kell beadni a kész programot is.
** Ismét kell bele értékelést írni a tagok hozzájárulásáról.
* 14. Összefoglalás
** A ráfordított munkaórák alapján a korábban megadott százalékokon akár módosíthat a labvez, hogyha úgy látja, hogy a kettő nincs összhangban.
** A vélemény nem számít bele a kapott jegybe, de azért illik normálisan kitölteni.
(A leírtakért felelősséget nem vállalok, nálunk ezek az elvek voltak igazak, bár tapasztaltuk, hogy labvezenként kisebb/nagyobb eltérés volt, de nincs rá garancia, hogy nálatok is ezek igazak lesznek. Ajánlott laborra úgy menni, hogy előre megnézitek, hogy mit kell a héten csinálni, és akár az itt felsoroltak segítségével kérdéseket fogalmazzatok meg magatokban, és ezekre a kérdésekre a labvezek egyértelmű választ tudnak adni. Csak a doksiban leírt kék szövegek alapján elég nehéz a doksi elkészítése. Tényleg ajánlott figyelni a labor során, mert kellemetlen, amikor másoktól kell információmorzsákat összeszedni, mert éppenséggel senki sem figyelt kellő mértékben a laboron, vagy mindenki másra emlékszik.)

==Feladatok==
{{Rejtett
|mutatott= '''2016/17 tavasz - Vonatos'''
|szöveg=
Sheldon terepasztalt épít vonatjai számára. A terepasztal széleiről időnként vonatok indulnak. Egy vonat egy mozdonyból és valahány kocsiból áll. A kocsikban utasok ülnek, akiket a megfelelő állomásokra kell eljuttatni a megfelelő sorrendben.

A terepasztalon sínek futnak, a vonatok csak a síneken közlekedhetnek. Elágazásoknál a síneket váltók kötik össze. Egy vonat mindig abba az irányba halad tovább, amerre a váltó áll. Bizonyos helyek különlegesek a pályán, ezeken a helyeken egy alagút száját lehet felépíteni vagy megszüntetni. Egyszerre maximum csak két alagútbejárat lehet megépítve a pályán. A két bejáratot egy speciális alagút köti össze, és ha a vonat bemegy az egyik szájon, akkor a másikon jön ki. Az alagút lehet rövidebb is, mint a vonat hossza, és a vonat alagútban lévő része nem látható.

A sínek mellett különböző színű állomások lehetnek. A vonatok kocsijainak is van színe, és amikor egy vonat egy állomáson átrobog, az állomáson csak azok az utasok ugranak le, akik ugyanolyan színű kocsiban utaznak, mint amilyen az állomás színe. A kocsik azonban csak a mozdonytól kezdődő sorrendben ürülnek ki. Tehát hiába ér a vonat egy olyan állomásra, amely megegyezik az utolsó kocsi színével, az utasok nem fognak onnan leszállni, amíg a korábbi kocsik még nem ürültek ki.

A játékos a váltókat tudja állítani, illetve alagútszájakat tud építeni vagy megszüntetni. A játék célja, hogy minden utas eljusson a megfelelő állomásra anélkül, hogy a vonatok egymással összeütköznének. Ha két vonat összeütközik, a játékos veszít. Miután egy terepasztalt sikerült teljesíteni, a játék a következő pályával folytatódik.

'''Módosítás'''
# Sheldon új pályaelemet, kereszteződő síneket vásárolt. A kereszteződés egyszintű, a különböző irányokból jövő vonatok a kereszteződésben ütköznek.
# Egyes állomásokon utasok a megfelelő színű üres kocsikba (a kocsi szerelvényben elfoglalt helyzetétől függetlenül) fel tudnak szállni.
# Sheldon bővítette a vagonkészletét. Vett szeneskocsikat, amiken nem utaznak utasok, nem is tudnak felszállni. Az utasok leszállásánál az ilyen vagonokat nem vesszük figyelembe.

A változásokkal kapcsolatos modellmódosításokat már a március 27-ei, Prototípus koncepciója c. beadandó anyagban is figyelembe kell venni. Az anyagnak legyen egy 0. fejezete, ami tartalmazza a módosítással kapcsolatos szöveges elemzést, a frissített osztálydiagramot, valamint a fenti pontok sorrendjében a módosult és új szekvenciadiagramokat.
}}

==Befejezett projektek galériái==
* [[Szoftlab4_Kindergarten_galéria_2006|Kindergarten Galéria 2006]]
* [[SzgLab4Galeria2008|SnakeFarm Galéria 2008]]
* [[SzgLab4Galeria2010|Bankrabló Galéria 2010]]
* [[SzgLab4Galeria2012|Continuity Galéria 2012]]
* [[Szoftlab4_AntFarm_galéria|AntFarm Galéria 2013]]
* [[Szoftlab4_Két_Torony_galéria|Két Torony Galéria 2014]]

==Csapattoborzás==
Ha nincs csapatod, [https://lists.sch.bme.hu/wws/arc/szoftlab4 levlistán] érdemes szóvá tenni, a legkönnyebben ott lehet csapatot verbuválni. Mivel a csapatban mindenképpen szükség lesz jó kóderre, dokumentálóra, érdemes az ilyen jellegű igényeket is beleírni a toborzó emailekbe. Viszont azt, hogy ''szeretném elvégezni a tárgyat'', lehetőleg ne, hisz én még nem találkoztam olyan emberrel, aki azért vette föl, mert ''nem'' szeretné elvégezni. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 21:32 (CET))

{{Lábléc_-_Mérnök_informatikus_alapszak_2014}}
{{Lábléc_-_Mérnök_informatikus_alapszak}}

Operációs rendszerek

2018-04-17T08:08:16Z

Schulcz Ferenc: /* Segédanyagok */ Fakultatív házi hozzáadása

{{Tantárgy
|nev=Operációs rendszerek
|tárgykód=VIMIAB00
|régitárgykód=VIMIA219
|szak=info
|kredit=5
|felev=4
|kereszt=vizsgakurzus
|tanszék=MIT
|kiszh=nincs
|hf=fakultatív
|nagyzh=1 db
|labor=6 db
|vizsga= írásbeli
|szak=info
|levlista=opre@sch.bme.hu
|targyhonlap=http://www.mit.bme.hu/oktatas/targyak/vimiab00
}}

==Követelmények==

=== Előtanulmányi rend ===
[[Számítógép architektúrák]] tárgyból aláírás megszerzése szükséges a tárgy felvételéhez.

=== A szorgalmi időszakban ===
*Az '''aláírás''' megszerzésének feltétele:
**A '''ZH''' sikeres (min 40%) megírása.
**Hatból négy '''labor''' legalább teljesítése. A labor elején beugrót iratnak a kiadott segédanyagokból.
*'''Megajánlott jegy:'''
**4 kiválóan megfeleltre értékelt labor
**legalább öt szorgalmi házi pont (összesen 9-12 szerezhető)
**legalább 33 pontos (66%) zárthelyi
**megajánlott jegy csak az aláírás megszerzésének félévében adható
**a megajánlott érdemjegy a vizsga értékelési táblázata szerinti, összpontszám = 1.5 * ZH pontszám + HF pontok
*'''Pótlási lehetőségek:'''
**A ZH egyszer félév közben pótolható. Ha van PPZH is, azt a tárgy adatlapján feltüntetik, ott keresd.
*'''Elővizsga:''' nincs.

===A vizsgaidőszakban===
*'''Vizsga:''' írásbeli. Két részből áll, amelyek 10 és 50 (35+15) pontosak. Az elégséges vizsgához az első (beugró) részén legalább 6 pontot, a második (teszt és számítási feladat) részén legalább 20 pontot kell szerezni. A beugró teljesítése a vizsga folytatásának feltétele. (Mivel nem tudják ott azonnal kijavítani, így a vizsga folytatható, csak a beugró nem teljesülése esetén a vizsga második részét nem javítják ki.) A beugró pontszáma nem számít bele a félévvégi jegybe.
**Előfeltétele: az aláírás megléte.

===Félévvégi jegy===
*A jegyet adó pontszámot (P) az aktuális félévben aláírást szerzőknél a ZH, a vizsga második felének (V2) pontszáma, és a fakultatív házi feladatokra kapott pontszám adja a következő módon:
*<math>P= V_2 + {\frac {ZH} {2}} + HF</math>
*Aki korábban szerzett aláírást, annál:
*<math>P= 1.5 * V_2</math>
*''A vizsga első felének (a beugrónak) a pontszáma a végső jegybe nem számít bele, csak a vizsga folytatásának feltétele!''
*Ponthatárok:
:{| class="wikitable" align="center"
|-
! P !! Jegy
|-
|0 - 29 || 1
|-
|30 - 39 || 2
|-
|40 - 49 || 3
|-
|50 - 59 || 4
|-
|60 - 75+ || 5
|}

== Segédanyagok ==

'''A tárgy tematikája 2016 tavaszától jelentősen módosult, a korábbi segédanyagok nem, vagy csak korlátozott mértékben használhatóak.'''

=== Könyv ===
* A tárgy honlapján bejelentkezés után elérhető egy, a tárgyhoz készített terjedelmes jegyzet. Ezt 2017-ben kezdték el írni, akkor még hiányos volt.
Kicsit régebbi könyvek, amik nem a tárgyhoz készültek, de sok dolog felhasználható belőlük:
* Kóczy A., Kondorosi K. (szerkesztők): [http://www.tankonyvtar.hu/hu/tartalom/tkt/operacios-rendszerek/adatok.html Operációs rendszerek mérnöki megközelítésben], Panem Kiadó, Budapest, 2000.
** a tárgy általános részét részben lefedi a könyv 17. és 211. oldalak közti része
* Silberschatz, Peterson: Operating System Concepts vagy Operating Systems Concept with JAVA (7. vagy későbbi kiadás)

=== Opre nemhivatalos jegyzet ===
Legfrissebb változat: [[Media:OPRE_jegyzet.pdf|OpreJegyzet]]
* NEM HIVATALOS JEGYZET: nincs benne minden, vannak benne hibák/elírások
* 2011-es anyagot tartalmazza
* utolsó szerkesztés dátuma: 2011 nyár
* Továbbfejlesztési lehetőségek:
** Minden évben szükséges lenne frissíteni az aktuális anyagokkal és kiegészíteni, újabb "kiadásban" feltölteni!
** [[Szerkesztő:Ferrero| a készítő elérhetősége]], vele egyeztetve lehet elkérni a forrást és továbbfejlesztésről érdeklődni (mely mindenki számára nyitott, csak pár tanácsot adna)

=== Diák ===
* A tárgyhonlapon belépés után megtalálod az aktuális félév diasorait, pár hét késéssel mindegyiket feltöltik.
* [[Operációs rendszerek - Régi képzés diái|Régi képzés diái]]

=== Egyéb segédanyagok ===
* [[Media:opre_mindmap_altalanos.png|Opre általános MindMap]], nem hivatalos [[Media:opre_mindmap_kidolgozas.pdf|kidolgozása]]
* [[Media:opre_mindmap_windows.png|Opre Windows MindMap]]
* [[Media:opre_feladatok_segedanyag.pdf|Számolási példák és algoritmusok]]
* [[Media:opre_raidosszefoglalas_20140610.pdf|RAID összefoglaló a diasor alapján]]
* [[Media:Opre_Vizgya_Jegyztet_2014_tavasz.pdf|2014 tavaszi félév előadásdiáinak tömör jegyzete (41.o)]]
* [[Media:opre_szalkezeles_Csharp_jegyzet.pdf|Szálkezelés C# nyelven]]

=== Videó ===
2011. őszén felvették a tárgy előadásait, [http://bme.videotorium.hu/hu/channels/details/900,Operacios_rendszerek itt megtekinthető]

===Fakultatív házik===
* Egy 2018-as, 3/3 pontos HF1 [https://git.sch.bme.hu/schulczf/taskscheduler megoldás]

== Laborok ==
A félév folyamán hat kétórás labort kell teljesíteni három témakörben. A 6 labort elvégezheted 3 nap alatt is, mert úgy vannak beosztva a laborok, hogy kettő egymás után kezdődik. Érdemes elvégezni az egy témakörbe tartozó feladatokat egy napon, mert sok feladat az előző feladatokra épült, vagy felhasználja a benne tanultakat.

A feladatokat a tárgyhonlapon találod meg. A rendszer lehetővé teszi, hogy a labor ideje előtt is feltöltsd a feladatokat. Így ha akarod, akár otthon is elkészítheted őket. Ettől még be kell menned a laborra a beugrót megírni, ott megvárhatod, amíg kijavítják a feladataidat, a hibásakat még tudod javítani. Ezt a módszert akkor érdemes kihasználnod, ha tudsz önállóan dolgozni, és kiválóan megfeleltet akarsz szerezni. Ez persze a beágyazott labornál nem működik, ahhoz kell az eszköz is.

=== Windows ===
[[Kidolgozott beugrókérdések]]

=== Linux ===

[[Media:Ellenorzo_kerdesek_Linux.pdf | Kidolgozott beugrókérdések]]

=== Beágyazott rendszerek ===
[[Media:Beágyazott operációs rendszerek - kidolgozott ellenőrző kérdések.pdf|Kidolgozott beugrókérdések]]

== ZH ==


A ZH 50 pontos, 20 ponttól van meg.
==== Számolós példára lehetőségek ====
* Alap ütemezési algoritmusok
* Klasszikus UNIX ütemezés
* Holtpont bankár algoritmus
* Memória foglalás
* Lapcsere algoritmusok

==== Zárthelyi feladatsorok ====
[[Media:Opre_zh_2016_minta.pdf | MintaZH (2016 tavasz)]]

==Vizsga==
A tárgyból írásbeli vizsga van, ami két részből áll. Beugró és nagyfeladat. A beugrót csak a nagyfeladat megírása után javítják ki. Aki a beugró alapján reménytelennek tartja a helyzetét, a beugró után elmehet. Eredmények a tárgyhonlapra kerülnek fel, ott olvashattok a megtekintések időpontjáról is.

=== Beugró ===
* A 10 elméleti kérdésböl 6-et kell megválaszolni.
* Elméleti kérdéseket tartalmaz, tehát a beugró teljesítéséhez tudni kell az anyagot részletesen.
* [[Media:Opre_vizsgabeugro_minta_2017.pdf|Minta beugró "kérdések" 2017]]

=== Nagyfeladatlap ===
* A beugrót követi a nagyfeladatlap kitöltése. A nagyfeladatlap 35 tesztkérdést, és egy, 15 pontos számítási példát tartalmaz. A vizsgában nagyobb arányban szerepelnek benne Windows, UNIX/Linux, virtualizáció, biztonság, stb. kérdések a ZH-hoz képest.

== Régi képzés feladatsorok==
'''A tárgy tematikája 2016 tavaszától jelentősen módosult, az előadó nem javasolja a régi képzés feladatsorainak segítségével való felkészülést.'''
{{Rejtett
|mutatott= 
|szöveg=
==== Régi képzés - Zárthelyi feladatsorok ====

* [[Media:opre_2010_mintazh.pdf|2010-es MintaZH]], [[Media:opre_2010_mintazh_megoldas.pdf|megoldása]]
* [[Media:opre_2011_mintazh.pdf|2011-es MintaZH]]
* [[Media:opre_20100426_ZH_megoldas.pdf|2010.04.26. ZH megoldással]]
* [[Media:opre_20100507_ZH_megoldas.pdf|2010.05.07. ZH megoldással]]
* [[Media:opre_20100520_ZH_megoldas.pdf|2010.05.20. ZH megoldással]]

==== Régi képzés - Beugró kidolgozások ====
* [[OpReVizsgaBeugrokMegoldassal|Vizsgabeugrók és azok megoldásai ÖSSZEGYŰJTVE, ABC-rendbe szedve, egy helyen]] (javítsátok, egészítsétek ki! :) ) -- [[PeteHaro|Pete]] - 2011.06.19.
* [[OpReVizsgaKisKerdesek|Kidolgozott beugró kérdések]] - nem hibátlan, aki hibát talál benne javítsa

==== Régi képzés - Beugró feladatsorok ====
* [[Media:opre_vizsga_beugro_20110606.pdf|2011.06.06. beugró]]
* [[Media:opre_vizsga_beugro_20110523.pdf|2011.05.23. beugró]]
* [[Media:opre_vizsga_beugro_20110117.pdf|2011.01.17. beugró]]
* [[Media:opre_vizsga_beugro_20110111.pdf|2011.01.10. beugró]]
* [[Media:opre_vizsga_beugro_20101220.pdf|2010.12.20. beugró]]
* [[Media:opre_vizsga_beugro_20100615.pdf|2010.06.15. beugró]]
* [[Media:opre_vizsga_beugro_20100608.pdf|2010.06.08. beugró]]
* [[Media:opre_vizsga_beugro_20100601.pdf|2010.06.01. beugró]]
* [[Media:opre_vizsga_beugro_pelda.pdf|2010-es minta beugró]], [[Media:opre_vizsga_beugro_pelda_megoldas.pdf|megoldása]]

==== Régi képzés - Igaz-hamis ====
[[Operációs rendszerek - Igaz-hamis vizsgakérdések|Igaz-hamis kikérdező]]

==== Régi képzés - Nagyfeladatlap feladatsorok és kidolgozások ====
* [https://docs.google.com/document/d/1sI2li2AO9_b91PuSzumuGAtljoWZyonHJ7SyTGPiGDE/edit#heading=h.s6w19lpyy18v 2014-2015 vizsgák nem hivatalos kidolgozása]
* [[Media:opre_vizsga_20100615_megoldas.pdf|2010.06.15. vizsga nagyfeladata hivatalos megoldással]]
* [[Media:opre_vizsga_20100608_megoldas.pdf|2010.06.08. vizsga nagyfeladata hivatalos megoldással]]
* [[Media:opre_vizsga_20100601_megoldas.pdf|2010.06.01. vizsga nagyfeladata hivatalos megoldással]]
* [[Media:opre_vizsga_20100125.jpg|2010.01.25. vizsga nagyfeladata]]
* [[OpReVizsga20100118PrioritasInverzio|2010.01.18. vizsga nagyfeladatai nem hivatalos megoldás]]
* [[Media:opre_vizsga_20100106.jpg|2010.01.06. vizsga nagyfeladata]]
* [[OpReVizsga20090615|2009.06.15. vizsga nagyfeladatai]]
* [[OpReVizsga20090608|2009.06.08. vizsga nagyfeladatai]]
* [[Media:opre_vizsga_20090122.jpg|2009.01.22. vizsga nagyfeladata]]
* [[Media:opre_vizsga_20090112.pdf|2009.01.12. vizsga nagyfeladata]]
* [[Media:opre_vizsga_20081222.jpg|2008.12.22. vizsga nagyfeladata]]
* [[Media:opre_vizsga_20081215.jpg|2008.12.15. vizsga nagyfeladata]]
* [[OpReVizsga2008junius19|2008.06.19. vizsga nagyfeladatai]]
* [[OpReVizsga2008junius11megoldas|2008.06.11. vizsga nagyfeladatai és beugró nem hivatalos megoldással]]
* [[OpReVizsga2008majus20megoldas|2008.05.01. vizsga nagyfeladatai és beugró nem hivatalos megoldással]] '''(hiányzik: beugró 3 nagykérdések 2)'''
* [[OpReVizsga2007junius12megoldas|2007.06.12. vizsga nagyfeladatai és beugró nem hivatalos megoldással]] '''(hiányzik: nagykérdések 1, 2, 3)'''
}}

== Kedvcsináló ==
[[OpReKedvcsinalo|Kedvcsináló]]

==Észrevételek==
* Érdemes a megajánlott jegyet megszerezni a tárgyból. A ZH valamivel egyszerűbb, mint a vizsga, a laborokból összehozható a 4 kiválóan megfelelt, a szorgalmi házikkal alig van munka.
*Több probléma is akad a tárgy wiki adatlapjával ill. a felkészüléssel kapcsolatban:
** Hiányos, hibás kidolgozások. Arról van szó, hogy hibás/téves információkat tanulunk meg belőlük.
** Magolás, beugrókérdések betanulása. Amikor nem az anyagrész megértése, hanem a "beseggelése" történik. Vizsgán gyakran szokott olyan történni, hogy felteszik a kérdés ellenkezőjét, vagy kicsit változtatnak rajta. Az a tapasztalat, hogy az emberek ilyenkor is a standard (wikis bemagolt) választ adják vissza, ami természetesen nem jó.
** A wikin található tartalomért, az esetlegesen hiányzó anyagrészekért és az előforduló hibákért nem vállalunk felelősséget. Konzultáltunk az oktatókkal: szerintük minden előadáson elhangzott anyag szerepel, a jelenlegi állapot már alkalmas lehet egy sikeres zh/vizsga felkészüléshez. Ha hibát / hiányosságot találtál az oldalon található anyagokban, vagy esetleg téves információt közöltünk, kérlek írj a tárgy levelezési listájára, vagy a vitalapra.

{{Lábléc_-_Mérnök_informatikus_alapszak_2014}}
{{Lábléc_-_Mérnök_informatikus_alapszak}}

IMSc

2017-12-07T18:42:35Z

Schulcz Ferenc: Félreérthetőség javítása

A hazai gazdaság és tudományos kutatás élvonalbeli szegmensei által igényelt, elméletileg is jól felkészült, magas szellemi hányadú, csúcstechnológiákat alkalmazó, innovatív kutatási-fejlesztési tevékenységre képes fiatal mérnökhallgatók tehetséggondozási célú képzési programja.

==Miről szól==
*Tehetséges diákok felkarolása
*Mélyebb tudás megszerzése
*Szakmai tapasztalatszerzés
*Ösztönzés az MSc elvégzésére

==Követelmények==
===Bekerüléshez===
*'''Gólyák''' esetén:
**Matematika, fizika, informatika II. OKTV, Informatikai alapismeretek, esetleg elektronikai alapismeretek SZÉTV '''tanulmányi versenyek 1-10 helyezettjei (ők automatikusan bekerülnek,''' ha akarnak) ''VAGY''
**'''Emelt szintű érettségi''' matematikából vagy fizikából ''VAGY''
**A fenti tárgyak egyikéből '''OKTV tanulmányi verseny 11-30. helyezett'''
:Felvételi döntés a létszámkorlát figyelembevételével meghatározott minimumpontszám alapján történik. A pontszámba a felvételi pontszám számít bele, és az egyes versenyeredményekért, második emelt szintű érettségikért pluszpontok kaphatók. 
*Lehetőség van a '''képzés során később,''' valamelyik szemeszter előtt is becsatlakozni, '''mintatantervi haladás, és legalább 4.0 súlyozott tanulmányi átlag''' esetén.

===Bennmaradáshoz===
*mintatantervi haladás
*>='''4.0''' súlyozott tanulmányi átlag minden félévben
Semmilyen negatív következménnyel nem jár, ha nem sikerül tartani - ekkor a hallgató átsorolódik normál képzésre, és a fenti feltételek teljesítése után a félév végén akár vissza is kerülhet.

==Előnyök és hátrányok==
'''Előnyök:'''
*Gyorsabb haladási ütem (BSc + MSc képzéshez képest '''fél évvel korábban végzel''')
*Minden hallgató kap maga mellé egy '''mentort''', aki segít minden felmerülő kérdésben
*'''Érdekesebb''' és egyben '''nehezebb''' feladatok gyakokon, így a ZH feladatai könnyebbnek tűnnek majd
*Kisebb gyakorlat- és laborcsoportok kizárólag IMSc-seknek, így minden félévben lesz egy értelmesen összerakott órarended, és tárgyfelvételnél nem kell aggódni a helyeken
*Szakonként és évfolyamonként a legjobban teljesítő 5-5 hallgató IMSc '''ösztöndíjat''' kap
*Erősebb tudást ad
'''Hátrányok:'''
*'''Kiforratlan''' rendszer (2016-ban indult, néha maguk a gyakvezek sincsenek teljesen tudatában a szabályoknak)
*Engedély nélkül '''nem szabad dolgozni''' egyetem mellett
*Az előre megadott gyakorlat- és laborcsoportok miatt az '''órarended fix''', kevés a variációs lehetőség
*Ha IMSc pontokat is akarsz gyűjteni (bár ez '''nem kötelező'''), '''többet kell tanulnod,''' így kevesebb szabadidőd marad

==IMSc pontok==
IMSc pontokat IMSc és normál képzésen is, szorgalmi feladatok megoldásával lehet szerezni. Ilyesfajta pluszfeladatok előfordulhatnak ZH-kban, vizsgákon és házifeladatokban, tantárgytól függően. Persze a meg nem oldásuk nem jár semmilyen negatív következménnyel, nélkülük is lehet 100%-os ötöst csinálni. 
Minden tantárgyból a kreditértéke ötszörösének megfelelő IMSc pont adható, és (egyelőre) főleg az IMSc-ösztöndíjak megítélésénél játszik szerepet az, hogy kinek mennyi pontja van.

==Vélemények==
*A program elindulásával egyidőben léptem be az IMSc-be, és nekem megérte. Tényleg sokkal több tudást ad, és motiválóbb - ráadásul legtöbbször mi kapjuk a legjobb tanárokat. Szerintem az emberek sokkal jobban félnek ettől a képzéstől, mint kellene. Ha nem tudod hozni a négyes átlagot, akkor visszakerülsz normál képzésre, és kész, ahol nem lesz hiányosságod, mert amit ők tanulnak, azt mi is. Amiben nekünk pluszmunkánk van, az némi extra IMSc-tananyag, de ezeket csak IMSc-pontokért kérik számon, tehát egyfajta szorgalmi feladat ez is. - [[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2017. június 17., 18:54 (UTC)

*Kicsit olyan mint orosz rulettezni patronos pisztollyal, vagy bejön és úgy érzed: "Igen, ezt is megcsináltam", vagy egy kicsit cseng a füled, meg fura érzés van az orrodban majd egy enyhén kellemetlen élménnyel távozol, de komoly károk nélkül. Alapképzésen kezdtem, aztán lett elég átlagom arra hogy csatlakozzak, szóval gondoltam miért ne. Nekem tetszik hogy kisebb csoportokban vagyunk, és az extra feladatok is jó kihívást jelentenek. Azoknak akik úgy érzik, hogy szívesen kipróbálnák magukat valamennyivel hajtósabb gyakorlatokon csak ajánlani tudom. Főleg mivel lement az első kör és kevésbé valószínű az olyan irányú meglepetés, hogy ja ebből is külön előadás lesz. (Ja igen, és én még eddig úgy vagyok vele, hogy igen, ezt is megcsináltam.)

==Hivatkozások==
*[https://www.vik.bme.hu/page/998/ A 2016-os hivatalos kari tájékoztató]
*[https://www.vik.bme.hu/document/829/original/3/00003967.pdf A kar tájékoztatója bővebben, 2016-ból (pdf)]
*[http://www.vik.bme.hu/hir/2076-imsc-program---ujabb-csatlakozasi-lehetoseg 2017 júniusi kari tájékoztató IMSc-seknek]

IMSc

2017-06-17T19:29:49Z

Schulcz Ferenc: /* Vélemények */

A hazai gazdaság és tudományos kutatás élvonalbeli szegmensei által igényelt, elméletileg is jól felkészült, magas szellemi hányadú, csúcstechnológiákat alkalmazó, innovatív kutatási-fejlesztési tevékenységre képes fiatal mérnökhallgatók tehetséggondozási célú képzési programja.

==Miről szól==
*Tehetséges diákok felkarolása
*Mélyebb tudás megszerzése
*Szakmai tapasztalatszerzés
*Ösztönzés az MSc elvégzésére

==Követelmények==
===Bekerüléshez===
*'''Gólyák''' esetén:
**Matematika, fizika, informatika II. OKTV, Informatikai alapismeretek, esetleg elektronikai alapismeretek SZÉTV '''tanulmányi versenyek 1-10 helyezettjei (ők automatikusan bekerülnek)''' ''VAGY''
**'''Emelt szintű érettségi''' matematikából vagy fizikából ''VAGY''
**A fenti tárgyak egyikéből '''OKTV tanulmányi verseny 11-30. helyezett'''
:Felvételi döntés a létszámkorlát figyelembevételével meghatározott minimumpontszám alapján történik. A pontszámba a felvételi pontszám számít bele, és az egyes versenyeredményekért, második emelt szintű érettségikért pluszpontok kaphatók. 
*Lehetőség van a '''képzés során később,''' valamelyik szemeszter előtt is becsatlakozni, '''mintatantervi haladás, és legalább 4.0 súlyozott tanulmányi átlag''' esetén.

===Bennmaradáshoz===
*mintatantervi haladás
*>='''4.0''' súlyozott tanulmányi átlag minden félévben
Semmilyen negatív következménnyel nem jár, ha nem sikerül tartani - ekkor a hallgató átsorolódik normál képzésre, és a fenti feltételek teljesítése után a félév végén akár vissza is kerülhet.

==Előnyök és hátrányok==
*Gyorsabb haladási ütem (BSc + MSc képzéshez képest '''fél évvel korábban végzel''')
*Minden hallgató kap maga mellé egy '''mentort''', aki segít minden felmerülő kérdésben
*'''Érdekesebb''' és egyben '''nehezebb''' feladatok gyakokon, így a ZH feladatai könnyebbnek tűnnek majd
*Kisebb gyakorlatcsoportok
*Szakonként és évfolyamonként a legjobban teljesítő 5-5 hallgató IMSc '''ösztöndíjat''' kap
*Erősebb tudást ad
*'''Kiforratlan''' rendszer (2016-ban indult, néha maguk a gyakvezek sincsenek teljesen tudatában a szabályoknak)
*Engedély nélkül '''nem szabad dolgozni''' egyetem mellett
*Ha IMSc pontokat is akarsz gyűjteni, '''többet kell tanulnod,''' így kevesebb szabadidőd marad

==IMSc pontok==
IMSc pontokat IMSc és normál képzésen is, szorgalmi feladatok megoldásával lehet szerezni. Ilyesfajta pluszfeladatok előfordulhatnak ZH-kban, vizsgákon és házifeladatokban, tantárgytól függően. Persze a meg nem oldásuk nem jár semmilyen negatív következménnyel, nélkülük is lehet 100%-os ötöst csinálni. 
Minden tantárgyból a kreditértéke ötszörösének megfelelő IMSc pont adható, és (egyelőre) főleg az IMSc-ösztöndíjak megítélésénél játszik szerepet az, hogy kinek mennyi pontja van.

==Vélemények==
*A program elindulásával egyidőben léptem be az IMSc-be, és nekem megérte. Tényleg sokkal több tudást ad, és motiválóbb - ráadásul legtöbbször mi kapjuk a legjobb tanárokat. Szerintem az emberek sokkal jobban félnek ettől a képzéstől, mint kellene. Ha nem tudod hozni a négyes átlagot, akkor visszakerülsz normál képzésre, és kész, ahol nem lesz hiányosságod, mert amit ők tanulnak, azt mi is. Amiben nekünk pluszmunkánk van, az némi extra IMSc-tananyag, de ezeket csak IMSc-pontokért kérik számon, tehát egyfajta szorgalmi feladat ez is. - [[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2017. június 17., 18:54 (UTC)

==Hivatkozások==
*[https://www.vik.bme.hu/page/998/ A 2016-os hivatalos kari tájékoztató]
*[https://www.vik.bme.hu/document/829/original/3/00003967.pdf A kar tájékoztatója bővebben, 2016-ból (pdf)]
*[http://www.vik.bme.hu/hir/2076-imsc-program---ujabb-csatlakozasi-lehetoseg 2017 júniusi kari tájékoztató IMSc-seknek]

IMSc

2017-06-17T19:18:44Z

Schulcz Ferenc: /* Előnyök és hátrányok */

A hazai gazdaság és tudományos kutatás élvonalbeli szegmensei által igényelt, elméletileg is jól felkészült, magas szellemi hányadú, csúcstechnológiákat alkalmazó, innovatív kutatási-fejlesztési tevékenységre képes fiatal mérnökhallgatók tehetséggondozási célú képzési programja.

==Miről szól==
*Tehetséges diákok felkarolása
*Mélyebb tudás megszerzése
*Szakmai tapasztalatszerzés
*Ösztönzés az MSc elvégzésére

==Követelmények==
===Bekerüléshez===
*'''Gólyák''' esetén:
**Matematika, fizika, informatika II. OKTV, Informatikai alapismeretek, esetleg elektronikai alapismeretek SZÉTV '''tanulmányi versenyek 1-10 helyezettjei (ők automatikusan bekerülnek)''' ''VAGY''
**'''Emelt szintű érettségi''' matematikából vagy fizikából ''VAGY''
**A fenti tárgyak egyikéből '''OKTV tanulmányi verseny 11-30. helyezett'''
:Felvételi döntés a létszámkorlát figyelembevételével meghatározott minimumpontszám alapján történik. A pontszámba a felvételi pontszám számít bele, és az egyes versenyeredményekért, második emelt szintű érettségikért pluszpontok kaphatók. 
*Lehetőség van a '''képzés során később,''' valamelyik szemeszter előtt is becsatlakozni, '''mintatantervi haladás, és legalább 4.0 súlyozott tanulmányi átlag''' esetén.

===Bennmaradáshoz===
*mintatantervi haladás
*>='''4.0''' súlyozott tanulmányi átlag minden félévben
Semmilyen negatív következménnyel nem jár, ha nem sikerül tartani - ekkor a hallgató átsorolódik normál képzésre, és a fenti feltételek teljesítése után a félév végén akár vissza is kerülhet.

==Előnyök és hátrányok==
*Gyorsabb haladási ütem (BSc + MSc képzéshez képest '''fél évvel korábban végzel''')
*Minden hallgató kap maga mellé egy '''mentort''', aki segít minden felmerülő kérdésben
*'''Érdekesebb''' és egyben '''nehezebb''' feladatok gyakokon, így a ZH feladatai könnyebbnek tűnnek majd
*Kisebb gyakorlatcsoportok
*Szakonként és évfolyamonként a legjobban teljesítő 5-5 hallgató IMSc '''ösztöndíjat''' kap
*Erősebb tudást ad
*'''Kiforratlan''' rendszer (2016-ban indult, néha maguk a gyakvezek sincsenek teljesen tudatában a szabályoknak)
*Engedély nélkül '''nem szabad dolgozni''' egyetem mellett
*Ha IMSc pontokat is akarsz gyűjteni, '''többet kell tanulnod,''' így kevesebb szabadidőd marad

==IMSc pontok==
IMSc pontokat IMSc és normál képzésen is, szorgalmi feladatok megoldásával lehet szerezni. Ilyesfajta pluszfeladatok előfordulhatnak ZH-kban, vizsgákon és házifeladatokban, tantárgytól függően. Persze a meg nem oldásuk nem jár semmilyen negatív következménnyel, nélkülük is lehet 100%-os ötöst csinálni. 
Minden tantárgyból a kreditértéke ötszörösének megfelelő IMSc pont adható, és (egyelőre) főleg az IMSc-ösztöndíjak megítélésénél játszik szerepet az, hogy kinek mennyi pontja van.

==Vélemények==
*A program elindulásával egyidőben léptem be az IMSc-be, és nekem megérte. Tényleg sokkal több tudást ad, és motiválóbb, hogy okos, lelkiismeretesen tanuló emberekkel vagyok körülvéve - ráadásul legtöbbször mi kapjuk a legjobb tanárokat. Szerintem az emberek sokkal jobban félnek ettől a képzéstől, mint kellene. Ha nem tudod hozni a négyes átlagot, akkor visszakerülsz normál képzésre, és kész, ahol nem lesz hiányosságod, mert amit ők tanulnak, azt mi is. Amiben nekünk pluszmunkánk van, az némi extra IMSc-tananyag, de ezeket csak IMSc-pontokért kérik számon, tehát egyfajta szorgalmi feladat ez is. - [[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2017. június 17., 18:54 (UTC)

==Hivatkozások==
*[https://www.vik.bme.hu/page/998/ A 2016-os hivatalos kari tájékoztató]
*[https://www.vik.bme.hu/document/829/original/3/00003967.pdf A kar tájékoztatója bővebben, 2016-ból (pdf)]
*[http://www.vik.bme.hu/hir/2076-imsc-program---ujabb-csatlakozasi-lehetoseg 2017 júniusi kari tájékoztató IMSc-seknek]

Fun - Tasnádi Tamás

2017-06-17T19:13:42Z

Schulcz Ferenc:

,,Egy mondatot írok már öt perce..."

T. T. (egy levezetés végi egyszerűsítés előtt): ,,Sokat kell írni, de teljesen érdektelen, hogy mi is van ott"
Marci: ,,Ezzel le is írta az órát..."

==2016/2017 tavasz==

,,A függvény grafikonja egy lepedő."

(Tabletről olvassa a feladatsort:) ,,Kettes feladat:... Csatlakoztassa a töltőt!"

,,A régi honlapon fent van, csak nincs rá link."

,,Túl gyakran vált előjelet, ezért nem mondhatjuk, hogy előjelet vált."

,,Aki nem hiszi, deriváljon."

,,Új táblát nyitok."

,,Most jutott eszembe, hogy mi az, amit elfelejtettem."

(A Fibonacci-sorozatnál:) ,,Egy szaporodási probléma vezethet például lineáris rekurzióra. "

,,... ahol ezek a fí-kák..."

,,A bizonyítás első lépése az, hogy belepiszkálok az előző tételbe."

,,Ha van olyan becslés, ahol az a-ká-kat fölül tudjuk becsülni bé-kák-kal..."

,,Mindegy, nem kell érteni."

,,Ha léteznek olyan pozitív bé-kák..."

IMSc

2017-06-17T18:54:17Z

Schulcz Ferenc: Tartalmi frissítés, bővítés

A hazai gazdaság és tudományos kutatás élvonalbeli szegmensei által igényelt, elméletileg is jól felkészült, magas szellemi hányadú, csúcstechnológiákat alkalmazó, innovatív kutatási-fejlesztési tevékenységre képes fiatal mérnökhallgatók tehetséggondozási célú képzési programja.

==Miről szól==
*Tehetséges diákok felkarolása
*Mélyebb tudás megszerzése
*Szakmai tapasztalatszerzés
*Ösztönzés az MSc elvégzésére

==Követelmények==
===Bekerüléshez===
*'''Gólyák''' esetén:
**Matematika, fizika, informatika II. OKTV, Informatikai alapismeretek, esetleg elektronikai alapismeretek SZÉTV '''tanulmányi versenyek 1-10 helyezettjei (ők automatikusan bekerülnek)''' ''VAGY''
**'''Emelt szintű érettségi''' matematikából vagy fizikából ''VAGY''
**A fenti tárgyak egyikéből '''OKTV tanulmányi verseny 11-30. helyezett'''
:Felvételi döntés a létszámkorlát figyelembevételével meghatározott minimumpontszám alapján történik. A pontszámba a felvételi pontszám számít bele, és az egyes versenyeredményekért, második emelt szintű érettségikért pluszpontok kaphatók. 
*Lehetőség van a '''képzés során később,''' valamelyik szemeszter előtt is becsatlakozni, '''mintatantervi haladás, és legalább 4.0 súlyozott tanulmányi átlag''' esetén.

===Bennmaradáshoz===
*mintatantervi haladás
*>='''4.0''' súlyozott tanulmányi átlag minden félévben
Semmilyen negatív következménnyel nem jár, ha nem sikerül tartani - ekkor a hallgató átsorolódik normál képzésre, és a fenti feltételek teljesítése után a félév végén akár vissza is kerülhet.

==Előnyök és hátrányok==
*Gyorsabb haladási ütem (BSc + MSc képzéshez képest '''fél évvel korábban végzel''')
*Minden hallgató kap maga mellé egy '''mentort''', aki segít minden felmerülő kérdésben
*'''Érdekesebb''' és egyben '''nehezebb''' feladatok gyakokon, így a ZH feladatai könnyebbnek tűnnek majd
*Kisebb gyakorlatcsoportok
*Szakonként és évfolyamonként a legjobban teljesítő 5-5 hallgató IMSc '''ösztöndíjat''' kap
*Erősebb tudást ad
*'''Kiforratlan''' rendszer (2016-ban indult, néha maguk a gyakvezek sincsenek teljesen tudatában a szabályoknak)
*Engedély nélkül '''nem szabad dolgozni''' egyetem mellett
*Néhány tárgy kivételével ugyanazok az '''előadások''' vannak, mint a BSc-s hallgatóknak
*Ha IMSc pontokat is akarsz gyűjteni, '''többet kell tanulnod,''' így kevesebb szabadidőd marad

==IMSc pontok==
IMSc pontokat IMSc és normál képzésen is, szorgalmi feladatok megoldásával lehet szerezni. Ilyesfajta pluszfeladatok előfordulhatnak ZH-kban, vizsgákon és házifeladatokban, tantárgytól függően. Persze a meg nem oldásuk nem jár semmilyen negatív következménnyel, nélkülük is lehet 100%-os ötöst csinálni. 
Minden tantárgyból a kreditértéke ötszörösének megfelelő IMSc pont adható, és (egyelőre) főleg az IMSc-ösztöndíjak megítélésénél játszik szerepet az, hogy kinek mennyi pontja van.

==Vélemények==
*A program elindulásával egyidőben léptem be az IMSc-be, és nekem megérte. Tényleg sokkal több tudást ad, és motiválóbb, hogy okos, lelkiismeretesen tanuló emberekkel vagyok körülvéve - ráadásul legtöbbször mi kapjuk a legjobb tanárokat. Szerintem az emberek sokkal jobban félnek ettől a képzéstől, mint kellene. Ha nem tudod hozni a négyes átlagot, akkor visszakerülsz normál képzésre, és kész, ahol nem lesz hiányosságod, mert amit ők tanulnak, azt mi is. Amiben nekünk pluszmunkánk van, az némi extra IMSc-tananyag, de ezeket csak IMSc-pontokért kérik számon, tehát egyfajta szorgalmi feladat ez is. - [[Szerkesztő:Schulcz Ferenc|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc|vita]]) 2017. június 17., 18:54 (UTC)

==Hivatkozások==
*[https://www.vik.bme.hu/page/998/ A 2016-os hivatalos kari tájékoztató]
*[https://www.vik.bme.hu/document/829/original/3/00003967.pdf A kar tájékoztatója bővebben, 2016-ból (pdf)]
*[http://www.vik.bme.hu/hir/2076-imsc-program---ujabb-csatlakozasi-lehetoseg 2017 júniusi kari tájékoztató IMSc-seknek]