Szoftver projekt laboratórium

Szoftver projekt laboratórium

Tárgykód	VIIIAB06
Régi tárgykód	VIIIAB02, VIIIA220
Általános infók
Szak	info
Kredit	3
Ajánlott félév	4
Keresztfélév	nincs
Tanszék	IIT
Követelmények
Jelenlét	nem kötelező, de erősen ajánlott
Labor	nincs
KisZH	nincs
NagyZH	nincs
Házi feladat	11 db
Vizsga	nincs
Elérhetőségek
Levlista	szoftlab4@NO-SPAM.sch.bme.hu
Tantárgyi adatlap
Tárgyhonlap
Facebook tanulmányi csoport

A tárgyat a régi képzésben így hívták: 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

• A 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.

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 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.
• 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.

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).
• 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:

$P=0,3*Sc+0,5*Pr+0,2*Gr$

• 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.
• Ponthatárok:

Pont	Jegy
0 - 40	1
41 - 54	2
55 - 68	3
69 - 82	4
83 - 100	5

iMSc pontok

• Elérhető pontszám: 10 pont.
• Feladat:
  • 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

Verziókezelés

• 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 kszk git verziókezelője, pár perc alatt el lehet sajátitani hozzá az alapokat: 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 Google Drivená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 facebook beszélgetés, akár Discord, 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.

• 1. Követelmény, projekt, funkcionalitás: (max 10 pont)
  • 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 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.
• 2. Analízis modell kidolgozása 1: (max 20 pont)
  • 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.
• 3. Analízis modell kidolgozása 2: (max 30 pont)
  • Á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.
• 4. Szkeleton tervezése: (max 20 pont)
  • 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.
  • 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).
  • 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.
• 5. Szkeleton beadása: (max 20 pont, min 9 pont)
  • 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.
• 6. Prototípus koncepciója: (max 20 pont)
  • 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 karakteres bemenetre és kimenetre gondolni.
• 7. Részletes tervek: (max 45 pont)
  • 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.
• 8. Prototípus beadása: (max 35 pont, min 15 pont)
  • 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)
• 9. Grafikus felület specifikációja: (max 30 pont)
  • 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.
• 10. Grafikus változat beadása: (max 40 pont, min 17 pont)
  • 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.
• 11. Összefoglalás (max 30 pont)
  • 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.)

Tippek

• Lennon tanácsai a tárgyhoz

Kedvcsináló

• Kindergarten Galéria 2006
• SnakeFarm Galéria 2008
• Bankrabló Galéria 2010
• Continuity Galéria 2012
• AntFarm Galéria 2013
• Két Torony Galéria 2014
• Killer sokoban galéria 2018
• Jégmező galéria 2020
• Aszteroidabányászat galéria 2021
• Sivatagi vízhálózat galéria 2023

Mérnökinformatikus
Bevezetők	Bevezető matematika
1. félév	Analízis 1  •  A programozás alapjai 1  •  Bevezetés a számításelméletbe 1  •  Digitális kompetenciák  •  Digitális technika  •  Fizikai alapismeretek  •  Villamos alapismeretek
2. félév	Algoritmuselmélet  •  Analízis 2  •  A programozás alapjai 2  •  Bevezetés a számításelméletbe 2  •  Fizika i  •  Számítógép architektúrák
3. félév	A programozás alapjai 3  •  Adatbázisok  •  Kódolástechnika  •  Operációs rendszerek  •  Szoftvertechnológia  •  Valószínűségszámítás és statisztika
4. félév	Menedzsment és vállalkozásgazdaságtan  •  Jogi alapismeretek  •  Kommunikációs hálózatok  •  Szoftvertechnikák  •  Szoftver projekt laboratórium  •  Számítógépes grafika
5. félév	Mesterséges intelligencia
6. félév	Mikro- és makroökonómia B  •  IT biztonság
7. félév	Záróvizsga

Mérnökinformatikus 2014
Bevezetők	Bevezető fizika  •  Bevezető matematika
1. félév	Analízis 1  •  A programozás alapjai 1  •  Bevezetés a számításelméletbe 1  •  Digitális technika  •  Fizika 1i  •  Mérnök leszek
2. félév	Analízis 2  •  Analízis szigorlat informatikusoknak  • A programozás alapjai 2  •  Bevezetés a számításelméletbe 2  •  Fizika 2i  •  Rendszermodellezés  •  Számítógép-architektúrák
3. félév	Adatbázisok  •  A programozás alapjai 3  •  Kódolástechnika  •  Kommunikációs hálózatok 1  •  Rendszerelmélet  •  Szoftvertechnológia  •  Valószínűségszámítás
4. félév	Adatbázisok laboratórium  •  Algoritmuselmélet  •  Kommunikációs hálózatok 2  •  Menedzsment és vállalkozásgazdaságtan  •  Operációs rendszerek  •  Számítógépes grafika  •  Szoftver projekt laboratórium  •  Szoftvertechnikák
5. félév	IT eszközök technológiája  •  Mesterséges intelligencia  •  Mikro- és makroökonómia  •  Mobil- és webes szoftverek  •  Üzleti jog
6. félév	Információs rendszerek üzemeltetése  •  IT biztonság
7. félév	Záróvizsga