.
.
- Jelen útmutató, illetve követelményleírás csak Sipos Miklós szakdolgozói számára vonatkozik.
- Más oktatóknál a pontos elvárások, határidők valamint egyéb részletek eltérhetnek.
- A repót csillagozzátok be és kövessetek be GitHubon, hogy lássátok a frissítéseket. Plusz nagyon sokan olvassátok a doksit annak ellenére, hogy nem nálam szakdolgoztok, így amolyan "like" funkciónak is nézem.
.
.
- Szakdolgozat I. tájékoztató
- Szakdolgozat II. tájékoztató
- Tervezés
- Tesztelés
- Prezentáció, védés, beszámoló
Jelen dokumentum keretein belül szeretném összefoglalni a Szakdolgozat I. tárgy menetrendjét, követelményeit és elvárásait. Kérnék mindenkit, hogy figyelmesen olvassa át és a félévben az itt leírtaknak megfelelően járjon el.
- MK 0.: 02. hét » feladatkiírási lap szövegének megfogalmazása
- MK 1.: 04. hét » hasonló rendszerek elemzése és bemutatása
- MK 2.: 08. hét » kapcsolódó témakörök irodalomkutatása / feldolgozása
- MK 3.: 10. hét » irodalomkutatás összegzése
- MK 4.: 13. hét » tervezés + követelmény specifikáció
Adott hét vasárnapjának 23:59 percéig szeretném Teams privát üzenet formájában megkapni a szakdoga aktuális (és az előzőhöz képest előrehaladottabb) változatát. Az üzenetben vázlatpontokban szívesen venném, ha fel lenne tüntetve, hogy mi került bele pluszként az előzőhöz képest. Ha a doksiban esetleg sárga háttérrel megjelölitek az is teljesen rendben van. A lényeg az lenne, hogy átnézve könnyen lássam egyből mi az inkrementum.
Küldéskor pdf verziót küldjetek.
A küldött dokumentum neve ez legyen: SZD1_MK[#]_[NEPTUN]_[TELJES-NÉV].pdf
(Értelemszerűen a [] jelek nem kellenek egyik esetben sem, oda a megefelelő értéket kell behelyettesíteni. Minden résznek végig nagybetűvel kell lennie.)
Ha valaki nem halad egyik mérföldkőről a másikra, akkor ilyen egyetlen alkalommal fordulhat elő. Ha egynél többször fordul elő, akkor a szakdoga1-et nem fogom aláírni félév végén. Ennek oka, hogy a félév utolsó hetében nem szeretnék senkinél/vel tüzet oltani, és lutrira sem fogok senkit átengedni. Legyen benne a munka és akkor nem lesz gond - mondanom sem kell, ez egyben a Ti érdeketek is!
Kivételt képez ez alól, ha szól előre az illető, hogy nagy a gáz / kiégtem idegileg a sok zh-tól / családi gond van / stb. Ez esetben az illetővel majd egyeztetek, hogy a mérföldkövet hova csúsztassuk.
A mérföldkövek után igyekszem mindenkinek visszajelezni a leadott munkával kapcsolatban, de legkésőbb az utolsó MK után biztosan lesz visszajelzés.
Szakdoga 1.-ben az irodalomkutatáson át a tervezésig kellene eljutni a félév végéig (tehát szakdoga2-őn már egyből neki kell tudni állni a fejlesztésnek), én viszont javasolnám, hogy picit menjünk tovább (ez főleg igaz azokra akik projektmunkát is nálam csinálják, hiszen nekik a pilot alkalmazás már készen van). Jó volna, ha egy nagyon basic demo alkalmazás is lenne, mert akkor nagyjából nekiálltok a feladat megoldásának és lehet már szembejön olyan kardinális probléma, hogy pl. x-y programmal meg se valósítható ez vagy az... és ha ez később jön szembe, akkor nagyon rohamtempóban kell dolgozni, javítani stb., ami senkinek nem jó.
A félév végén, vizsgaidőszak eleje környékén lesz szakdoga1 bemutató / védés hivatalos keretek között. Ezt megelőzően ha van rá igény, akkor nekem elő lehet adni a prezentációt demó jelleggel. Elmondom az észrevételeket, ezt követően pedig a javítandó részeket még tudjátok finomítani. A hivatalos védést komolyan kell venni, ezen áll vagy bukik ugyanis a tárgy teljesítése. Itt a bizottság a doksit is és az előadást is bírálja. A prezentációról, annak tartalmáról, terjedelméről és kinézetéről itt írok bővebben.
A feladatkiírási lap az, amely a hivatalos elvárásokat és cél megfogalmazását tartalmazza a szakdolgozat egészével kapcsolatban. Ennek megírásában számítanék rátok. Első körben ki kellene tölteni ezt a formot ahol kérlek pontosan adjátok meg az adataitokat (fontos, hogy minden úgy legyen ahogy az Neptunban is szerepel). A mintákhoz hasonló terjedelemben és fogalmazási stílusban kellene megírni a feladattal kapcsolatban támasztott elvárásokat és elküldeni nekem sima szövegként, Teams privát üzenetben. A kész feladatlapot ezt követően majd előállítom és leadom a Diplomáztatási Csoport irányába, illetve megküldöm részetekre is (így a félév végén le tudjátok adni).
Határidő: 2. szorgalmi hét vége (vasárnap 23:59)
Érdemes már most a sablon (elérhető az oldalamon Hivatalos Szakdolgozat tájékoztató néven) alapján elkezdeni (sorköz, térköz, margók stb. legyenek rendben). Azért lenne jó így haladni, mert akkor nem csak kilóra (karakter- és szószám) látjuk, hogy mennyi, hanem oldalak számára nézve is. Illetve nektek is talán könnyebb, ha már látjátok, hogy vannak fejezetcímek stb. Plusz, a félév végén amúgy is ilyen formázásban kell leadni is a dolgokat.
A hivatalos tájékoztatóban megadot paraméterek csak ajánlások, ezektől el lehet térni, ha az jobbá teszi a munkát. Az én javaslataim az alábbiak:
- a beépített Word-féle default kék fejezetcímes sablont engedjük el, legyen minden szöveges rész fekete
- a fejezetcímek sorszámai ne római számmal legyenek írva, hanem rendes arab számokkal
- a fejezetcímek sorszámaiban minden szám után legyen pont (tehát pl.: 2.1.1 Fejezet címe --> 2.1.1. Fejezet címe)
- a folyószöveg mérete legyen 12-es méretű, ehhez képest nézve:
- a 4. szintű fejezetcím legyen 13-as méretű és félkövér
- a 3. szintű fejezetcím legyen 14-es méretű és félkövér
- a 2. szintű fejezetcím legyen 16-os méretű és félkövér
- az 1. szintű fejezetcím legyen 20-as méretű és félkövér
- minden 1. szintű fejezet kezdődjön fixen új oldalon
- a fejezetek legyenek balra igazítva
- a folyószöveg legyen sorkizárt stílusú mindenhol
- a betűtípus Times New Roman (de mindenképpen valamilyen talpas típus)
- az alfejezetek három szint mélységig legyenek sorszámozva (negyedik szintig még el lehet menni sorszámozással, de törekedni kell arra, hogy ilyen mélység esetén máshogy legyen strukturálva a dokumentum)
Szintén javaslom, hogy könyvjelzőzzetek el minden képet / hivatkozást / irodalmat, amikkel találkoztok, mert ezeket mind bele kell majd tenni és lehivatkozni! Utólag keresgélni nagyon rossz dolog.
A félév végén, de legkésőbb Szakdolgozat II. leadást követően -- még záróvizsgázás előtt (!) -- a kész dolgozatot fel kell tölteni egy plágium ellenőrző rendszerbe, amely végeredménye egy számérték lesz, hogy mennyi egyezőség van más munkákkal, azaz, hogy mennyire plagizáltatok a dolgozatban. Ebben lehetséges, hogy csak arra fog kiadni egyezőséget, hogy a feldolgozott irodalmak azonosak másokéval -- ez természetesen nem baj. Ha viszont, konkrét részek, fejezetek vannak átemelve, az hatalmas probléma (még akkor is, ha egyébként az a tartalmi rész lehivatkozásra kerül a dolgozatban az irodalomjegyzékben). Ezért, konkrétan átemelt részben mindig pontos idézésmegjelöléssel kell ezeket a részeket ellátni. Egyéb esetben törekedni kell a saját megfogalmazásra!
Az alábbi képen bal oldalt látható a végső számérték, lebontva, hogy mely forrásokból történt a plagizálás; jobb oldalt pedig a leadott dolgozat oldalanként végigvezetve (amelyből csak 1 oldalt emeltem most ki) és kiemelve, hogy mely részek, mettől-meddig számítanak plagizálásnak.
A felhasznált irodalmakat (ahol törekedni kell a könyvek, folyóiratok, cikkek felhasználására, szemben random netes linkekkel) forrásként le is kell hivatkozni. Ezt azt jelenti, hogy a dolgozatban bizonyos részeknél amikor állítást fogalmaztok meg oda kell rakni, hogy ezt az állítást milyen forrásból szedted, mivel támasztod alá. Például, ha azt állítom, hogy a Vue a leggyorsabb keretrendszer akkor ezt alá kell tudjam támasztani valamilyen statisztikai adattal ami mondjuk az elmúlt 1 évben jelent meg lehetőség szerint valamilyen könyvben, vagy hivatalosnak tekinthető forrásban.
A lehivatkozásokat IEEE formában kell megtenni. Egy magyarázó link alább található a "Javasolt fejezetcímek / Irodalomjegyzék" részben.
A folyószövegben a dolgozatba berakott ábrákat le kell hivatkozni! Ennek egyik része az, hogy a szövegben konkrétan bele kell írni azt, amikor valami olyanról írunk, amihez / ami miatt az adott ábrát beraktuk. Ekkor jelenjen meg a szövegben pl. a következő: "... ahogy az a(z) X.Y. ábrán látható", ahol X.Y. az adott ábra sorszáma lesz. Ez kiváltható azzal is, ha zárójelben odaírjuk a mondat végére, hogy: "(X.Y. ábra)"
A lehivatkozás másik része, hogy az ábrának forrását meg kell jelölni, mint az irodalom lehivatkozása esetén. Erről alább, a "Javasolt fejezetcímek / Ábrajegyzék" részben írok.
Az ábrákat a dolgozatba berakva olyan stílusban kell használni, hogy felette / alatta legyen szöveg, ilyen szöveg-körbefuttatás ne legyen. Mondatot ne vágjon ketté ábra.
Az ábráknak legyen egy sorszáma, amely tartalmazza a fejezet sorszámát, majd fejezetenként egy egytől induló számozást. A fentebbi példában az X.Y. esetén az X a fejezet, az Y az ábra sorszáma a fejzeten belül.
Az ábra címe mindig úgy épüljön fel, hogy: "X.Y. ábra: Valami rövidebb vagy hosszabb magyarázó mondat arról, hogy éppen mit látunk a képen és ez miért fontos. Nyugodtan lehet akár két mondatot is írni!" Tehát legyen egy sorszám, utána pont, majd az a szó, hogy ábra, majd egy kettősponttal legyen elválasztva a rövidebb vagy hosszabb magyarázó szöveg.
Alapvetően nincs megkötés, hogy Word-ben (esetleg Linuxos vagy Maces alternatívában (bár Macre van Word)) dolgoztok, vagy pedig LaTex-ben. Ha utóbbihoz már értesz, vagy érdekel és szeretnéd megtanulni, akkor én javasolnám, hogy itt az idő. Egy idő után sokkal jobb lesz benne szerkeszteni és kevesebb szívás lesz vele mint Wordben. Ha így tesztek és Tex-ben dolgoztok akkor a leadáskor doc/docx verziótok nem lesz, csak pdf. Ez esetben annyit meg lehet tenni, hogy készítetek egy külön Word fájlt a fedlappal és beleírjátok, hogy a dolgozat tex-ben került elkészítésre, ezért pdf-ként érhető el a dokumentum.
Absztrakt- sorszámozás nélküli fejezet
- rövid, háromnegyed oldalas kivonata a teljes dolgozat tartalmának
- elolvasva az olvasó egy átfogó képet kell kapjon a teljes munkáról / dolgozatról (mi volt a cél, mik voltak elemezve, mi lett megtervezve és milyen eredmények lettek elérve)
- az absztrakt tartalmazza majd a Szakdolgozat II. tárgyon véglegesített dokumentum teljes tartalmát, tehát az elért eredményeket is, röviden, tényszerűen tőmondatokban
Abstract- sorszámozás nélküli fejezet
- ugyan az, angolul
Tartalomjegyzék- sorszámozás nélküli fejezet
- a következő fejezeteket tartalmazó tartalomjegyzék
- harmadik szintű mélységig jelenjenek meg a fejezetek nevei és a hozzá tartozó oldalszámok (jó az, amit a Word/LaTeX generál)
1. Bevezetés(max 2 oldal)- innen induljon a fejezetek sorszámozása, tehát ez az 1. fejezet
- bevezető leírása a teljes dolgozatnak
- ismertető, hogy miről lesz szó
- a cél megfogalmazása
- motiváció a probléma megoldására
- (szemben az absztrakttal, ebben nincsenek benne az elért eredmények, tehát ténylegesen csak egy kedvcsináló, bevezető (~trailer) a teljes dolgozathoz)
2. Irodalomkutatás(~ 20 - 25 oldal)- 2.1. Hasonló rendszerek (ez fix fejezet)
- azon belül a vizsgált rendszerek bemutatása és levont következtetések
- a fejezet végén legyen egy táblázatos összefoglalása a vizsgált rendszereknek
- a táblázatban legyenek benne a szempontok, hogy mik alapján hasonlítottad össze a rendszereket, majd a szempontok alapján pontozd az egyes rendszereket
- a szempontok természetesen minden szakdolgozat téma esetén mások, szubjektívek az adott témára vonatkozó hasonló rendszereket illetően
- a szempontok pl. olyanok legyenek, amelyek alapján a saját készítendő rendszeredet értékelni szeretnéd
- a táblázat további célja, hogy egyértelműen (számszerűen!) kiderüljön, hogy mely funkciók érhetők el a vizsgált hasonló rendszerekben és ha elérhetők akkor mennyire működnek jól
- egyéb, az irodalomkutatáshoz kapcsolódó feldolgozandó téma #1
- egyéb, az irodalomkutatáshoz kapcsolódó feldolgozandó téma #2
- ...
- egyéb, az irodalomkutatáshoz kapcsolódó feldolgozandó téma #n
- ilyen témák azok, amelyek kapcsolódnak a te munkádhoz
- szoftverfejlesztés esetén pl. lehet írni a Git-ről és különböző workflow-król, elemezni azokat, hogy melyiket fogod választani
- különböző algoritmusok amelyeket a szakterületen alkalmaznak (pl. képfeldolgozó vagy útkereső algoritmusok)
- ilyen témák azok, amelyek kapcsolódnak a te munkádhoz
- Összegzés (ez fix fejezet)
- összefoglalása az irodalomkutatásnak, mire jutottunk, ez alapján mit fogok csinálni a megvalósítás kapcsán
- 2.1. Hasonló rendszerek (ez fix fejezet)
3. Követelmény specifikáció(~ 1 oldal)- definiálni, hogy mik azok a szempontok, amiket elvárunk a rendszertől
4. Tervezés(~ 10 oldal)- készítendő rendszer megtervezése
- rendszerterv: (ez fix fejezet)
- ahol minden mindennel kommunikál, egyben legyen látható az egész szakdoga (=fejlesztendő rendszer) tartalma
- az egyes részek legyenek külön megtervezve (pl. adatbázis EK modell és/vagy táblás modell, szoftverben a modulok és azok kapcsolódása stb.)
- funkciólista: (ez fix fejezet)
- a rendszertől (felsorolás szinten) milyen funkciókat várunk el (esetleg ezek rövid leírása 1 mondatban kb.)
- a főbb funkciókról legyen valamilyen tervezési diagram (pl. szekvencia diagram) amely az adott feladat működésének lényegét szemlélteti
- fejlesztés tervezett menete: (ez fix fejezet)
- legyen egy konkrét roadmap vagy Gantt-diagram alapú szemléltetése annak, hogy honnan fogod kezdeni a szakdoga2-őt és abban milyen sorrendben és milyen lépésekkel fogsz haladni
- bővebben, ábrákkal szemléltetett leírás a tervezésről itt olvasható
5. Fejlesztés: ha van rá idő, egy minimálisan működő demó rendszer elkészítéseIrodalomjegyzék- sorszámozás nélküli fejezet
- IEEE formátumban kell elkészíteni (részletes leírás itt)
Ábrajegyzék- sorszámozás nélküli fejezet
- érdemes törekedni a saját készítésű ábrákra, így ha van rá mód, akkor érdemes és javasolt egy ábrát újra megrajzolni (pl. blokkos ábrák könnyen előállíthatók powerpoint-ban vagy draw.io-ban)
- amely ábra saját készítésű azok az ábrajegyzékben legyenek megjelölve, hogy "Saját készítésű ábra", így nem kell hozzá hivatkozást társítani; egyéb esetben jelenjen meg, hogy adott ábra milyen hivatkozásból származik (ezt a hivatkozást az irodalmi hivatkozások közé is nyugodtan fel lehet venni és akkor az ábránál csak a hivatkozás száma pl.
[10]jelenik meg)
Táblajegyzék(ha van)- sorszámozás nélküli fejezet
A fentiek értelmében a Szakdolgozat I.-re elkészített dokumentum ~40 oldalnyi (releváns) terjedelemmel kell rendelkezzen. Ebbe a 8., 9. és 10. fejezetek által hozott oldalak nem számítanak bele. A 7. fejezet tartalma sem számítandó bele, ugyanis az a rész tekinthető úgy, hogy a Szakdolgozat II.-ről kerül "előrehozásra".
Ezt majd félév végén egyben mindenkinek aki jogosult rá én fogom kiállítani, ha minden rendben volt a félévben. A lényege, hogy azok a mérföldkövek hivatalosan dokumentálva legyenek, amelyeket a félév folyamán érintettünk. A kész konzultációs naplókat személyesen kell átvenni a félév végén tőlem, majd ezt le is kell adjátok a szakdolgozat feltöltésekor, mint bizonyíték, hogy a konzulens jóváhagyta a féléves munkát.
Kérek mindenkit, hogy a naplóra nagyon vigyázzon, mert majd a leköttetéskor (szakdoga 2 végén) ugyan ezt a példányt kell vinni és a szakdolgozatba belekötni. Ha összegyűrődik, eltűnik stb. akkor baj van.
Jelen dokumentum keretein belül szeretném összefoglalni a Szakdolgozat II. tárgy menetrendjét, követelményeit és elvárásait. Kérnék mindenkit, hogy figyelmesen olvassa át és a félévben az itt leírtaknak megfelelően járjon el.
- MK 0.: 01. hét » repository létrehozása (lásd lentebbi "repository létrehozása" rész)
- MK 1.: 03. hét » fejlesztés erőteljesen kell, hogy menjen már 3 hete
- MK 2.: 06. hét » minimálisan működő rendszert már kell látni ezen a ponton
- MK 3.: 10. hét » a fejlesztéssel nagyjából készen kell lenni, a legtöbb funkciónak működnie kell; a 11. héten már a tesztelésre kell rátérni
- MK 4.: 12. hét » fejlesztés és tesztelés kész, dokumentálás végső simításait kell elvégezni
Adott hét vasárnapjának 23:59 percéig szeretném Teams privát üzenet formájában megkapni a szakdoga aktuális (és az előzőhöz képest előrehaladottabb) változatát. Az üzenetben vázlatpontokban szívesen venném, ha fel lenne tüntetve, hogy mi került bele pluszként az előzőhöz képest. Ha a doksiban esetleg sárga háttérrel megjelölitek az is teljesen rendben van. A lényeg az lenne, hogy átnézve könnyen lássam egyből mi az inkrementum. Ha a dokumentum nem módosult -- ami a fejlesztés szakaszban előfordulhat -- akkor "új" verziót nem szükséges küldeni, ez esetben viszont kérném, hogy a küldött üzenetben felsorolás-szerűen (!) legyen ott, hogy mivel haladtatok / mi van még hátra / milyen problémák merültek fel.
Küldéskor pdf verziót küldjetek.
A küldött dokumentum neve ez legyen: SZD2_MK[#]_[NEPTUN]_[TELJES-NÉV].pdf
(Értelemszerűen a [] jelek nem kellenek egyik esetben sem, oda a megefelelő értéket kell behelyettesíteni. Minden résznek végig nagybetűvel kell lennie.)
Ha valaki nem halad egyik mérföldkőről a másikra, akkor ilyen egyetlen alkalommal fordulhat elő. Ha egynél többször fordul elő, akkor a szakdoga2-őt nem fogom aláírni félév végén. Ennek oka, hogy a félév utolsó hetében nem szeretnék senkinél/vel tüzet oltani, és lutrira sem fogok senkit átengedni. Legyen benne a munka és akkor nem lesz gond - mondanom sem kell, ez egyben a Ti érdeketek is!
Kivételt képez ez alól, ha szól előre az illető, hogy nagy a gáz / kiégtem idegileg a sok zh-tól / családi gond van / stb. Ez esetben az illetővel majd egyeztetek, hogy a mérföldkövet hova csúsztassuk.
A mérföldkövek után igyekszem mindenkinek visszajelezni a leadott munkával kapcsolatban, de legkésőbb az utolsó MK után biztosan lesz visszajelzés.
A repository létrehozásának a következő a menete:
- a repót magát én fogom létrehozni a GitHub-on, a megfelelő group-on belül
- ehhez viszont kell, hogy küldjetek egy üzenetet nekem, hogy milyen email címre vagy GitHub account-ra küldhetem a meghívást, ehhez kérlek előtte regisztráljatok be
- ezt követően a repóhoz developer-ként meghívást fogok küldeni
Ha valaki korábbi projektmunkázó hallgató, akkor a már meglévő repóját fogom átmigrálni a projektmunkázó csoportból a szakdolgozó csoportba. Tehát újat nem kell majd létrehozni. A szükséges módosításokról majd Teams-en értesítek mindenkit.
A repó gyökerében ha én nem hozok létre alapból, akkor ti hozzatok létre egy README.md nevű és kiterjesztésű állományt. Az ebben foglaltak később felhasználhatók a dolgozat Mellékletek című fejezetében (ahogy erről lentebb is írok). Ebbe a readme-be kéretik röviden leírni, hogy:
- a projekt beüzemeléséhez milyen alkalmazások kellenek (és melyiket mire lehet használni); valamint, hogy milyen eszközök kellenek telepítve legyenek
- példa:
- alkalmazások: VSCode (kód megnyitása), DataGrip (adatbázis figyelése)
- eszközök: node, npm, angular cli (Angular frontend futtatásához), dotnet core xy verzió (backend futtatásához)
- példa:
- a projekt elindítása honnan és milyen paranccsal tehető meg
- példa: a backend-et a
dotnet build, majddotnet runparanccsal lehet futtatni a/backendmappából, a frontendet pedig a/clientmappából aznpm iparancsot követően azng serveparanccsal lehet futtatni
- példa: a backend-et a
- a beüzemelést követően mi honnan érhető el
- példa: a backend a
127.0.0.1/api/xyvégpontokon fogad kéréseket, de a swagger alocalhost:5000/api/swaggerurl-ől érhető el, a frontend pedig alocalhost:5500végpontről érhető el böngészőből
- példa: a backend a
- miután fut az alkalmazás, hol és milyen előre létrehozott user-pass párossal lehet belépni és tesztelni a funkciókat
A repót természetesen rendeltetésszerűen használjátok, tehát nem a félév végén szeretnék látni 1 db commit + push kombinációt, hanem szépen a munka előrehaladását, hétről-hétre lehetőleg. Erről egy elvárt commit history itt alább látható. A félév végére, a leadásnál minden a master branch-be legyen bemergelve, az tekinthető a végleges, leadott állapotnak.
Folytatva, a szakdolgozat I.-ben abbahagyott sorszámozást.
5. Fejlesztés(~ 10 oldal)- itt majdhogynem fejlesztési naplóként nyugodtan le lehet írni a dolgokat, annyi megkötéssel/javaslattal, hogy:
- minden apró-cseprő dolgot ne írjatok bele, törekedjetek a fontos dolgokat kiemelni; mindenképpen ilyen egy-egy probléma amibe belefutottatok, ami kapcsán aztán hoztatok egy döntést (ugye egy mérnök sok szívással szembesül, azok közül mérlegel, döntést hoz és halad tovább >> ezt volna jó viszont olvasni a dolgozatban is)
6. Tesztelés(~ 5 oldal)- elengedhetetlen része a Szakdolgozatnak; enélkül nem fogom elfogadni a Szakdolgozat 2-őt senkinek (hovatovább, záróvizsgán is sanszos ez)
- a lényeg, hogy meggyőződjünk arról, hogy amit csináltunk az jó-e / működik-e
- kicsit nézzetek utána, hogy milyen tesztek vannak (ezeket egyébként utólagosan az ir.kut-ba is nyugodtan bele lehet tenni)
- amit sw fejlsztés esetén mindig elő lehet kapni: unit teszt, manuális teszt, funkcionális teszt >> ezekhez többé kevésbé vannak dedikált tool-ok / keretrendszerek, nézzetek utána és válasszatok (a döntési folyamatot itt is lehet dokumentálni)
- tesztelésről bővebben itt írok
7. Értékelés(2 oldal)- eredmények bemutatása
- „miután lefejlesztettem amit kértek tőlem
- és leteszteltem, hogy azt csinálja-e amit kértek tőlem
- értékelem, hogy az elvárásokhoz képest mit tud / nem tud / miben tud többet”
8. Továbbfejlesztési lehetőségek(1 oldal)- milyen potenciális dolgokat látsz benne még, amire nem jutott idő / energia , de nagyon jó lenne ha még benne lenne
- az ötletek megalapozottak legyenek, ne légbőlkapottak
9. Összegzés(3/4 oldal)- rövid összefoglalás a dolgozatról, eredmények szummázása és a dolgozat lezárása
- az összegzés lehet kicsit személyesebb hangvételű is akár (pl. köszönetnyilvánítás)
- nagyon hasonló, mint az absztrakt, de:
- az absztrakt egy tömör kivonata a teljes munkának, amit elolvasva az olvasó egy átfogó képet kell kapjon a teljes munkáról / dolgozatról (mi volt a cél, mik voltak elemezve, mi lett megtervezve és milyen eredmények lettek elérve)
- az összegzés ehhez képest önmagában nem értelmezhető, csak akkor, ha a teljes dolgozatot végigolvasta az olvasó
Irodalomjegyzék- lásd Szakdolgozat 1.-ben taglaltak szerint
Ábrajegyzék- lásd Szakdolgozat 1.-ben taglaltak szerint
Táblajegyzék(ha van)- lásd Szakdolgozat 1.-ben taglaltak szerint
Mellékletek(ha van)- aki olyan rendszert csinált ami online is elérhető, ott javasolt mellékletekben megadni, hogy hol és hogyan érhető el a rendszer, milyen login adatokkal lehet belépni, stb.
- akinél nem ilyen dologról van szó, ott pedig leírni azokat a lépéseket amikkel a rendszert egy üres gépen be lehet üzemelni (tehát milyen szükséges keretrendszerek szükségesek a futtatáshoz (pl. node, dotnetcore stb.))
- itt egy az egyben felhasználók a repository readme-jében leírtak
- a kész rendszerről képeket, az egyes főbb funkciók bemutatását képekkel is ide kell elhelyezni és röviden leírni, hogy mit látunk
A fentiek értelmében (~20 oldal), valamint a Szakdolgozat I.-ben követett elvárások (~40 oldal) esetén a kész Szakdolgozat ideálisan 60-65 oldalas kell, hogy legyen. A kevesebb ugyan úgy nem jó, mint a (jelentősen) több! A Hivatalos Szakdolgozat tájékoztató (link az oldal alján) szerint 60 oldal az elvárt, ezt pár oldallal feljebb tudjuk tolni (innen a 65) ha ez szakmailag indokolt a dolgozatban.
Ugyan az igaz rá, mint szakdolgozat 1 esetén. A félévi mérföldköveket dokumentálja hivatalosan. Személyesen tőlem lehet átvenni majd a félév végén, amit aztán majd bele kell köttetni a dolgozatba.
A szakdolgozathoz tartozó anyagokat a Diplomáztatási Csoport elvárásai alapján kell majd feltölteni a portálra. Ebben benne van a szakdolgozat digitális verziója (pdf és docx egyaránt!), a prezentáció (pdf és pptx egyaránt!), valamint minden olyan egyéb kód, forráskód és egyéb, ami a munkát képviseli.
- Megírjátok a dolgozatot.
- A félév végén ha minden ok, elfogadom.
- Átadom a konz. naplót (nem aláírva).
- A konz. naplóval együtt (+ még sok dolog, amiket a Diplomáztatási Csoport ír meg nektek) elmentek kinyomtatni és leköttetni.
- A lekötött szakdogát visszahozzátok nekem és az utolsó lépés, hogy a konz. naplót aláírom a már bekötött szakdogában.
- Utána mehettek leadni a Diplomáztatási Csoport irodájába, aminek a határideje emlékeim szerint mindig: 14. szorgalmi hét szerda 15:00-ig bezárólag. Tehát én azt javasolnám, hogy 13. szorgalmi hét végére már 100%-os legyen a munka, hétfőn / kedden nyomtatás és köttetés, szerda leadás. (Megj.: nem tudom, hogy van-e ilyen +1 hét határidő díj ellenében, de nem is szeretnék ezzel foglalkozni; tartsuk magunkat a menetrendhez.)
- Köttetésnél én a CopyGuru-t javaslom, van egy a Jászai Mari tér környékén, szép munkát csinálnak.
- Mivel mindenki ilyenkor megy, ezért úgy dolgoznak, hogy 1 nap átfutás van (általában minden helyen 1-2 nap); de van SOS köttetés ami feláras, de akkor instant megcsinálják.
A szakdolgozat leadását követően, a konzulens egy külső, független bíráló személy bírálatát kezdeményezi. A bíráló személye alapvetően független az egyetemtől, de nem szükségszerűen. A bíráló egy olyan személy, aki a szakdolgozat témájában jártas, magas szintű szaktudással rendelkezik, így releváns megítéléssel tud lenni a szakdolgozat tartalmával kapcsolatban.
A bíráló vizsgálja a dolgozat külső, formai megjelenését; a szakmai tartalom komplexitását; a szakmai tartalom kidolgozásának részletességét és mélységét; valamint az elért eredményeket (azok összhangját az eredeti célkitűzéssel) és azok bemutatását.
Ezekhez az is hozzá tartozik, hogy a kódba belenéz, esetlegesen futtatja az alkalmazást - így meggyőződve arról, hogy minden tényleg elkészült-e és jól készült-e el. Éppen ezért fontos, hogy a repóban a readme-t ha megfelelően kitöltitek a fentebb írt elvárásoknak megfelelően, majd ugyan ezek mentén a dolgozat mellékletek fejezetében is leírjátok ezeket, akkor a bíráló könnyen be tudja üzemelni szükség esetén a leadott kódbázist.
Szakdolgozat II-ből nincsen olyan védés, mint szd1 esetén, viszont hivatalosan a szakdoga2 leadását követné a záróvizsga, ahol hasonlóan, mint szd1 esetén meg kell védeni és elő kell adni a dolgozatot amin dolgoztál. Természetesen a záróvizsga ideje csúszhat, ha te nem éppen akkor végzel. A védéshez szükséges szintén egy prezentáció, csak úgy mint szd1 esetén, erről mindenkivel egyeztetek majd ha ott tartunk. A prezentációról, annak tartalmáról, terjedelméről és kinézetéről itt írok bővebben.
A tervezés fejezet lényege, hogy be tudd mutatni azt, hogy a tanulmányaid ezen szakaszára eljutottál oda, hogy meg tudsz tervezni egy rendszert látatlanban. Nem baj és nem is biztos, hogy tökéletes lesz és nem kell semmit változtatni rajta, a lényeg, hogy tudj tervezni. Persze, törekedni kell arra, hogy amit megtervezel az a legkisebb mértékben legyen majd módosítva a megvalósítás folyamán -- de természetesen ilyen (hogy módosítani kell valamit) előfordulhat.
A tervezés fejezetben mindenképpen jelenjenek meg konkrét ábrák a különböző tervezési módszerek reprezentálására.
A lentebb található példák kész szakdolgozatokból vagy TDK dolgozatokból származnak, melyek felhasználhatóságát ezúton is köszönök hallgatóimnak.
Érdemes a rendszer fő egységét, vagy a rendszer egészét, vagy a rendszer legfontosabb és legkomplexebb részét (ez feladattól függ) bemutatni egy szekvenciadiagram segítségével, amely a megértést elősegíti, hiszen az egyes lépések illetve azok egymásutánisági tökéletesen látható erről.
Szintén vannak bizonyos folyamatok, amelyek nagyon jól szemléltethetők folyamatábra segítségével. Akár a rendszer teljes egészét, akár egy bizonyos kiemelendő részét érdemes így bemutatni.
A use case diagramok használatát érdemes limitálni, vagy legalábbis körültekintéssel kezelni. Amennyiben a rendszer nem kellően komplex, akkor az ilyen típusú diagramok túl egyszerűen néznek ki, ekkor pedig a dolgozat komolyságát rombolják.
Fontos, hogy megjelenjen egy high-level terv arról, amit szeretnél készíteni. Ez azért kell, mert máskülönben nem lesz "kézzel fogható" kimenete a tervezésnek. Itt nagyjából rád van bízva, hogy mennyire szeretnél részletes tervet készíteni, de mindenképpen tükröződnie kell a főbb moduloknak a tervből.
Szintén érdemes meghatározni egy agenda-szerűséget, hogy pontosan melyik komponensek fejlesztése élvez prioritást, valamint, hogy pontosan mi lesz a fejlesztésnek az általános üteme. Ezt lehet akár folyamatábrával vagy pedig Gantt-diagrammal is ábrázolni. Minden esetben jelenjen meg a tesztelés is, valamint erősen javasolt csúszási időtartalékkal is számolni.
A funkciólista akár egybe is vonható egy API végpont listával (amennyiben a feladat ezt a fajta fejlesztési módszert használja), de kezelhető külön fejezetként is. Amennyiben a feladatban van szerver-kliens kapcsolat és API alapú kommunikáció, úgy elvárt egy API végpont lista tervet készíteni, ami egybevághat a funkciólistával, de lehetnek eltérések is.
A tesztelés rész lényege, hogy valamilyen bizonyítékot tudjunk szolgáltatni arról, hogy amit csináltunk az jó és úgy működik, ahogy az elvárt. Itt feladatonként eltérhet, hogy milyen módszerrel és eszközzel tesztelünk, azonban a cél mindig ez lesz.
Fontos, hogy a tesztelésből készüljön egy táblázatos, jól feldolgozható és egyértelmű kimenet, ahol látható, hogy mit és miért teszteltünk és sikeres volt-e. Erről az alábbi ábra ad egy nagyon jó mintát/kiindulási alapot.
Természetesen ha egy teszt nem sikeres, mert valamilyen okból kifolyólag pl. azt a részét a fejlesztésnek nem sikerült sikeresen teljesítenünk, akkor nincs semmi gond, nyugodtan belekerülhet pl. piros x jelöléssel, hogy sikertelen. Ha az összkép szerint a lényeges és legtöbb dolog teljesül és sikeresen le lett fejlesztve, akkor nincs gond. A valósághoz hozzátartozik, hogy bizonyos dologra nem maradt kellő mértékű idő, ettől nem kell tartani.
Az alább látható példák kész szakdolgozatokból vagy TDK dolgozatokból származnak, melyek felhasználhatóságát ezúton is köszönök hallgatóimnak.
- általában 8-10 perces előadással készüljetek, de a hivatalos, adott félévre vonatkozó tájékoztató ettől eltérhet, így van, hogy csak 8, vagy akár csak 5 perc áll rendelkezésre
- az előadást úgy kell tudni felépíteni, hogy ha a helyszínen derül ki, hogy csak 5 perc áll rendelkezésre, akkor bizonyos részeket tudj rövidebben elmondani amik amúgy nem annyira lényegesek
- a tartalom tükrözze a féléves munkátokat, tehát:
- mi a dolgozat célja: az alap probléma és a célkitűzés bemutatása
- miket, miért és hogyan vizsgáltál meg: az irodalomkutatás bemutatása, a szakmai háttér ismertetése
- mit, miért és hogyan terveztél meg: kapjanak nagy hangsúlyt a tervezéssel kapcsolatos részek, úgy mint rendszerterv, specifikáció, diagrammok stb. (ez az a rész, ami már kézzel fogható saját munka)
- akiknek van munka projektmunka tárgyakról ott természetesen az is legyen benne mint "már fejlesztés alatt álló rendszer", esetleg rövid bemutatóval, hogy mit tud jelenleg. (bemutató esetén javaslom .gif készítését, mivel a ppt-ben vetítés közben az fixen és jól működik, videóval lehetnek gondok)
- tehát a fő lényeg, hogy a saját munkáról beszéljetek (mit csináltál, miért csináltad, hogyan csináltad) ne pedig arról, hogy a 128. keretrendszerben melyik függvényt hívnád majd meg itt-ott
- előre meghatározott "ennyi legyen" diaszám így konkrétan nincsen, de főbb fejezeteknek érdemes a szakdoga fejezeteit választani
- az előadást feltétlen gyakorold át párszor, legyen egy gondolatmenet a fejedben, hogy mi alapján akarod végigmondani az egészet
- ami mindenképpen legyen a diában:
- a diák legyenek oldalszámozva és legyen ott, hogy hányadik oldal a mennyiből (pl. 3/20) ==> ez azért kell, hogy lássa a bizottság, hogy kb. hol tartasz az előadásodban
- borító slide tartalmazzon minden lényeges információt, ehhez egy-két jó minta lentebb található
- szakdolgozat cím magyarul
- szakdolgozat cím angolul (kisebben)
- hallgató név
- hallgató neptunkód
- hallgató törzsszám
- végzés féléve
- konzulens neve és titulusa (a lentebbi minta borítóképek régebben készültek, jelenleg "Egyetemi Tanársegéd" a titulusom)
- specializáció megnevezése ahova jársz (teljes kiírás)
- nem begyakorolni a védést, mondván "úgyis menni fog majd"
- felolvasni a mondandó szöveget (ez ciki is és nincs rá lehetőség -- az felolvasás lenne, nem pedig előadás)
- hatalmas fejezetek rámásolva folyószövegként a diára
- nincs idő elolvasnia senkinek az előadás alatt
- elveszi a figyelmet rólad mint előadóról és arról amit mondasz
- túl apró betűket használni (otthon 4K monitoron lehet, hogy jól olvasható de kivetítőn sokszor más a helyzet)
- saját munkát előtérbe helyezni
- (mérnöki) döntési pontokat hangsúlyozni (indokolni, hogy miért úgy döntöttél ahogy)
- ábrákat alkalmazni, amiről könnyen és jól be lehet azonosítani a mondandó lényegét (pl. rendszerterv)
- legyen erős kontraszt a betűk és a háttér között pl. fehér háttér fekete betű. persze lehet színeket is használni de érdemes figyelni arra, hogy olvasható maradjon (és ez nem csak a 4K-s otthoni monitorra igaz, hanem egy gyengébb minőségű projektorra is legyen igaz! ez utóbbi sokszor nem színhelyes, nem éles)
- a legtöbb kivetítő 4:3 képaránnyal tud dolgozni, így javasolt ennek megfelelően készíteni a prezentációt
A hivatalos szakdolgozat tájékoztató weboldalon elérhető egy sablon amely már az új ÓE brand stílusához van igazítva, azonban ennek konkrét felhasználása kapcsán óvatosságra intenék mindenkit, ugyanis ha megnézitek, akkor a legtöbb dia sablon nem egészen úgy van kitalálva, hogy pl. szakdolgozattal kapcsolatos szakmai és technikai dolgokkal jól ki lehessen tölteni a helyet. Ettől függetlenül egy alapnak, kezdeti látványvilágnak teljesen jó ugródeszka lehet, de biztatnék mindenkit, hogy valami saját és egyedi sablont csináljon.
Nagyon hasonló a helyzet mint Szakdolgozat I. esetén, ami a változás: elkészült a rendszer. Ebből adódóan erről a kész rendszerről kell 60-70%-ban beszélni, és ami korábban szd1 beszámolóban volt az értelemszerűen redukálódni fog, ez megmarad 40-30%-ban.
A prezentáció időtartama szintén 10 perc. A százalékos felbontás alapján 3 perc bevezető (~szd1) és 7 perc eredmények bemutatása. (A 10 perces intervallum félévenként esetleg eltérhet. Vagy 10 vagy 15 perces blokkok szoktak lenni (de előfordulhat 8 perc is akár szintén), erről a hivatalos tájékoztatóban kell legyen információ. Ha nincs, kérdezzetek inkább rá.)
- szakd1-ről a bevezetése a témádnak, probléma felvetése és hogy mit készítettél, milyen eszközöket esetleg programnyelveket használtál (ez legyen tempós és gyors, nem ez a lényeg hanem a munka, lásd további pontok)
- hogyan jutottál el ide, milyen problémákkal szembesültél és ezeket hogyan oldottad meg (mérnöki döntések)
- mit tud a rendszer jelenleg (ehhez képest mi volt az elvárás / specifikáció)
- hogyan tesztelted a rendszert
- hogyan értékeled a kész rendszert (személyes oldalról és objektív (számszerűsíthető) oldalról)
- milyen továbbfejlesztési lehetőségeket látsz a rendszerben (akár amin javítani kell, akár ami a színvonalat tovább tudná emelni)
Bármilyen kérdés esetén keressetek bizalommal.
Sipos Miklós
Egyetemi tanársegéd
Óbudai Egyetem Neumann János Informatikai Kar
Szoftvertervezés és -fejlesztés Intézet
[email protected]
https://nik.siposm.hu