Nagy házi feladat – követelmények

Czirkos Zoltán · 2019.10.28.

A nagy házi feladat követelményei. A beadással kapcsolatos tudnivalók, értékelés, pontozási táblázat.

A tárgyban kötelező egy nagy házi feladat megoldása. A feladat szabadon választott. Lehet a listából is választani, vagy azokhoz hasonló nehézségű, az elvárásoknak megfelelő saját problémák is megoldhatóak.

A nagy házi megoldásához néhány tipp és segédlet egy külön oldalon található.

1. Követelmények

A nagy házi feladat a következő követelményeknek kell megfeleljen:

  • A feladatválasztást a laborvezető jóvá kell hagyja.
  • A kész megoldás és a dokumentáció bemutatása csak személyesen történhet, legkésőbb az utolsó oktatási hét végéig.
  • A nyelv lehetőségeinek kihasználása: strukturált felépítés, több modulra bontás, fájlkezelés, osztályok és adatszerkezetek.
  • A program mellé el kell készüljön a programozói és a felhasználói dokumentáció.

A fentiek között logikai és kapcsolat értendő: ha bármelyik hiányzik, a házi feladat nem elfogadható.

Az osztályok és adatszerkezetek tekintetében: a programnak összetett adatszerkezetet kell építenie, amely objektumok listáját vagy listák listáját használja. Ez nem helyettesíthető fájlműveletekkel, nem váltható ki egyéb nyelvi elemekkel. Nem tárolhatóak egy entitás adatai listában (pl. lista[0] egy ember neve, lista[1] a születési dátuma, lista[2] a lakcíme, ...) saját osztályok definiálása helyett.

Ezeket az adatszerkezeteket a függvények közt paraméterátadással és visszatérési értékekkel kell átadnia a programnak, nem használhat indokolatlanul globális változókat.

A fájlkezelésben olyan adatokat kell tudni kezelni, amelyek száma változik, vagy változhatna. Nem teljesíti a követelményt pl. egy olyan program, amelyik az elindításainak számát (egyetlen egy egész számot) tárol fájlban. Teljesíti viszont egy olyan, amelyik egy játék 10 elemű dicsőséglistáját tárolja. A 10 ugyan fix, de akár változhatna is. A fájlkezelés saját programkódon kell alapuljon, pl. grafikus könyvtár által betöltött kép nem számít saját fájlkezelésnek.

A nagy házi egyéni feladat. A plágium mindenképpen bukáshoz vezet, nincs második lehetőség.

2. A nagy házi részfeladatai

A hetek során az alábbi részfeladatokat kell megoldani. Az egyes részfeladatok megoldásához példákat mutat a minta nagy házi oldal.

A konkrét tárgykövetelmény az NHF 4-es (vagy pótlás esetén az 5-ös) megléte, annak elfogadása, és az elégséges pontszám elérése. A többi részfeladat ezen belül pontot ér, a nem teljesítésük esetén még lehet sikeres a nagy házi.

NHF 1. – választás

Ez a részfeladat a feladat kiválasztását jelenti. A listában szereplő feladatok közül is lehet választani, vagy saját, hasonló nehézségű feladatot is lehet hozni. A kiválasztott feladat utólag már nem lesz módosítható.

Saját, előző évben elkezdett házi feladat is választható. Akár változatlanul is leadható, de újra lesz pontozva. Mindenesetre ezt nem javasoljuk; a házi feladat elkészítése a gyakorlás fontos része.

NHF 2. – specifikáció

A nagy házi választása után a portálon meghirdetett időpontig fel kell tölteni a házi feladat specifikációját. Ez a kiadott feladat részletekbe menő pontosítása. A pontosítás célja az, hogy a program megrendelője, és a programot elkészítő programozó ugyanarra gondoljon, és ne a munka végén derüljön fény a félreértésekre. Ide tartozik a program feladatának leírása, a bemenetek és a várt kimenetek rögzítése, a program használatának leírása is. A specifikációban még nem kell a program belső felépítésével, működésével kapcsolatos részleteket megadni.

