Szoftver projekt laboratórium - Laptörténet

Kovács Hunor Lajos: fungorium feladat hozzáadva

2025-05-31T15:30:59Z

fungorium feladat hozzáadva

← Régebbi változat		A lap 2025. május 31., 17:30-kori változata
144. sor:		144. sor:
	* [[Szoftver projekt laboratórium - Aszteroidabányászat galéria \| Aszteroidabányászat galéria 2021]]		* [[Szoftver projekt laboratórium - Aszteroidabányászat galéria \| Aszteroidabányászat galéria 2021]]
	* [[Szoftver projekt laboratórium - Sivatagi vízhálózat galéria \| Sivatagi vízhálózat galéria 2023]]		* [[Szoftver projekt laboratórium - Sivatagi vízhálózat galéria \| Sivatagi vízhálózat galéria 2023]]
			* [[Szoftver projekt laboratórium - Fungorium \| Fungorium 2025]]

	{{Lábléc - Mérnök informatikus alapszak 2022}}		{{Lábléc - Mérnök informatikus alapszak 2022}}
	{{Lábléc - Mérnök informatikus alapszak 2014}}		{{Lábléc - Mérnök informatikus alapszak 2014}}

Kovács Hunor Lajos: naprakész adatok

2025-05-31T15:23:15Z

naprakész adatok

