Kihagyás

Általános követelmények

  • A csapatok egy open-source fejlesztésbe kapcsolódnak be a félév során.
  • A projekteket optimálisan 5, de min. 4, max. 6 fős csapatok viszik.
  • A csapaton belüli bármilyen probléma (pl. inaktív tagok) esetén, a első előfordulás alkalmával tájékoztatni kell a gyakorlatvezetőt e-mailben, melyen minden csapattagot címezni kell (CC). Az értékelés után beérkező csapatot érintő panaszokat nem fogadjuk el.
  • A csapatok kialakítása véletlenszerűen történik a gyakorlatokon belül, a kialakított csapatokról a gyakorlatvezető értesíti a csapatokat.
  • Projektekből összesen 65 pontot lehet összegyűjteni a félév során. Részenként és összesen min. 50% teljesítendő. A felosztást lásd az ezt követő részekben.
  • A gyakorlatvezető a kiemelkedő egyéni teljesítményt (kezdeményező készség, megfelelő kommunikáció, csapatvezetés, stb.) plusz ponttal jutalmazhatja. Egy hallgató a félév során maximum 75 pontot szerezhet a projektmunkára, az egyéni pluszpontokkal és a ,,közös'' feladatokra kapott pontokkal együtt.
  • Bármelyik kötelezőnek megjelölt leadandó hiánya esetén a hallgató (vagy csapat, a leadandó jellegétől függően) elégtelen érdemjegyet kap.
  • Csak azt a leadott anyagot tudjuk az egyéni értékelés során figyelembe venni, ami a saját GitLab felhasználó segítségével került feltöltésere. Ez minden esetben a H-s azonosító, vagy az egyetemi LDAP belépés. Csak olyan commit-okat fogadunk el ami a hallgató saját, stud-os címéről készült. (Az Irinyi Kabinetben való használat esetén minden újraindítás után be kell állítani a Git user nevet és e-mail címet, ezzel elkerülve hogy az alapértelmezett felhasználó nevében szülessenek a commit-ok. (https://help.github.com/en/github/using-git/setting-your-username-in-git)
  • A leadandók esetén a megadott névkonvenciókat szigorúan tartani kell. A névkonvenciót nem tartó leadás nem minősül elfogadott teljesítésnek (akkor sem, ha határidőig beérkezett).
  • Mivel a projektmunka folyamtos munkát igényel, és a leadandók pontos időpontja a félév elején kihirdetésre került, ezért a projektmunka pótlására nincs lehetőség. A projektmunka elvégzése előretervezést igényel a hallgatóktól.
  • A projektmunka elvégzése a félév során folyamatos és az tanórákon túli munkát igényel. Az ipari projektekhez hasonlóan a nem megfelelő minőségű munka elvégzése a gyakorlat során is következményekkel jár. Ezen okok miatt a projektmunkák javítására nincs lehetőség.
  • Minden leadandóban csak azok a részek fogadhatóak el új teljesítésnek, amik korábbi, a projekttel kapcsolatos teljesítésben még nem lettek leadva.
  • Ahol a ,,közös'' értékelési mód van megadva ott a gyakorlatvezető a hallgatók egyéni teljesítményét és javaslatait figyelembe véve, de a saját szakmai tapasztalatai alapján dönti el hogy milyen arányban osztja el a feladatra kapott pontot.
  • A csapat javaslatot tehet, melyben megadja, hogy a közös részeken ki és milyen mértékben (%) dolgozott. A javaslattal minden csapattagnak bele egyet kell értenie.
  • A javaslat során a hallgatóknak személyenként részletezniük kell az egyes elvégzett részeket, melyeket célszerű Git commit-okkal alátámasztani.
  • A hozzájárulás részletezését gyakorlatvezetőnek az értékelést követő 7 napon belül (23:59) e-mail-ben kell elküldeni melyen minden csapattagot címezni kell (CC). A levél tárgya: ,,[RF2] csapatnév: leadandó címe hozzájárulások. A csapattagoknak az e-mail beérkezésétől számított 24 óráig van idejük jelezni (e-mail-ben) a ha nem értenek egyet a csapat által küldött hozzájárulás felosztással, mely esetben a pontokat a gyakorlatvezető osztja el.
  • Amennyiben a csapat képtelen megegyezni, vagy erről nem küld megfelelő tájékoztatást úgy a pontokat a gyakorlatvezető saját belátása szerint osztja el a csapat tagjai között. A gyakorlatvezető felülbírálhatja a hallgatók által küldött hozzájárulás elosztást.
  • A feladatok végrehajtása során mindig jelöljük meg azt a master branch-en lévő commit-ot, mely tartalmazza a feladata minden eredményét. A jelöléshez használjuk a megfelelő tag-eket.
    1
    2
    git tag -a <rövidítés> -m "<megjegyzés>"
    git push origin <rövidítés>
    
    Például:
    1
    2
    git tag -a sample_task -m "final working version"
    git push origin sample_task
    
  • A ,,/'' mindig a GitLab projekthez társított Git repository gyökerét jelzi.
  • A leadandók bemutatása során a gyakorlatvezető által szigorúan tartani kell az időkeretet. Ne tervezzünk túl hosszú prezentációt!
  • A gyakorlat célja hogy a hallgató elsajátítsa az önálló munkavégzéshez szükséges szaktudást és képességeket. A megadott jegy ennek sikerességét tükrözi. Azt hogy a leadott munka eléri-e a megfelelő minőséget és mennyiséget a gyakorlatvezető dönti el figyelembe véve az ebben a dokumentumban meghatározottakat.
  • A kiemelkedő minőségű projektmunkákat a gyakorlatvezető előadás megajánlott jegyre javasolhatja az előadónál. A megajánlott jegy feltételei és megítélése az előadó által történik az általa meghatározott és hirdetett szabályok szerint.

Fontosabb formai követelmények

  • Minden szövegnek, ábrának és képnek olvashatónak kell lennie A4-es lapra nyomtatás során ill. prezentáció esetén a kivetítőn nagyítás nélkül (javasolt betűméret: 11-14pt).
  • A megadott oldalszámok, minden esetben a címlap és az esetleges tartalomjegyzék nélkül értendők.
  • A leadott anyagok nyelve magyar vagy angol, de dokumentumon belül ne keverjük a nyelveket (kivétel az egyes forráskód idézetek).
  • A kettőnél kevesebb elemből álló ábra (diagram, gráf) nem számít ábrának.
  • Az olyan ábra ahol nincs az elemek között kapcsolat (él) nem számít ábrának.
  • Az olyan ábrát vagy képernyőképet amihez nem tartozik legalább egy bekezdésnyi magyarázó vagy részletező szöveg nem vesszük figyelembe a teljesítés során.
  • Az ábráknak és a képernyőképeknek tartalmaznia kell a bemutatott elemeket. Logikátlan vagy követhetetlen módon feldarabolt ábrákat nem fogadunk el.
  • A prezentációk során javasoljuk a ,,The beamer class User Guide for version 3.57'' 5. fejezetében ,,Guidelines for Creating Presentations'' leírt irányelvek betartását. (a prezentációkat nem kötelező LaTeX-ben készíteni)
  • Az itt felsoroltak csak a kiemelten fontos formai dolgokat érintik, egyéb formai kérdésekben a gyakorlatvezető dönt.

Projekt megismerése és változtatási igények összeállítása

rövidítés max. pontszám min. pontszám
comprehension feladat 50 pont/csapat 5 pont/fő

Cél az átvett projekt megismerése, a változtatási igény benyújtása.

Leadandó a futó program és a projektet röviden bemutató, legalább 8 oldalas dokumentum, ami ismerteti

  • az átvett program szerkezetét (UML package, osztály vagy egyéb szerkezeti diagram, pl. E/K) és az átvett program fő funkcióit (UseCase, szekvencia diagram, funkcióleírások screenshotokkal)
  • összesen legalább annyiféle diagramot kell átadni ahány fős a csapat(javasolt diagram típusok: 1, 2, pl.: 4 fő esetén: 2 osztálydiagram, 1 csomagdiagram, 1 szekvenciadiagram és 2 folyamatábra = 4-féle diagram)
  • az átvétel során tapasztalt hiányosságokat, nehézségeket, esetleg pozitívumokat
  • a tervezett változtatásokat, amik lehetnek új funkciók és minőségjavítás is (Minőségjavítás esetén a bemutatás során ki kell térni a leggyakoribb vagy a legsúlyosabb hibákra amik javításra kerültek, ezeket célszerű kódrészletek segítségével bemutatni.)

Fontos, hogy a változtatási igényt annyi alfeladatra kell szétbontani, ahány csapattag van, hogy a későbbi feladatok személyenként számonkérhetőek legyenek. A csapat által fejlesztett projekthez kapcsolódó issue-k közül minden tag maga választ. A választást a gyakorlatvezető hagyja jóvá. Egy issue-t fejleszthet több hallgató és egy hallgató több issue-t is vállalhat, amennyiben ezt a gyakorlatvezető jóvá hagyja.

A fejlesztés során felmerülő előre nem látható komplikációkról azonnal tájékoztatni kell a gyakorlatvezetőt (ha másképp nem rendelkezik akkor e-mail-ben). A problémák jellege alapján a gyakorlatvezető enyhíthet bizonyos követelményeken, hogy azok egyensúlyban maradjanak a tárgy teljesítéséhez szükséges erőforrásokkal.

A leadáskor minden csapatnak rendelkezni kell egy GitLab group-pal, melybe minden tagot felvettek. E csoport tulajdonában kell lennie egy GitLab projektnek, melyben a csapat a feladatok megvalósítását követi és teszi közzé.

Leadandók és teljesítendők

A választott projekt leírása

Tulajdonság Érték
A választott projekt leírása /doc/comprehensiontask<csapatnév>-project.md
formátum folyószöveges dokumentum
min. méret 1 diagram és magyarázó szöveg/fő
értékelési mód közös
kötelező? igen
max. pontszám 40 pont/csapat

A választott projekt bemutatása

Tulajdonság Érték
névkonvenció /doc/comprehension/hcsapatnévi-presentation.pdf
formátum prezentáció
max. méret 10 perc/csapat
értékelési mód közös
kötelező? nem
max. pontszám 10 pont/csapat

Változtatás igény ismertetése és felosztása

Tulajdonság Érték
névkonvenció /doc/comprehension/hcsapatnévi-changereq.md
formátum folyószöveges dokumentum
min. méret 2 oldal/csapat
értékelési mód közös
kötelező? igen
max. pontszám 10 pont/csapat

GitLab csoport

Tulajdonság Érték
névkonvenció <gyakorlat Neptun kódja>-<csapatnév ékezetek nélkül>
formátum GitLab csoport
min. méret összes csapattag
értékelési mód személyenként egyénileg
kötelező? igen
max. pontszám 0 pont

GitLab projekt

Tulajdonság Érték
névkonvenció <projekt neve ékezetek nélküli>
formátum GitLab projekt
min. méret minden kötelező leadandó folyamatosan vezetve
értékelési mód személyenként egyénileg
kötelező? igen
max. pontszám 0 pont

Fejlesztés

Változtatási igény implementálása

rövidítés max. pontszám min. pontszám
development feladat 25 pont/csapat 12 pont/fő

A bemutatón az implementált változtatásokat, új feature-öket kell bemutatni. A csapat minden tagjának ismernie kell a főbb változtatásokat.

A fejlesztés GitLab környezetben történik. A futtatható kódot a master branch-en kell elhelyezni és az development tag-gel kell ellátni a Git-ben. A leadandóhoz a határidőre fordítható, bemutatható kódnak kell lennie, amit a bemutató időpontján kell bemutatni. A bemutatóhoz prezentációs anyag készíthető, de nem kötelező.

Leadandók és teljesítendők

Az változtatásokat tartalmazó projekt forráskódja

Tulajdonság Érték
névkonvenció /src/??/?.java
formátum forráskód fájlok
min. méret nincs megadva
értékelési mód személyenként egyénileg, élő bemutató alapján
kötelező? igen
max. pontszám 25 pont/fő

A változtatások megvalósításának bemutatása

Tulajdonság Érték
névkonvenció /doc/development/hcsapatnévi-presentation.pdf
formátum prezentáció
max. méret 15 perc/csapat
értékelési mód közös
kötelező? nem
max. pontszám 10 pont/csapat

A fejlesztési és egyéb folyamatok követése

rövidítés max. pontszám min. pontszám
process feladat 50 pont/csapat 5 pont/fő

A félév során a következő fejlesztési elemek dokumentált használatát pontozzuk: heti megbeszélés, issuek karbantartása, Git és GitLab használat, git flow követése, melyeket legkésőbb az comprehension bemutatásának hetétől kezdődően az processes leadásáig legalább hetente kell frissíteni. Az agilis módszertanokhoz hasonlóan kövessük nyomon a feladatok végrehajtását. Minden csapattagnak legyenek saját issuejai. Az issue board státuszai tartalmazzák a következőket: Új (To Do, Backlog), Folyamatban (Doing), Tesztelésre vár (To Test), Tesztelés alatt (Testing), Lezárt (Closed) (vagy ezek angol megfelelőit).

Gitben nagy bináris állományok (*.class, *.jar, *.zip, *.rar, ...) tárolása tilos (max. 3 pont levonás jár érte), a .gitignore fájl segíthet ennek követésében.(A legtöbb projekt már tartalmaz ilyen fájlt, amelyik mégsem ahhoz könnyen létrehozhatunk egyet a Gitignore.io segítségével) A példa projekt a következő címen érhető el: link. A példa projekt módosítása szigorúan tilos. Aki ennek ellenére módosítja, attól módosításonként 2 pont kerül levonásra.

A projekt lezárásaként egy összegző dokumentumot kell készíteni. Az összegzést a csapat GitLab projektjéhez tartozó Git repozitoriban kell elhelyezni a mater branch-en. A dokumentum (README.md) tartalmaznia kell az minden részfeladatok teljesítésére vonatkozó hivatkozásokat és MarkDown formátumban kell elkészülnie.

Az process átadandóinak tartalmaznia kell:

  • Legalább 5 db meeting memo, melyet az adott projekthez GitLab-ban, a Wiki-be kell rögzíteni.minta
  • Minden feladat felvitele, pontos határidőkkel az adott projektbe GitLab-ban. Valamint az alábbi követelmények szerint Issue-k létrehozása az egyes feladatok számára.
  • Feladatonként legalább 3 issue létrehozása
  • Felhasználónként legalább 4 issue létrehozása
  • Minden issue folyamatos vezetése a task board (Scrum vagy Kanban tábla) segítségével. Ellenőrzésre az issue-k státusz log-ja kerül felhasználása, ahol az egyes státusz változások között indokolható időnek kell eltelnie. Vitás kérdésekben a log összehasonlításra kerül a Git repository kommitjaival.
  • Projekt összegző leírás

Leadandók és teljesítendők

Megbeszélés jegyzet

Tulajdonság Érték
névkonvenció link
formátum GitLab Wiki bejegyzés
min. méret 5 darab/csapat
értékelési mód közös
kötelező? igen
max. pontszám 20 pont/csapat

Mérföldkövek

Tulajdonság Érték
névkonvenció link
formátum GitLab mérföldkő
min. méret 2 darab/csapat
értékelési mód közös
kötelező? igen
max. pontszám 10 pont/csapat

Issue-k

Tulajdonság Érték
névkonvenció link
formátum GitLab issue
min. méret 3 darab/mérföldkő és 4 darab/fő
értékelési mód közös
kötelező? igen
max. pontszám 20 pont/csapat

Projekt összegző leírás

Tulajdonság Érték
névkonvenció link
formátum Markdown
min. méret minden leadandóra és csapattagra mutató hivatkozás
értékelési mód közös
kötelező? igen
max. pontszám 5 pont/csapat

Minőségbiztosítás és elemzés

Az alábbi feladatok közül a csapat a projekt jellegét figyelembe véve és a gyakorlatvezető jóváhagyásával választ egy feladatot. A kiválasztott feladat nevét még a development leadása előtt el kell küldeni e-mail-ben a gyakorlatvezetőnek. Az e-mail tárgya legyen: ,,[RF2] minőségbiztosítás feladatválasztás''. A választás csak akkor számít elfogadottnak, ha azt a gyakorlatvezető válaszlevélben megerősíti. A gyakorlatvezető jóváhagyása nélküli feladat végrehajtását és eredményét nem fogadjuk el.

Unit tesztek

rövidítés max. pontszám min. pontszám
testing feladat 10 pont/csapat 5 pont/fő

Feladat a projekthez unit tesztek implementálása és futtatása. A feladat során a unit tesztek forráskódját (*.java fájlok) a master branch-en kell elhelyezni és az testing tag-gel kell ellátni Git-ben. Csapattagonként legalább 10 különböző metódus unit tesztjeit be kell tudni mutatni. A tesztelésre kiválasztott metódusok során vegyük figyelembe a következőket.

  • Ne teszteljünk triviális kódot, például egysoros getter és setter.
  • A unit tesztelés célja hogy ellenőrizze hogy a metódus előre meghatározott bemenetere megfelelő (literálként megadott) eredményt ad.
  • Elsősorban a saját változtatás megvalósítását teszteljük, vagyis azokat a metódusokat amiket mi írtunk, vagy módosítottunk.
  • Másodsorban a saját változás megvalósításához közvetlenül kapcsolódó részeket teszteljük, vagyis amik ugyan abban az osztályban vagy névtérben vannak (package).
  • Amennyiben nincs elegendő metódus a projektben úgy ezt azonnal jelezzük a gyakorlat vezető felé. Az értékelés utáni panaszokat nem tudjuk elfogadni.
  • Ne teszteljük többször ugyanazt. Amennyiben nincs elegendő metódus úgy pontosan válasszuk el hogy ki melyik esetet teszteli, például helyes és helytelen bemenetre való viselkedés.
  • Az indoklás és magyarázat nélküli lefedettségi adatokat nem fogadjuk el.

Leadandók és teljesítendők

Tesztelés jegyzőkönyv és lefedettségi jelentés

Tulajdonság Érték
névkonvenció /doc/testing/hcsapatnévi-testreport.md
formátum folyószöveges dokumentum
min. méret 2 oldal/fő
értékelési mód személyenként egyénileg
kötelező? igen
max. pontszám 5 pont/fő

Egység/unit tesztek forráskódja

Tulajdonság Érték
névkonvenció /src/??/?.java
formátum forráskód fájlok
min. méret 10 különböző metódus tesztjei
értékelési mód személyenként egyénileg
kötelező? igen
max. pontszám 5 pont/fő

Minőségriport statikus kódelemzés alapján

rövidítés max. pontszám min. pontszám
static feladat 50 pont/csapat 5 pont/fő

A feladat célja hogy képet kapjunk a projekt minőségéről és ennek változásáról a módosítások elvégzése előtt, közben és után. Ezért a fejlesztések végén a projektről minőségriport készül a projekt kezdeti és végső állapota alapján. A riportot a gyakorlatokon bemutatott eszközök segítségével ajánlott elkészíteni, de használható más eszköz is saját felelősségre.

Az elemzésben és a bemutató során részletezni kell a következőket: - A projekt forráskódjának metrikák és egyéb mért jellemzőkkel alátámasztott kezdeti és fejlesztés utáni minősége, annak változása. - A megvalósítás (forráskód) metrikákból levonható és konkrét példákkal alátámasztott jellegzetességei. Elemezhetőek többek között az egyes metrikák - kiemelkedő értékeinek magyarázata és jogossága - értékeinek egymással való kapcsolata és ezek pozitív, negatív vagy semleges hatása a fejlesztett projektre - időbeli változásának értékelése és magyarázata - A forráskód szabálysértések vizsgálata. - jogos és jogtalan jelzések értékelése - leggyakoribb és legritkább jelzések magyarázata - figyelmet érdemlő (pozitív vagy negatív) kódrészek bemutatása és magyarázata

Leadandók és teljesítendők

Minőségriport

Tulajdonság Érték
névkonvenció /doc/quality/static/hcsapatnévi-qualityreport.md
formátum folyószöveges dokumentum
min. méret 5 oldal/csapat
értékelési mód közös
kötelező? igen (feladat választása esetén)
max. pontszám 50 pont/csapat

A projekt minőségének és változásának bemutatása

Tulajdonság Érték
névkonvenció /doc/quality/static/hcsapatnévi-presentation.pdf
formátum prezentáció
max. méret 10 perc/csapat
értékelési mód közös
kötelező? nem
max. pontszám 5 pont/csapat

Tesztlefedettség vizsgálata}

rövidítés max. pontszám min. pontszám
coverage feladat 50 pont/csapat 5 pont/fő

Feladat a projekthez a csapat által végzett módosításokat ellenőrző (lefedő) tesztek implementálása és végrehajtása valamint tesztjegyzőkönyv készítése. A feladat során a unit tesztek forráskódját (*.java fájlok) és a lefedettségi eredményeket bemutató riportot a master branch-en kell elhelyezni és az testing tag-gel kell ellátni Git-ben.

A leadott anyagnak röviden magyaráznia kell a tesztelés és a hozzá kapcsolódó mérés során kapott értékeket, különös tekintettel a megvalósított módosításokhoz kapcsolódó forráskódét. A tesztelés során vegyük figyelembe és a leadott anyagban foglaljuk bele a következőket.

  • tesztelés során felhasznált eszközök és technikák ismertetése
  • létrehozott teszt csomag bemutatása
  • létrehozott tesztek pontos megadása (forráskód vagy szöveges)
    • előkészítés/előfeltételek (arrange)
    • végrehajtási lépések (act)
    • viselkedés és eredmények kiértékelése (assert)
  • végrehajtott tesztek sikerességének ismertetése
  • tesztek végrehajtása során a lefedettség szisztematikus (akár automatikus) mérése
    • felhasznált technikák és eszközök
    • lefedettségi érték indoklása
    • erősen és kevésbé lefedett kódelemek bemutatása (csapat által fejlesztett részekből)
    • könnyen és nehezebben tesztelhető funkciók és változtatások

Leadandók és teljesítendők

Tesztjegyzőkönyv

Tulajdonság Érték
névkonvenció /doc/quality/coverage/hcsapatnévi-testreport.md
formátum folyószöveges dokumentum
min. méret a csapat által végzett változtatások tesztelése
értékelési mód közös
kötelező? igen (feladat választása esetén)
max. pontszám 25 pont/csapat

Tesztlefedettség riport

Tulajdonság Érték
névkonvenció /doc/quality/coverage/hcsapatnévi-coveragereport.md
formátum folyószöveges dokumentum
min. méret a csapat által végzett változtatások lefedettsége
értékelési mód közös
kötelező? igen (feladat választása esetén)
max. pontszám 25 pont/csapat

A tesztlefedettség vizsgálatának bemutatása

Tulajdonság Érték
névkonvenció /doc/quality/coverage/hcsapatnévi-presentation.pdf
formátum prezentáció
max. méret 10 perc/csapat
értékelési mód közös
kötelező? nem
max. pontszám 5 pont/csapat

Utolsó frissítés: 2021-09-08 08:25:18