A pontosított specifikáció részletességére jellemző, hogy ha két külön programozó elkészíti a programot ugyanabból a specifikációból, de egymástól függetlenül dolgozva, akkor kívülről nézve nagyon hasonló programoknak kell keletkezniük. Amennyiben az eredeti, rövid specifikáció bármelyik része nem egyértelmű, akkor a pontosítás során egy lehetőség mellett dönteni kell. Ebben segítenek a laborvezetők is.

NHF 3. – félkész megoldás

A félkész megoldás lényege az, hogy a készülő program funkcionalitásának egy részét bemutassa: már látszania kell rajta akár felhasználói, akár programozói szemmel, hogy mi készül. Nem elegendő egy „hellóvilág” programot, vagy egy menüt feltölteni, a félkész változatnak valamennyire már működnie kell. Még nem kell hibamentes legyen, nem kell tartalmaznia az összes funkciót, sem felépítésében és használt adatszerkezeteiben nem kell a végleges programmal megegyezzen.

A félkész házinak kezdetleges dokumentációt már tartalmaznia kell: legalább egy rövid, fél-egy oldalas leírást arról, hogy mi az, ami már működik, és hogy az egyes feltöltött fájloknak, függvényeknek mi a szerepe.

Néhány példa. Kukacos játék esetén félkész házi lehet egy olyan program, amelyikben a kukac feje már mozog a képernyőn, és az étkeket össze lehet gyűjteni, de a kukacnak még nincsen farka, és nem nő. Telefonkönyves házi esetén félkész változat lehet az, ahol az adatokat már be tudja kérni a program, de nem tudja eltárolni, kereséseket még nem tud végezni, vagy képernyőre írja azt, amit amúgy fájlba mentene.

NHF 4. – végleges program
Ez az elkészült, végleges program leadása, forráskódokkal és dokumentációkkal.
NHF 5. – javítás vagy pótlás
Akinek a házi feladata nem készült el időben vagy nem elfogadható, az utolsó oktatási hét végéig pótolhatja azt. Ebben az esetben kevesebb pont jár a megoldásra. Javítás esetén (ha az NHF 4-es részfeladat elfogadott) a teljes pontszám megkapható.

3. A házi feladat beadása

NHF 1. – választás

A listából választott feladatok esetén a feladatkiírás vagy a cím bemásolásával választható ki a feladat. Saját feladat esetén röviden el kell magyarázni a majdan elkészülő program lényegét.

NHF 2–3–4. – programkódok és dokumentációk

A dokumentációkat és a forráskódot elektronikusan kell leadni, az adminisztrációs portálon. A megoldás forrásfájljait és dokumentációit kell feltölteni egy ZIP fájlban. A feltöltés formátumára az alábbi megkötések vonatkoznak:

  • A csomag ZIP formátumú, maximális mérete 1 MB forráskóddal és dokumentációval együtt.
  • A megoldás forrásfájljait *.py nevű szöveges fájlként kell leadni.
  • A specifikációt és a dokumentációt PDF formátumban kell leadni.
  • A feltöltésnek ezeket a fájlokat tartalmaznia kell, emailben küldés, illetve link nem elfogadható. Ha vannak egyéb, nagy adatfájlok, azokra lehet link.

A nagy házit a 13. vagy 14. heti laborgyakorlaton személyesen is be kell mutatni a laborvezetőnek. A laborvezető a megoldás saját elkészítését ellenőrzi: a program forráskódjával kapcsolatban kérdéseket tesz fel, esetleg annak módosítását kéri. A bemutatás után a laborvezető a feltöltött programot is megnézi és pontozza. Ez jelenti a házi feladat tényleges elfogadását, aminek szükséges, de nem elégséges feltétele a bemutatás. Rendszeres konzultációval a bemutatás kiváltható; ehhez a laborvezető hozzájárulása szükséges.

A javasolt PDF készítő letölthető innen: CutePDF. Telepítés után megjelenik egy fiktív nyomtató; arra nyomtatva készül a PDF fájl.