← Régebbi változat		A lap 2025. május 31., 17:23-kori változata
1. sor:		1. sor:
	{{Tantárgy		{{Tantárgy
	\|név = Szoftver projekt laboratórium		\|név = Szoftver projekt laboratórium
	\|tárgykód = ~~VIIIAB06~~		\|tárgykód = VIIIAB11
	\|régitárgykód = VIIIAB02, VIIIA220		\|régitárgykód = VIIIAB02, VIIIA220, VIIIAB06
	\|szak=info		\|szak=info
	\|kredit = 3		\|kredit = 4
	\|felev = 4		\|felev = 4
	\|kereszt = nincs		\|kereszt = nincs
14. sor:		14. sor:
	\|hf = 11 db		\|hf = 11 db
	\|vizsga = nincs		\|vizsga = nincs
	\|tad = https://portal.vik.bme.hu/kepzes/targyak/~~VIIIAB02~~/		\|tad = https://portal.vik.bme.hu/kepzes/targyak/VIIIAB11/
	\|targyhonlap = https://www.iit.bme.hu/targyak/BMEVIIIAB02		\|targyhonlap = https://www.iit.bme.hu/targyak/BMEVIIIAB02
	\|levlista = szoftlab4{{kukac}}sch.bme.hu		\|levlista = szoftlab4{{kukac}}sch.bme.hu
57. sor:		57. sor:

	=== iMSc pontok ===		=== iMSc pontok ===
	* '''Elérhető pontszám:''' 10 pont.		* '''Elérhető pontszám:''' 20 pont.
	* ~~'''Feladat:'''~~		* A tárgyból az IMSC-pontokat a csapat gyűjti. Minden új beadandóra jár IMSC-pont, amennyiben az anyag az elérhető pontok 80%-ánál többet ér. Ebben az esetben az elérhető pontok százalékában mért eredmény 80% feletti részében 10%-pont ér egy IMSC-pontot. Pl. 85% 0,5 IMSC-pont, 93% 1,3 IMSC-pont, 100% 2 IMSC-pont. Az így szerzett pontok összeadódnak és a félév végén a tárgyból jelest szerző hallgatók külön-külön megkapják a csapatuk által szerzett IMSC-pontokat.
	** Minden ~~heti leadandó anyag esetén~~, amennyiben az anyag az elérhető ~~pontszámok~~ 80%-~~nál~~ többet ér, ~~a csapat számára~~ 1 ~~iMSC~~ pont ~~adható~~.
	** Csak azok a ~~hallgatók kaphatják meg az iMSc pontot, akik~~ a tárgyból jelest ~~szereztek~~.

	== Házi feladat ==		== Házi feladat ==
68. sor:		66. sor:

	=== Doksi írás ===		=== 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~~.		* Érdemes olyan platformot választani, amit egyszerre mindenki tud használni, nem kell várni a másikra, illetve utólag összeollózni. Nekünk a git+latex jól bevált, esetleg a [https://drive.google.com Google Drive] egy működő alternatíva lehet.

	=== Kommunikáció ===		=== Kommunikáció ===

Ragány-Németh Albert1: 4-5 helyett 5 fos csapatok

2025-02-18T17:52:16Z

4-5 helyett 5 fos csapatok

← Régebbi változat		A lap 2025. február 18., 19:52-kori változata
21. sor:		21. sor:
	{{Átnevezett tárgy \| Szoftver laboratórium 4}}		{{Á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.		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 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.


38. sor:		38. sor:
	=== Féléközi jegy ===		=== Féléközi jegy ===
	* A három feladatrész (Skeleton, proto, grafika) összesen 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).		* A három feladatrész (Skeleton, proto, grafika) összesen 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:		*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,3Sc+0,5Pr+0,2*Gr</math>		<math>P= 0,3Sc+0,5Pr+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.		* 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.

Magyari Krisztián: /* Verzókezelés */

2024-06-15T11:40:04Z

Verzókezelés

← Régebbi változat		A lap 2024. június 15., 13:40-kori változata
64. sor:		64. sor:
	== Házi feladat ==		== Házi feladat ==

	=== ~~Verzókezelés~~ ===		=== Verziókezelés ===
	* Mindenképpen kell egy értelmes ~~verzókezelő~~ rendszer, ha dropboxon vagy hasonló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]		* Mindenképpen kell egy értelmes verziókezelő rendszer, ha dropboxon vagy hasonló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 ===		=== Doksi írás ===

Török Zsombor, 2024. május 28., 11:18-n

2024-05-28T11:18:55Z

← Régebbi változat		A lap 2024. május 28., 13:18-kori változata
148. sor:		148. sor:

	{{Lábléc - Mérnök informatikus alapszak 2022}}		{{Lábléc - Mérnök informatikus alapszak 2022}}
	~~{{Lábléc - Mérnök informatikus alapszak 2017}}~~
	{{Lábléc - Mérnök informatikus alapszak 2014}}		{{Lábléc - Mérnök informatikus alapszak 2014}}

Török Zsombor, 2024. május 26., 21:18-n

2024-05-26T21:18:47Z

← Régebbi változat		A lap 2024. május 26., 23:18-kori változata
19. sor:		19. sor:
	\|facebook = https://www.facebook.com/groups/338196589708558/		\|facebook = https://www.facebook.com/groups/338196589708558/
	}}		}}

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

148. sor:		147. sor:
	* [[Szoftver projekt laboratórium - Sivatagi vízhálózat galéria \| Sivatagi vízhálózat galéria 2023]]		* [[Szoftver projekt laboratórium - Sivatagi vízhálózat galéria \| Sivatagi vízhálózat galéria 2023]]

	{{~~Lábléc_~~-~~_Mérnök_informatikus_alapszak_2014~~}}		{{Lábléc - Mérnök informatikus alapszak 2022}}
	{{~~Lábléc_~~-~~_Mérnök_informatikus_alapszak~~}}		{{Lábléc - Mérnök informatikus alapszak 2017}}
			{{Lábléc - Mérnök informatikus alapszak 2014}}

Gombos Sándor Bence: 2023 link

2023-03-10T20:41:24Z

2023 link

← Régebbi változat		A lap 2023. március 10., 22:41-kori változata
146. sor:		146. sor:
	* [[Szoftver projekt laboratórium - Jégmező galéria \| Jégmező galéria 2020]]		* [[Szoftver projekt laboratórium - Jégmező galéria \| Jégmező galéria 2020]]
	* [[Szoftver projekt laboratórium - Aszteroidabányászat galéria \| Aszteroidabányászat galéria 2021]]		* [[Szoftver projekt laboratórium - Aszteroidabányászat galéria \| Aszteroidabányászat galéria 2021]]
			* [[Szoftver projekt laboratórium - Sivatagi vízhálózat galéria \| Sivatagi vízhálózat galéria 2023]]

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

Csia Klaudia Kitti: Konvenciók alapján rendbe szed.

2022-02-15T15:41:34Z

Konvenciók alapján rendbe szed.

Változtatások megtekintése

Piller Trisztán: /* Befejezett projektek galériái */

2021-08-10T14:24:38Z

Befejezett projektek galériái

← Régebbi változat		A lap 2021. augusztus 10., 16:24-kori változata
176. sor:		176. sor:
	* [[Szoftver projekt laboratórium - Killer sokoban galéria\|Killer sokoban galéria 2018]]		* [[Szoftver projekt laboratórium - Killer sokoban galéria\|Killer sokoban galéria 2018]]
	* [[Szoftver projekt laboratórium - Jégmező galéria\|Jégmező galéria 2020]]		* [[Szoftver projekt laboratórium - Jégmező galéria\|Jégmező galéria 2020]]
			* [[Szoftver projekt laboratórium - Aszteroidabányászat galéria\|Aszteroidabányászat galéria 2021]]

	==Csapattoborzás==		==Csapattoborzás==

Szenczy Balázs: /* Beadandó tartalmi követelménye */

2021-01-23T09:01:02Z

Beadandó tartalmi követelménye

← Régebbi változat		A lap 2021. január 23., 11:01-kori változata
97. sor:		97. sor:
	*** 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.		*** 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ű.		*** 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.		*** 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 teljesen 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.		** 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:		* 3. Analízis modell kidolgozása 1:
105. sor:		105. sor:
	** 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.		** 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:		* 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.		** Á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 kevesebb tennivalója van.
	* 5. Szkeleton tervezése:		* 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.		** A szkeleton 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.		** 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 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égrehajtá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).		** 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.		** 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.
121. sor:		121. sor:
	** 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.		** 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 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 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.		** 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.		** 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.		** Nem ajánlott JUnit vagy valami ehhez hasonló környezetben gondolkodni, mert csak feleslegesen elbonyolítja a helyzetet, bőven elég karakteres bemenetre és kimenetre gondolni.
	* 8. Részletes tervek:		* 8. Részletes tervek:
	** Az előző rész részletezéséről szól ez a dokumentum.		** Az előző rész részletezéséről szól ez a dokumentum.