Szoftver projekt laboratórium

A VIK Wikiből
(SzgLab4 szócikkből átirányítva)
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@sch.bme.hu
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

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:

  • 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

Kedvcsináló
Bevezetők
1. félév
2. félév
3. félév
4. félév
5. félév
6. félév
7. félév


Bevezetők
1. félév
2. félév
3. félév
4. félév
5. félév
6. félév
7. félév


A lap eredeti címe: „https://vik.wiki/index.php?title=Szoftver_projekt_laboratórium&oldid=205654”