A viták elkerülése végett

  • Feltöltött fájlnak a megoldást közvetlenül tartalmaznia kell. PDF-ben feltöltött forráskódok nem elfogadhatóak. Internetes linkek, „emailben elküldve” megjegyzések nem elfogadhatóak, sem a beadandó szövegekre (specifikáció, dokumentáció), sem a forráskódra. A laborvezetők csak olyan fájlt fogadhatnak el, amely megoldásként lett beküldve, nem pedig üzenetként.
  • A rossz formátumban vagy hiányosan feltöltött, feltölteni próbált megoldások szintén nem elfogadhatóak. Amit a portál nem enged feltölteni, vagy feltöltés után automatikusan visszautasít, az biztosan nem elfogadható házi. Az automatikus visszautasítás okkal történik, formai hibák miatt.
  • A feltöltött csomag felesleges, különösen a fordítással automatikusan előállítható fájlokat (*.obj, *.exe stb.) nem tartalmazhat. Az ilyen feltöltéseket a portál automatikusan vissza fogja utasítani, és nem elfogadottnak minősülnek.
  • Ha túl nagyok a PDF-ek, akkor javasolt: a) kitörölni a felesleges, túlméretezett, vágatlan képeket, b) nem használni rengetegféle betűtípust (a tartalmat pontozzuk, nem a díszítéseket), c) egy PDF fájlban beadni a programozói és a felhasználói dokumentációt.
  • Ha a feltöltött csomag hiányos, vagy a programban alapvető technikai hiányosságok vannak, akkor a laborvezető utólag is megtagadhatja az elfogadást. A hibás feltöltés, követelményeknek nem megfelelés nem a laborvezető hibája, akkor sem, ha nem jelezte azonnal.
  • A házi feladat fájljaiért, mint adatvagyonért mindenki saját maga felelős. Rendszeres biztonsági mentést kell készíteni róla. „Meghalt a vinyóm, vírusos lett a gépem”, és ezekhez hasonló indokokkal sem fogadunk el késést. Javasolt Dropbox, Google Drive vagy hasonló szolgáltatások használata.
  • Gyakran visszatérő fordulat a „nem azt töltöttem fel, amit szerettem volna”. Ilyen indokkal sem fogadunk el késést. A feltöltött fájlt magad is le tudod tölteni; ellenőrizd, mit adsz be!

4. A végleges megoldás értékelése, pontozása

Általános követelmény a programmal szemben az, hogy a józan ész elvárásai szerint működjön. A programnak olyan magától értetődő képességekkel is kellhet rendelkeznie, amelyek a specifikációban külön nincsenek rögzítve. Például ha a specifikáció annyit mond, hogy a program egy nevet megjegyez, akkor elvárható az is, hogy a névben lehessen szóköz karakter. Vagy ha a specifikáció azt mondja, hogy a program bizonyos adatokat fájlba tud menteni, akkor elvárás az is, hogy vissza is tudja tölteni azokat.

A megoldásokat a laborvezetők pontozzák. A pontozást minőségbiztosítási okokból szúrópróbaszerűen központilag is ellenőrizzük; ugyanez reklamációra is ad lehetőséget.

Beadás előtt

Automatikusan elutasításra kerül

Vannak olyan elvi hibák és alapvető hiányosságok, amelyek esetén a beadás egyáltalán nem elfogadható. Érdemes a következő ellenőrzési listán végigmenni beadás előtt:

  • Nincs feltöltve a forráskód megfelelő formátumban. Esetleg csak link, megjegyzés van a forráskód helyett, vagy csak a fejlesztőkörnyezet projektfájlja.
  • Hiányzik a dokumentáció. Ha a felhasználói dokumentáció lényegében megegyezik a specifikációval, akkor is át kell szerkeszteni és fel kell tölteni.
  • A program leglényegesebb funkciói nem működnek, nem valósítja meg a specifikációját.
  • Az egész program egy forrásfájlban van, nincsen több modulra bontva.
  • A program nem használ fájlkezelést.
  • A program nem definiál saját osztályokat a tárolandó adatok modellezéséhez.
  • A program nem épít adatszerkezeteket, esetleg fájlműveletekkel próbálja kiváltani azokat.
  • A program indokolatlanul, túlzóan használ globális változókat a függvényparaméterek és visszatérési értékek helyes használata helyett.
  • A program a függvényhívást ciklusként használja: pl. a menu() meghívja az adatbevitel()-t, az pedig visszatérés nélkül meghívja a menu()-t, hogy az meghívhassa a keres()-t, ami megint meghívja a menu()-t stb.

Az elfogadott megoldás pontozása az alábbiak szerint történik. Összesen 20 pontot lehet elérni. Minden felsorolásjellel jelölt elem 1 pontos.

Jegyben:
20 pont

Pontozás

Határidők betartása

  • időben kiválasztva (NHF1 elfogadva és NHF4 elfogadva)
  • specifikáció időben elkészült (NHF2 elfogadva és NHF4 elfogadva)
  • félkész házi időben elkészült (NHF3 elfogadva és NHF4 elfogadva)
  • végleges házi időben elkészült (NHF4 elfogadva)

    NHF5-tel a fenti pontok nem javíthatók és pótláskor sem adhatók meg. Vagyis ha pl. a specifikáció nem készült el időben, akkor már nem szerezhető pont utólagos beadással; illetve ha az NHF4 nem volt elfogadva, akkor ezek mind elvesznek.

Programkód minősége

  • modulokra bontás minősége (tipikusan a main.py+fuggvenyek.py nem elég; pl. adatszerkezeteket kezelő modul, grafika modul, különféle menüket megjelenítő modul stb.)
  • funkcionális dekompozíció minősége (ne legyenek túl nagy függvények, és ne hívják egymást következetlen módon, pl. beolvasás a menüt)
  • adatszerkezetek, típusok használata (tipikusan: osztály bekerültek, amik összetartoznak; nem szamlalo, nevezo, hanem class Tort; nem rajzol(palya, szelesseg, magassag), hanem rajzol(palya), ahol az egy osztály; általában a túl sok paraméterű függvényekből látszik, hogy baj van)
  • helyes erőforráskezelés (fájlok bezárása, kivételek kezelésével vagy with blokkokkal)
  • nyelvi elemek helyes használata (ne legyen sok mágikus szám vagy sztring, helyes vezérlési szerkezetek, nincs from module import *)
  • a tárgyban elvárt kódolási stílust követi (van main() függvény, osztályok adattagjai már a konstruktorban létre vannak hozva)
  • nincsen telis-tele indokolatlanul újraimplementált szabványos függvénnyel
  • szerep szerinti változónevek, függvénynevek (nem a betűk száma a lényeg, lehetnek 1 betűsek; vmi, logikai – ezek nem)
  • 1. feladatfüggő pont, a feladat jellege alapján (tipikusan kisebb hibáért, hatékonytalanságért levonható, laborvezető indokolja)
  • 2. feladatfüggő pont, mint a fenti
  • 3. feladatfüggő pont, mint a fenti

Dokumentáció általában

  • a dokumentációk bekezdésekre és fejezetekre vannak tagolva, elfogadható a helyesírásuk, nincsenek bennük képként forráskódok, nincsenek felfújva (16-os betűméret, 4 cm margó, dupla sorköz, egyéb terjedelemnövelő technikák).

Programozói dokumentáció

  • a projekt felépítése (melyik fájl mit tartalmaz) és a szükséges környezet, külső könyvtárak leírása, telepítéshez szükséges lépések leírása (pl. grafikus könyvtár; ha nem igényel szabványos könyvtárakon kívül semmit, akkor ez a tény)
  • adatszerkezetek dokumentációja, tervezési megfontolások leírása (melyik típus és adatszerkezet mire való, mit tárol, miért arra esett a választás)
  • a függvények dokumentációja (feladat, paraméterek, visszatérés, esetleg körülmények, pl. xy nem lehet None)

Felhasználói dokumentáció

  • program feladata, célja; milyen bemenetek, kimenetek vannak, játéknál hogyan kell irányítani