Hogy megkönnyítsük a gyakorlat menetébe való bekapcsolódást az első két héten (a felvételi és a szorgalmi időszak metszetében) úgynevezett "onboarding" alkalmakat tartunk a gyakorlat időpontjában. Ezek célja, hogy áttekintsük a gyakorlat mentetét, beleértve a követelményeket és hallgató, valamint a gyakorlatvezető feladatait is. Ez a folyamat hasonló a cégeknél is alkalmazott [szervezeti szocializációhoz](https://hu.wikipedia.org/wiki/Szervezeti_szocializ%C3%A1ci%C3%B3). Biztatjuk a hallgatókat hogy az onboarding alatt tegyenek fel minden olyan kérdést, mely felmerült bennük a gyakorlattal kapcsolatban. Természetesen erre a későbbiek során is lehetőségük lesz a gyakorlatvezetővel egyeztetett módon és időpontokban.
A gyakorlat célja, hogy a hallgatók betekintést nyerjenek egy már létező projekt fejlesztésébe való bekapcsolódásba. A félév során többféle aspektusból fogjuk megközelíteni az ehhez kapcsolódó, az iparban is gyakran használt módszereket és technológiákat.
A projektek sikerének egyik alapja a szakképzett munkaerő, amely képes értelmezni a helyzetet és megfelelő módszert kiválasztva az ahhoz kapcsolódó technológiák segítségével reagálni rá. Az eredményes munkához nem elég az egyes fogalmak lexikális ismerete, a szoftverfejlesztőnek tisztába kell lenni, hogy ezeket mikor és hogy tudja alkalmazni a projekt életciklusa során.
Erről a képességéről a hallgató egy ZH keretében ad számot. A sikeres félévhez legalább 60% teljesítendő.
A szakmai anyag elmélyítésének egyik módszere a valós példán keresztüli felhasználás. A hallgatók egy korábban elkezdett nyílt forráskódú projektbe kapcsolódnak be. Célunk, hogy egy valós példán keresztül tapasztalják meg a szoftverfejlesztéssel kapcsolatos kihívásokat és hozzák meg az ezekkel kapcsolatos döntéseket. A feladat célja nem csak a szükséges programozás elvégzése, hanem hogy a hallgató képes legyen valós környezetben is látni az e köré épülő egyéb folyamatokat.
Az elvégzett munkáról a hallgatók egy projektmunka keretében adnak számot. A sikeres félévhez legalább 60% teljesítendő.
A korábbi aspektusok szükségesek ahhoz hogy egy szoftverfejlesztő szakmailag korrekten tudja elvégezni a feladatát. Azonban ritkán fordul elő, hogy az adott fejlesztő teljes egészében átlátja a projektet. Általában különböző technológiákra és módszertanokra helyezik a hangsúlyt. Ez a speciális szaktudás értékesebbé teszi a fejlesztőt a munkaerő piacon.
A kurzus során szeretnénk terjeszteni a már meglévő speciális tudást és motiválni a mélyebb ismeretek megszerzését valamelyik (a hallgató által választott) témában.
A hallgatók egymásnak nyújtott segítségadás során mutatják be, hogy részletesebben ismerik az adott témát. A mentorálás során a hallgatók többletpontokat szerezhetnek, de hanyagság esetén pontlevonás jár.
A részfeladat elvégzése nem kötelező, de jelentősen lerövidítheti a munkakezdés során a betanulási időszakot. Illetve jobb bértárgyalási pozíciót ad a fejlesztő számára.
A korábbi aspektusok során felhasznált technológiák és módszerek dedikált kutatómunka eredményei. A szoftverfejlesztés gyorsan változó világában fokozottan fontos, hogy a szaktudást lépést tudjon tartani az ipar által támasztott igényekkel. A kurzus során szeretnénk lehetőséget adni arra, hogy a hallgatók betekintsenek a tudományos világba is, ezzel is segítve a későbbi karrierrel kapcsolatos döntéseiket.
A kutatói munka elvégzéséről a hallgatók egy kutatási terv vagy kibővített absztrakt megírásával adnak számot.
A részfeladat elvégzése nem kötelező. Azoknak ajánljuk, akiket érdekelnek az új még feltörekvő technológiák vagy a már ismert módszerek újszerű alkalmazása. Ez a feladat fontos lépés lehet a tudományos pálya felé vezető úton (doktori fokozat).
A szoftver rendszerek fejlesztése sok részből álló feladat. Ez a sokszínűség jelentkezik a gyakorlat mentén és a követelmények összetettségén. Ezért a gyakorlat anyaga és a követelmény rendszer első látásra bonyolultnak tűnhet. Az is. A gyakorlat témája nem teszi lehetővé, hogy egy bizonyos mértéknél nagyobb egyszerűsítéssel éljünk a félév során.
Az előadóval és a gyakorlatvezetővel úgy terveztük meg a kurzus tematikáját, hogy a lehető legtöbb a való világban is használt módszerrel és technológiákkal ismertessük meg a hallgatókat. A tudás és tapasztalat átadása közös munkát igényel a hallgatókkal. Célunk, hogy minél jobb és a való életben minél hasznosabb szaktudást adó képzést biztosítsunk, melyhez a félév végén szívesen fogadjuk a konstruktív javaslatokat.
Amennyiben a hallgató bármilyen oknál fogva nem tud részt venni az onboarding alkalmakon, úgy a követelményeket önállóan kell hogy megismerje a honlapon közölt információk alapján. Törekszünk rá hogy a honlap tartalma mindig tükrözze az onboarding során elhangzottakat.
Ahogy az valós szoftverfejlesztési projektek esetében, a gyakorlat során is fontos a követelmények ismerete és az erőforrások számbavétele. Ezek a gyakorlaton a [határidők](gyakorlat/folyamat/menetrend.md) betartása és a [feladatok](gyakorlat/folyamat/feladatok.md) megoldásának minősége, valamint a hallgatók ideje.
A hallgatók számára javasoljuk hogy a félév elején a menüben megadott sorrendben (mélységi bejárással) olvassák végig az oldalon közölt anyagot. Az egyes oldalak egyre több részletet fognak felfedni a gyakorlattal kapcsolatban.
Sem a hallgatóktól, sem az oktatóktól nem várjuk el, ennyi idő alatt fejből tudják az oldal teljes tartalmát. Szükség esetén az bármikor elérhető, hogy segítse a felmerülő kérdések megválaszolását. Azonban egy általános kép szemelőt tartása fontos, hiszen ez alapján lehet megtervezni a félév során elvégzendő munka ütemezését.
A hallgatók számára javasoljuk, hogy folyamatosan hajtsák végre a feladatokat. Az egyes részekre szánt időtartamot úgy határoztuk meg, hogy minél egyenletes intenzitású munkavégzés mellett kezelhető terhelést jelentsen a hallgatóknak.
Ezenkívül a hallgatóknak nem szükséges folyamatosan fejben tartani a gyakorlat teljes menetét. A gyakorlatvezető egyik feladata az hogy iránymutatást adjon, hogy az adott időszakban mely feladatok elvégzésére kell koncentrálnia a hallgatóknak. A hallgatóknak javasoljuk, hogy mindegyik részfeladat kezdetekor olvassák el újra a hozzá kapcsolódó leírást a honlapon.
Végül éljünk a kurzus nyújtotta lehetőségekkel. Minél hamarabb tegyük fel kérdéseineket és jelezzük problémánkat.
Az új ismeretek megszerzése nemes cél a hallgatók számára, bízunk benne, hogy a követelményrendszer ezt támogatni fogja. Azonban tisztában vagyunk vele, hogy emellett a végzettség szerzése is legalább olyan fontos. Javasoljuk, hogy az kurzusra szánt erőforrások megbecsülése során a jeles érdemjegy elérését tűzzük ki célul, hallgatók és oktatók egyaránt. Sajnos nem minden alakul minden esetben a tervek szerint, de bemelegítő gyakorlatként gondolkodjunk el az alábbi két kérdésen.
*Ha jeles elérésére terveztem, de mégse volt elég erőforrás milyen lehetőségeim maradnak?*
A továbbiakban a ,,/'' mindig a GitLab projekthez társított Git repository gyökerét jelzi.
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 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.
Csak azt a leadott anyagot tudjuk 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. Hogyan?)
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).
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.
Végül a leadandók bemutatása során szigorúan tartani kell az időkeretet. Ne tervezzünk túl hosszú prezentációt!
A hallgatóknak a munkájuk követésére heti rendszerességgel munkanaplót kell vezetni. A munkanapló célja kettős. Egyrészt vezetése ösztönzi a hallgatót a rendszeres munkavégzésre, másrészt a tevékenység követésére és a problémák időben történő feltárásának is alkalmas eszköze. A munkanapló az éles projektekben is kötelező elem, heti jelentés formájában készülnek.
A munkanapló rendszeres vezetése kötelező, még abban az esetben is, ha nem történik érdemleges változás. Munkanapló hiányában pontlevonás jár, amennyiben a hallgató egyáltalán nem készít egy adott feladatrészhez naplót, úgy az a feladat nem kerül értékelésre.
A munkanaplót sablonját ezen a linken találhatjuk. A naplót a GitLab projekt Wiki oldalára kell feltölteni az ott létrehozásra kerülő Hallgató munkanaplók page alá. Minden projektben résztvevő hallgató számára saját wiki oldalt kell létrehozni, ahova a saját munkanaplóját készítheti el, illetőleg töltheti fel. A javasolt formátum a markdown. A munkanapló beszámolási időszaka két gyakorlat közötti idő. A beadási határidő a következő gyakorlatot megelőző nap 24.00 óra.
A gyakorlatvezető a kiemelkedő egyéni teljesítményt (kezdeményező készség, megfelelő kommunikáció, csapatvezetés, stb.) plusz ponttal jutalmazhatja.
Ezenkívül 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.
A gyakorlatvezetők csak olyan hallgatók munkáját javasolják megajánlott jegyre, akik a gyakorlaton jeles (5) osztályzatot szereztek.
Bármilyen probléma esetén, a első előfordulás alkalmával tájékoztatni kell a gyakorlatvezetőt e-mailben, melyen minden érintett címezni kell (CC).
Bármelyik kötelezőnek megjelölt leadandó vagy a kötelező pont hiánya esetén a hallgató elégtelen érdemjegyet kap.
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.
CodeMetropolis az Irinyi Kabinetben
Előfeltételek:
Töltsük le a Sourcemetert és csomagoljuk ki.
Töltsük le a java 1.8-at coospaceről és csomagoljuk ki a Letöltések/Downloads mappába.
Klónozzuk a Codemetropolist
Lépések
lépés: Másoljuk be az elemezni kívánt programot a
SourceMeter-10.0.0-x64-Windows\Java\Demomappábalépés: A
SourceMeter-10.0.0-x64-Windows\Java\Demomappában futtassuk le a csatolt batch fájlt.
A batch fájl tartalma:
SET PATH=C:\Program Files\Java\jdk-11.0.13\bin;%PATH%
..\SourceMeterJava.exe -projectName=iFL4Eclipse -projectBaseDir=iFL4Eclipse\org.eclipse.sed.ifl.root\bundles -resultsDir=Results -FBFileList=fbfilelist.txt -runFB=true
Ha nem az iFL az elemzendő programunk, akkor a paramétereket át kell írnunk:
projectName = < Általunk választott string ami a projekt azonosítására szolgál >
projectBaseDir = < Megadom melyik mappában található a projekt >
resultsDir = < Hova kerüljön az elemzés, érdemes a Results mappát megadni >
A results mappa tartalmazni fogja a leelemzett fájlokat
lépés: Nyissuk ki a mappákat addig amíg nem találunk egy GRAPH kiterjesztésű gráf fájlt.
lépés: Nyissuk meg az Eclipset és töltsük be a CodeMetropolist, mint maven projekt
Kattintsunk a browse gombra és keressük meg a CodeMetropolist
Kattintsunk a Finish gombra
Kattintsunk a Run > Run Configurations gombra
Kattintsunk duplán a Maven Build-re a bal oldali panelen, majd adjuk meg az opciókat az alábbiak alapján. Ezután kattintsunk a Run gombra és várjuk meg, hogy BUILD SUCCESS üzenetet kapjunk a konzolon.
lépés: Másoljuk át a SourceMeter elemzett gráf fájlját (példa található coospacen) a CodeMetropolis distrobution mappájába (CodeMetropolis\sources\distro)
lépés: Futtasd le a következő batch scriptet vizualize.bat a distrobution mappából (CodeMetropolis\sources\distro)
A batch script tartalma a következő:
SET PATH=C:\Users\valaki\Downloads\jdk1.8.0_311\bin;%PATH%
java -jar .\converter-1.4.0.jar -t sourcemeter -s .\iFL4Eclipse.graph
java -jar .\mapping-1.4.0.jar -i .\converterToMapping.xml -m ..\..\examples\mapping\sourcemeter_mapping_example_2_0.xml
java -jar .\placing-1.4.0.jar -i .\mappingToPlacing.xml
java -jar .\rendering-1.4.0.jar -i .\placingToRendering.xml -world .\world\
:: Comment out any step you would like to skip with the "::" marker
A batch scriptet a CodeMetropolis distro mappájából indítsuk el.
Figyelem, a scriptben jelenleg az egész toolchain futtatása zajlik. Ha valaki csak egyes részeit szeretné futtatni annak az adott sort ki kell kommenteznie. Kommentezni dupla kettőspont és szóközzel lehet. (Pl. :: echo "This is a comment")
Az itt felsoroltak csak a kiemelten fontos formai dolgokat érintik, egyéb formai kérdésekben a gyakorlatvezető dönt.
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 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 alábbi ábra mutatja be a projektmunka első részének folyamatát. A diagram két részre bontható a szereplők alapján. Bal oldalt látható a gyakorlatvezető által végrehajtott lépések, jobbra a hallgatóé, szürke színnel kiemelve.
A hallgatók a CodeMetropolis nevű nyílt forráskódú projekt fejlesztésébe kapcsolódnak be. A projekt jelenleg GitHub szerveren található.
Igen, természetesen van lehetőség más projekten is dolgozni, azonban a követelményeket muszáj tartani minden hallgatónak. Tehát minden részfeladatot teljesíteni kell.
Továbbá kikötés, hogy a választott projekt csak Java alapú asztali alkalmazás lehet.
Más projekt választása esetén a hallgató feladata a program megértése, tehát többlet támogatást nem köteles a gyakorlatvezető adni. Ezentúl más projekt választása semmilyen előnnyel **nem** jár.
A gyakorlatvezetők a félév elején létrehoznak egy másolatot a projektből a [Hallgatói GitLab szerveren](http://gitlab-okt.sed.hu/users/sign_in) minden gyakorlathoz. A hallgatók ezen a szerveren nyugodtan kísérletezhetnek és dolgozhatnak, anélkül, hogy veszélyeztetnék a projekt központi kódbázisának állapotát.
Az egyes projektek és szerverek közötti kapcsolatot az alábbi deployment diagramm szemlélteti.
A központi GitHub (legfölső projekt) és az alatta lévő gyakorlatokhoz kapcsolódó projektek közötti szinkronizációt a gyakorlatvezető végzi el. Szintén a gyakorlatvezető hozza létre az egyes projekteket és a félévet összefogó csoportot is. Ezek az ábrán a középső sorban találhatóak.
A minden hallgatónak legalább egy issue-t kell választani, melyen a félév során dolgozni fog. A feladat az issue teljes életútjának végigkísérése, kezdve a kapcsolódó részek feltérképezésétől, a megvalósításon át, egészen a minőségbiztosítás és dokumentálásig.
Az [issue-k](https://github.com/codemetropolis/CodeMetropolis/labels/RF2) a félév elejétől kezdve elérhetőek az adott linken.
Az issue-k bonyolultságát, azt hogy hány hallgató számára ajánlott, és egyéb meta-információkat GitHub projektben jelezzük különböző címkékkel.
| címke | jelentés |
|---|---|
| RF2 | Rendszerfejlesztés 2 projektmunka számára ajánlott |
| Xstudent | X hallgató számára javasolt |
| complexityY | Y bonyolultságú issue |
Sajnos adminisztrációs okok miatt a különböző gyakorlatra járó hallgatók nem választhatják ugyanazt az issue-t.
Igen, de az ajánlástól való eltérést minden esetben jóvá kell hagyni a gyakorlatvezetőnek.
Ha bizonytalan vagy kérd ki a gyakorlatvezető tanácsát. Az issue nehézsége sok mindentől függ, egyik meghatározó tényező a fejlesztő korábbi tapasztalata, szaktudása és szakmai érdeklődése. Egy adatbázis tervezés lehet, hogy egyszerű feladat egy szakértőnek, de nehéz egy grafikus felületekkel foglalkozó kollégának.
Az issue leírása és hozzárendelt címkék mind fontos információval szolgálhatnak a választása során. Ha az issue-hoz tartozik megbeszélés, vagy kapcsolódó (akár lezárt) issue-k azokat is érdemes megnézni. Természetesen az adott projekt kódbázisába is célszerű bele pillantani.
Az issue-k kiválasztása időrendben történik, vagyis vitás esetekben a korábbi jelentkezést részesítjük előnyben. A választást a Coospace közös színtérben kell jelezni, a megadott eszközzel.
Az issue választási időszak után a gyakorlatvezető egy másolatot fog készíteni a kiválasztott issue-ról a hallgatói szerveren lévő projektben. A gyakorlatvezető az első jelentkező hallgatót hozzárendeli az új issue-hoz, illetve a többi hallgatót említi a leírásában. (Sajnos GitLab-ban nem lehet több embert egyszerre hozzárendelni egy issue-hoz.) Innentől a munka ebben az új issue-ban és a hallgatói szerveren folyik.
Az adott issue-választás csak akkor tekinthető jóváhagyottnak, ha a fenti hozzárendelés megtörténik.
Bármilyen bolond képes olyan kód írására, amit egy gép megért. A jó programozók kódját más emberek is megértik.
*Martin Fowler*
+ nehezen tudod régi kódjaidat megfejteni
+ sok megjegyzésre van szükséged kódolás közben
+ programjaidhoz nagyon nehéz új funkciót illeszteni
+ új funkciók hozzáadása után programod más részén érdekes dolgok történnek
Javasoljuk a [Tiszta kód](https://moly.hu/konyvek/robert-c-martin-tiszta-kod) elvek követését. Ezenkívül érdemes megérteni és elsajátítani a [tervezési minták](https://refactoring.guru/design-patterns) használatát. A fejlesztés során célszerű figyelni a ["bad smell"-ekre](https://refactoring.guru/refactoring/smells) majd különböző [újratervezési technikákkal](https://refactoring.guru/refactoring/techniques) javítani a forráskód minőségét.
A szoftverfejlesztés végső célja természetesen a megrendelő igényeinek kielégítése olyan módon, hogy az nyereséges legyen a fejlesztést végző szakemberek számára is. Természetesen a munka során rengeteg jogi, erkölcsi és szakmai elvet is figyelembe kell venni. A szoftverfejlesztés több mint pusztán forráskód írása, de ez természetesen része.
A megrendelők igényei általában követelmény specifikációként kerülnek rögzítésre. A fejlesztő csapat vezetője és más menedzserek ezt tovább bontják a fejlesztők számára is feldolgozható feladatokká, melyeket issue-k formájában rögzítenek. Ezt a folyamatot a gyakorlatvezető végzi el. A hallgatók az issue-kban megfogalmazott feladatoktól veszik át a munkát, mint egy fejlesztő csapat tagjai.
Szeretem, ha a kódom elegáns és hatékony. A kód logikája egyértelmű kell legyen, hogy nehezen rejtőzzenek hibák a sorok között. A függőségek legyenek minimálisak, mert ez megkönnyíti a karbantartást. A hibakezelés legyen teljes és a kód teljesítménye közel optimális, így nem kísérti az olvasóját további optimalizálásra, amellyel a tisztaságát veszélyezteti. A tiszta kód egy dolgot csinál, és azt jól.
*Bjarne Stroustrup*
A szoftver rendszerek fordítása (build) összetett sok lépésből álló folyamat. A fordítás során általában három rendszer dolgozik együtt: az operációs rendszer, az automatikus fordító és függőség feloldó rendszer, valamint a fejlesztés alatt álló rendszer maga. Ez közül nyílt forráskódú fejlesztés esetén a fejlesztett projekre erős, a build rendszerre kisebb, míg a fejlesztő operációs rendszerére szinte semmilyen befolyása nincsen a projekt menedzsmentnek. A gyakorlat ilyen (feltehetőleg erősen heterogén) környezetben, hogy legalább egy működő fordítási folyamatot definiál a projekt.
Ez a gyakorlat szempontjából azt jelenti, hogy amennyiben a hallgatók számítógépe megfelel a követelményekben leírtaknak és a projekt által megadott folyamatot követik, úgy a fordítás nagy valószínűséggel sikeresen végbemegy. A hallgatók otthoni gépére (egyéb szoftverek és beállítások) nincs befolyásunk. Természetesen a gyakorlatvezetők tanácsok segítségével iparkodnak majd elhárítani az esetleg egyedi problémákat.
A CodeMetropolis fordítására egy példa az [Irinyi Kabinetes gépek kontrolált és steril környezetében](build-kabinet.md) itt található. A gyakorlatvezetők saját belátásuk szerint plusz ponttal jutalmazhatják az egyes speciális fordítási hibák és mellékhatások felfedezését és dokumentálását.
<iframe width="560" height="315" src="https://www.youtube.com/embed/2w9v6_93Gmo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
A hallgatók a **Programozás és kódolás** részre 6 pontot kaphatnak. Ebben az alfeladatban teljesíteni kell az elvállalt issue-ban leírt igényeket.
A fejlesztés GitLab környezetben történik. A futtatható kódot az issue-hoz kapcsolódó `feature` branch-en kell elhelyezni a Git-ben. 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ő. Az hallgatóknak ismerniük kell a kapcsolódó issue-k megvalósítása során elvégzett főbb változtatásokat. A bemutatón az implementált változtatásokat, új feature-öket kell bemutatni.
A fejlesztő feladatai közé tartozik, hogy az általa készített programkódot később tovább lehessen fejleszteni, javítani. A forráskód minősége mellett a rendszer megértéséhez szinte minden esetben szükség van olyan információkra, melyek a megrendelő területéről származnak és nem programozástechnikai jellegűek.
A projektek esetén a fordítottja is igaz. A felhasználó általában nem rendelkezik átfogó informatikai ismeretekkel, vagyis ami a fejlesztő számára egyértelmű az a felhasználó számára sokszor nem az.
Ezeket a többlet információkat a különböző dokumentációk tartalmazzák. A fejlesztők általában saját maguk írják a fejlesztői (kódhoz közelebbi dokumentációt). Továbbá aktívan együttműködnek a PR szakemberekkel a felhasználói dokumentáció elkészítése során.
Asami Sato a robottankokat gyártó cég egyik vezető mérnöke. Úgy dönt hogy segít Korra-nak, Mako-nak és Bolin-nak elsajátítani a robottank programozásának alapjait. A lelkes tanulók gyorsan fejlődnek és sok új funkciót kódolnak le. A kódbázis heteken belül a duplájára nő.
Asami egyre több kérdést kap a cég fejlesztőitől, hogy magyarázza el bizonyos algoritmusok működését és osztályok szerepét a kódban. Lassan már arra sincs ideje, hogy az új prototípusok ütemezését átnézze.
Egyik nap Mako rákérdezett egy olyan kódra, melyet még Asami sem értett. A kódott Korra írta, de ő most éppen elutazott a családjához. A fejlesztés megállt. Asami úgy döntött ez így nem mehet tovább. Kötelezővé tette, hogy mindenki csatolja a speciális tudást az általa megírt kódhoz.
A fejlesztői dokumentáció olyan technikai tudást tartalmaz, amely segíti a többi programozót a rendszer továbbfejlesztésében.
A kód képes bizonyos mértékben leírni és magyarázni, hogy hogyan működik a rendszer. A probléma az hogy általában nem tartalmaz információt arról, hogy miért kell úgy működnie.
Például egy céges adatokat tartalmazó adatbázis tárolhatja a cégek nevét és a telephelyeket. Amíg az kiolvasható az adatbázisból, hogy egy telephely csak egy céghez tartozhat, addig nem lehet tudni, hogy ezt a hatályos jogszabályok, vagy a gyakorlati tapasztalat miatt van-e így, esetleg mindkettő. Ez az információ fontos, hiszen az előbbi esetben a rendszernek követnie kell a jogszabályok változását, míg utóbbinál csak a cég üzletpolitikáját kell figyelembe venni.
Fontos figyelembe venni, hogy a fejlesztői dokumentáció nem csak más fejlesztőknek, hanem saját magunk jövőbeli változatának is segítséget nyújthat.
Annyit hogy a kód könnyen érthető legyen egy speciális tudással nem rendelkező fejlesztő számára.
A pontatlan megjegyzések még rosszabbak, mint a megjegyzések teljesen hiánya. A megjegyzések írásának egyik gyakori oka a rossz kód. Érdemesebb inkább rendbe tenni a rossz kódot, mint megjegyzésekkel megtűzdelni. A dokumentálás során az alábbi sorrendet célszerű követni.
+ A publikus és protected elemek legyenek dokumentálva, kivétel egy-két triviális eset.
+ A kulcsfontosságú vagy összetett privát elemek legyenek dokumentálva.
+ A speciális szoftverfejlesztési szaktudást igénylő elemek kerüljenek dokumentálásra. Pl.: miért használtunk egyedi bináris objektum soros-konverziót.
+ Jogi megjegyzések
+ Informatív megjegyzések
+ Szándékot magyarázó megjegyzés
+ Tisztázó megjegyzés
+ Következményekre figyelmeztető megjegyzés
+ TODO megjegyzés
+ Megerősítő megjegyzés
+ Javadoc megjegyzés nyilvános API-ban
| Fajtája | Leírás | Példa |
|---------|--------|-------|
| Motyogás | hanyagul odavetett megjegyzés, mely legfeljebb a szerzőnek jelent valamit, más számára nem érthető | `//TBD`|
|Redundáns | nem szolgál semmiféle plusz információval a kódról, nem könnyebb elolvasni sem, mint magát a kódot | `// sqrt(i) + 42 / (id % 0x0123BA)` |
| Félrevezető | nem eléggé pontos megjegyzés | `// ellapsed time` (milyen mértékegységben?) |
| Kötelező | a nyilvánvalót magyarázó megjegyzés, ami csak azért van ott, mert megkövetelik, hogy minden függvényhez, változóhoz tartozzon dokumentációs megjegyzés | `//the constructor` |
| Napló | egy modul elején a benne végzett minden egyes módosítást naplószerűen dokumentáló megjegyzés | `//2042-06-01: Creation of the file` |
| Zaj-megjegyzés | új információval nem szolgáló, a magától értetődőt újra megfogalmazó megjegyzés | `// this method gets the name` (`string getName()` előtt) |
| Pozíciójelző/szalagcím | kód tagolására szokták használni, a legtöbb esetben újratervezéssel a kódban is kifejezhető | `// Class Variables` |
| Szerző neve | a verziókezelő rendszerek feleslegessé tették | `//author: Gergő Balogh` |
| Megjegyzésbe tett kód | mások azt fogják gondolni, hogy okkal van ott, fontos, és ezért nem lesz bátorságuk törölni | `//i += count % step` |
| Nem lokális | olyan megjegyzés, mely nem a közvetlen környezetében lévő kódra vonatkozik | |
| Pletyka | túl sok információt tartalmazó | `//base on Pythagorean (born around 570 BC) theorem a^2 + b^2 = c^2 where c is the hypotenuse` |
| Nem releváns | kódhoz nem nyilvánvalóan kapcsolódó | `//Java virtual machine (JVM) is a virtual machine that enables a computer to run Java programs` (adatbázis definíciós fájlban) |
| Rejtett Javadoc | Javadoc megjegyzés nem nyilvános kódban | |
A **Fejlesztői dokumentáció** részre a hallgató összesen 6 pontot kaphatnak. A dokumentálás során az egyes kódelemeket [Javadoc](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html) segítségével dokumentáljuk. Az algoritmusok és folyamatok egyéb részeit hagyományos kommentekkel kell ellátni, ahol a megértéshez a programozástechnikai tudáson túlmutató információra van szükség. Például, miért az adott képletet használta a távolság kiszámítására két épület között a CodeMetropolis Placing fázisában.
A felhasználói dokumentáció célja, hogy segítse a rendszer használatának elsajátítását. Ezt célszerű párhuzamba állítani a fejlesztői dokumentációval, melynek célja a továbbfejlesztés segítése.
A felhasználó nem rendelkezik szoftverfejlesztői, sőt az esetek többségében még informatikai tapasztalatokkal sem. Egy asztalos feladata, hogy meghatározott összegért bútorokat készítsen, nem várható el tőle, hogy ismerje a bankszámláját kezelő rendszer adatbázis-sémáját. A nagymama, aki receptet keres az unokája születésnapjára, nem fogja tudni, hogy a menüben és az ikonsoron lévő gomb ugyan azt az eseménykezelő metódust hívja. A portás, aki Bluetooth-os kamera rendszert használ nem tud sebezhetőségi elemzést futtatni a kódoló algoritmusokon, hogy meggyőződjön róla nem lehet-e lehallgatni a rendszert.
A CodeMetropolis-ban van lehetőségünk, hogy a bemenő adatokat különbözőképpen átalakítsuk a vizualizáció során ezzel javítva az ábrázolás kifejezőképességét. Ezt különböző konverziók segítségével tehetjük meg, melyeket a [codemetropolis.toolchain.mapping.conversions csomagban](https://github.com/codemetropolis/CodeMetropolis/tree/develop/sources/codemetropolis-toolchain-mapping/src/main/java/codemetropolis/toolchain/mapping/conversions) lévő osztályok valósítanak meg.
A rendszer felhasználója itt általában egy fejlesztő vagy kutató, aki szeretné megvizsgálni a forráskód (nem a CodeMetropolis, hanem egy másik rendszer) tuladjonságait. De lehet, hogy nem fér hozzá a forráskódhoz, nem ért "Java-ul" vagy nincs ideje a rendszer belső működését megismernie. A felhasználó csak a hivatalos oldalon lévő [dokumentációra](http://codemetropolis.github.io/CodeMetropolis/toolchain/mapping/) támaszkodhat.
A felhasználói dokumentáció megírása nem egyedül a fejlesztő feladata. A fejlesztő birtokában van számos olyan információnak, melyet a dokumentációnak tartalmazni kell, de ezek bemutatása során sok egyéb aspektust is figyelembe kell venni. Ilyen például a termék és a cég marketing céljai és egységes arculata. A terméknek illeszkednie kell az aktuális jogszabályi háttérbe. Végül a vezetők döntése hogy bizonyos funkciókat milyen ütemezéssel és költségekkel tesznek elérhetővé.
Teszt Elek egész este forgolódott az ágyában. Pár hónapja került be junior fejlesztőként a +Műtlek projekt fejlesztői csapatába. A termék egy új robotkar volt, melyet az olyan műtétek során használnának, ahol a legprofibb sebész keze se tud elég pontos vágásokat ejteni. Számítógépes grafikai tapasztalatai miatt a kar térbeli vezérlésének megtervezésével bízták meg. Az orvos megadja a kulcspontokat, majd a robot megfelelő mozdulatokkal összeköti ezeket.
Álmában a projekt óriási sikert aratott. Bankettek sora követte egymást, s a cég már az Egyesült Államokban is megkezdte az eszköz értékesítését. Elek épp az egyik Floridai értekezleten volt, amikor autóbalesetet szenvedett. Kórházba szállították, ahol már ott várta a műtőben az orvos, a +Műtlek robotkar és az asztalon a használati utasítása. Az orovos belelapozott a vaskos könyvbe.
"az origótól vett távolságot kell megadni" - dünnyögött magában az orvos. - "Nővér, az első bemetszészt a bal felső pontól 1.24 inch-re kezdjük meg. Altatást!"
Elek próbált kiáltani, hogy ne! az origó a jobb alsó pont és minden távolságot mm-ben kell megadni, de ekkor már a maszk a száján volt. S a világ elsötétült.
Teszt Elek remegve ébredt, még félálomban az első dolga az volt, hogy a koordináta rendszerhez kapcsolódó issue alá tett egy megjegyzést: "Felhasználói dokumentációt és követelményeket átnézni: mértékegységek és referencia pontok".
Azt hogy a fejlesztők a felhasználói dokumentációhoz szükséges adatokat milyen formában és módon adják meg az adott cégtől és projekttől függ.
A **Felhasználói dokumentáció** részre a hallgató összesen 5 pontot kaphatnak. A hallgató feladata hogy közvetlenül a választott issue lezárása előtti megjegyzésben röviden összefoglalja az elkészült munka felhasználásának lehetőségét és módjait. A leírásnak a használatra kell koncentrálnia és nem a rendszer belső elemeinek működésére vagy kapcsolataira. Ha az elkészült módosítás eltért az issue-ban megfogalmazott követelményektől, azt részletezni és indokolni kell.
| részfeladat | maximális pontszám |
|---|---|
| Programozás és kódolás | 6 |
| Fejlesztői dokumentáció | 6 |
| Felhasználói dokumentáció | 5 |
Cél az átvett projekt megismerése, és a kiválasztott issue elhelyezése a projekten belül. Ez a feladat két fő részre bontható. Azon kódrészletek, komponensek azonosítására melyek kapcsolódnak a kiválasztott issue-hoz. Valamint a kapcsolódó issue-k feltérképezésére.
A feladat részeként keressük meg azokat a kódrészleteket, melyeket előreláthatólag módosítani kell majd a feladat végrehajtása során. Ezután vegyük sorra azokat az elemeket, melyek felhasználják a módosított elemeket.
Ezen komponensek szerkezetét (UML package, osztály vagy egyéb szerkezeti diagram, pl. E/K) és fő funkcióit (UseCase, szekvencia diagram, funkcióleírások screenshotokkal) ábrázolhatjuk.
*Mennyi italt kell meginni a JATE-klubban hogy jól érezd magad?* A válasz hasonló az issue-k esetében is. Sok mindentől függ. Ki és mit iszik? Mennyire fáradt? Mit evett előtte? Stb. Általánosságban elmondható, hogy a következő lépéseket célszerű követni.
**Hol van?** Egy vagy több áttekintő ábrán bemutatni a projekt fő elemeit és ezek kapcsolatát, kijelölve (és a hozzá kapcsolódó leírásban kiemelve) a megoldandó issue helyét a rendszerben. Erre a komponens- és a deployment-diagram az egyik eszköz.
**Mire lesz jó?** Ha az issue új funkciót valósít meg, akkor röviden ismertetve a lehetséges felhasználási eseteket (pl. egy használati-eset diagramon keresztül).
**Hogyan működik?** Be kell mutatni a folyamatokat, melyeket végrehajt a kapcsolódó rész. Ezt szekvencia-, állapot-diagram vagy folyamatábra felhasználásával szokták megoldani.
**Hogyan lesz megvalósítva?** A technikai részleteket és módosítandó kód közvetlen környezetét osztály-, csomag-, vagy komponens-diagramal ábrázolják.
Az előző JATE-s példát tovább gondolva, fontos (és bizony kihívás is) hogy ne becsüljük alá vagy túl a szükséges információt. A cél, hogy egy másik fejlesztő az általunk adott adatok alapján megtudja válaszolni a fenti kérdéseket.
Egy jó teszt lehet, hogy mennyi magyarázat kell a közölt adatokhoz. Ha túl sok mindent kell még elmondani akkor az adatok hiányosak, ezeket a magyarázatokat célszerű leírni. Ha inkább azt kell megmutatni, hogy mit hol talál az illető, akkor lehet, hogy túl sok, vagy nem elég rendszerezett az információ.
Az értékelés miatt összesen legalább annyi diagramot kell átadni ahány fő dolgozik az adott issue-n (javasolt diagram típusok: [1](https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams), [2](https://en.wikipedia.org/wiki/Modeling_language#Graphical_types)). A feltöltés során mindenki a saját felhasználóját használja, hogy egyértelműen el tudjuk dönteni melyik rész kinek a munkája.
Az issue (és a projekt) megismerése során tapasztalt hiányosságok, nehézségek, esetleg pozitívumok rögzítése szintén fontos lehet a feladat végrehajtása során. A projektek komplexitása tetszőleges lehet, ezt átlagember egyszerűen nem képes átlátni. Szerencsére nincs is szükség emberfeletti memóriára, hiszen az issue-khoz rengetek információ kapcsolható, amely szükség esetén elérhető.
Tegyük fel hogy teljesen összeomlott az operációs rendszer a laptopodon. Szerencsére a munkádat feltöltötted a verziókövető rendszerbe, így az nem veszett el, de a gépet újra kell telepíteni. Vagyis a fejlesztési környezetet újra létre kell hozni és be kell állítani.
Mennyivel egyszerűbb dolgod lenne, ha a különböző környezeti változók értékeinek beállításait megtalálnád az issue alatt kigyűjtve. Nem kell rá emlékezni, hogy mik voltak, sem azt hogy vajon hova írtad fel őket hiszen minden az issue-hoz kapcsolódó tudás elérhető az issue alatt.
A feladat megoldása során felmerülő komplikációkról azonnal tájékoztatni kell a gyakorlatvezetőt (ha másképp nem rendelkezik akkor e-mail-ben).
Ha egy issue-hoz másikat kapcsolunk mindig adjuk meg hogy mi a kapcsolat köztük.
*Melyik segít többet?* `#42` vagy `előfeltétele: #42`
A **kapcsolódó komponensek megismerése** részfeladatra összesen 3 pontot lehet szerezni. Az issue-hoz kapcsolódó információkat az issue alá kell gyűjteni. Az folyamat során azonosított hibákat, fejlesztési javaslatokat és alfeladatokat új issue-ként kell rögzíteni és említéssel belinkelni a fő issue alá.
Képzeljük el hogy egy adott feladatot, pl. az egyik eszköz parancssori kimenetének színezését több különböző könyvtárral is meglehet oldani. Teszt Elek a HiperSzínes csomagot, míg Pró Béla a SzívárványConsole csomagot választja. A fejlesztés egészen addig gond nélkül folyik amíg össze nem ér a két rendszer. Pl.: szeretnénk kiemelni a hibaüzenetek színét egy közös helyre, hogy egységes legyen minden eszközben.
Ilyenkor az egyik megvalósítást át kell írni a másik javára, vagyis vagy Elek vagy Béla fölöslegesen dolgozott. Ez a kellemetlen helyzet és a projekt számára kidobott erőforrás (munkaidő) elkerülhető lett volna, ha Béla és Elek tisztában vannak az issue-k közötti kapcsolatokkal.
A példában bemutatott helyzet elkerülése érdekében az issue-kat (legalább) említésekkel össze szokták kötni. Az issue-k egy gráfot vagy hálózatot alkotnak. Azonban nem szabad elfelejteni, hogy a hálózat mögött emberek (szoftverfejlesztők) és az ő munkájuk közötti kapcsolat húzódik. A nagyobb méretű vagy összetett csapat-hierarchiával rendelkező projektek esetén ritka, hogy egy ember képes legyen átlátni az egyes feladatok közötti kapcsolatokat. Vegyük figyelembe, hogy a feladatokhoz technikai részletek is tartoznak, például, hogy melyik könyvtárcsomagot vagy tervezési mintát használjuk.
Ezek a jelenségek a projektmunka kapcsán is megfigyelhetőek. Bár a CodeMetropolis közepes méretű rendszerek közül a kisebbek közé tartozik, de a több gyakorlaton és szemeszteren átívelő fejlesztés növeli a folyamatok összetettségét. Ezt az alábbi csomag- és objektum-diagram mutatja.
Látható, hogy bizonyos esetben a hallgatók által választott issue-k olyan más issue-khoz kapcsolódnak amit másik gyakorlatra járó hallgató társuk választott. Az is előfordulhatnak olyan issue-k melyek ebben a félévben nem kerülnek megoldásra.
Nagyon ritkán fordul elő, hogy egy issue-ban leírt feladat független a többi issue-ban definiálttól. Az issue-k általában összetett hálózatot alkotnak, mely megismerése fontos lépés a feladat elvégzése során.
Fontos felismerni, hogy bár az issue-k listája szétbonthatóak kisebb csoportokra a kapcsolataik mentén, de ezek végül egy közös rendszerhez kapcsolódnak, ami itt a CodeMetropolis projekt. Vagyis szükséges összehangolni az egyes részeken végzett munkát. Ezt a projektszintű összehangolást a gyakorlatvezetők fogják végezni a hallgatók segítségével.
Képzeljük el, hogy vezetőként el kell döntenünk hogy a projektben mennyire készültek el a naplózás funkciók. Ez 3 issue-ban került kiosztásra 3 különböző fejlesztőnek. Kakszi Lajos szereti az angol (amerikai) szakkifejezéseket, például naplózás helyett loggol-ást használ. A szleng és a poénok megszállottja Turbók Imre szenior fejlesztő, soha nem hagy ki egyetlen szóviccet se, még akkor se ha csak ő érti. Végül Király Sándor, egy junior fejlesztő, nem igazán ismeri a szakkifejezéseket, ezért gyakran rosszul használja, például keveri a kimenet és a naplófájl fogalmát.
Vezetőként mennyilyen érzés lenne egymás után olvasni a 3 issue alá írt megjegyzéseiket? Mennyi időt venne el az egyes stílusok közötti váltás? Mire fordítnád az egységes stílus bevezetése után felszabaduló időd?
Az egyes funkciócsoportok egységességének biztosítása érdekében kijelölt vagy vállalt felelősöket szoktak alkalmazni a projekt menete során. A felelősöknek feladata, hogy az elkészült részek dokumentáltsága egységes formátumú és stílusú legyen. Ezt a kisebb módosítások és formázások (tipok, csoportosítás, tartalomjegyzék) elvégzésével, de legtöbb esetben a többi fejlesztő figyelmeztetésével és tanácsokkal éri el.
Az egyes részek felelőse nem parancsol és nincs mindig igaza. De az ő felelőssége hogy szemelőt tartsa az egységességet és ezzel kapcsolatban kifejezze az irányelveket és tanácsokat.
Az előző példát folytatva, Kakszi Lajos legújabb kedvenc rövidítése a SPOC (single point of contact). Ezért eldöntötte, hogy segít a projekt-menedzsernek. Készített egy sablont az issue-k számára, ami minden fontos információt tartalmaz. Létrehozott egy Wiki oldalt a projektkezelőben, amely az egyes kapcsolódó szakkifejezéseket tartalmazza. Végül ezek alapján (példaként) kijavította saját megjegyzéseit és issue-át.
A többieknek is átküldte az elkészült anyagot. Elmagyarázta Sanyinak, hogy miért fontos a megfelelő szakkifejezések használata. Felhívta Csoki (Imre) figyelmét, hogy sajnos a vicces megjegyzései sokszor félrevezetik a kezdő fejlesztőket, valamint sokkal nehezebb kiszűrni a lényeget.
A menedzser sokkal hamarabb végzett Lali és Sanyi issue-inak átnézésével. Így volt ideje a projektzáró sörözés megszervezésére, ahol sokat beszélgetett mindenkivel. Kiderült, hogy Sanyi szívesen képezné magát. Lalit a következő projekt során több funkciócsoport felügyeletére is felkérték, végül a bértárgyalás során fizetésemelést kapott konstruktív és felelősségteljes hozzáállásáért.
Sajnos Csoki stílusa nem sokat változott. A vezetőség felé egyre több panasz érkezett, hogy hátráltatja a munkát. Ezért a következő értékelés során közös megegyezéssel elhagyta a céget.
Ha a felelős nem kerül kijelölésre, minden érintett pontot veszít. Ha a hallgató figyelmen kívül hagyja a felelős jogos tanácsát, akkor tőle pontot vonunk le, de a felelős nem veszít emiatt pontot.
A hallgatók megfelelő issue-k választásával befolyásolhatják, hogy kivel kell szorosabban együtt dolgozniuk.
A negatív véleményeket, javításra vonatkozó tanácsokat általában illik privátban jelezni az érintett felé. Sajnos a vitás esetek elkerülése érdekében a gyakorlatvezetőket muszáj bevonni a felelős és a többi hallgató kommunikációjába. Ez a Coospace-n történik majd. Fokozottan ügyeljünk rá, hogy ne szégyenítsünk meg senkit a többiek előtt és törekedjünk az építő szándékú tanácsokra.
A felelősök számára csak az igazolható munkáért tudunk pontot adni: kommunikáció Coospace-n vagy GitLab-on.
A **Kapcsolódó issue-k összegyűjtése és munka összehangolása** részre a hallgató összesen 5 pontot kaphat. A hallgató feladata, hogy a kapcsolódó issue-kat hivatkozza (említse) a választott issue-ja alatt. Fontos hogy a feladat elvégzésének része az egymás közötti kommunikáció és egyeztetés.
Az összekapcsolódó issue-kat választó hallgatók közösen megegyeznek az adott funkciócsoport egységességéért felelős hallgató személyében. Ezt egy új issue létrehozásával jelzik `<funkciócsoport neve> egységesítése`, melyhez a felelős hozzárendeli magát és megjelöli benne a kapcsolódó issue-kat. Ezt az issue-t célszerű abba a gyakorlathoz tartozó projektbe létrehozni, ahol a felelős is található, mivel így könnyebb lesz megjelölni. Az élőző példa alapján az új issue `naplózás egységesítése` lenne, amihez Lali rendeli hozzá magát és a három issue kerül benne említésre.
| részfeladat | maximális pontszám | kinek? |
|-------------|--------------------:|--------|
| kapcsolódó issue-k megjelölése | 2 | mindenki |
| felelős választása és megjelölése | 1 | mindenki |
| egységesség segítése | 2 | felelősök |
| egységesség alkalmazása | 2 | nem felelősök |
*Mindenki szerezhet 3 pontot + (felelős szerezhet 2 pontot __vagy__ nem felelős szerezhet 2 pontoz) = 5 pont mindenkinek.*
Ha igen, honnan? Miért pont azt a részt írtad meg? Meddig tartott megkeresni a választ?
Ha nem, miért nem? Elfelejtetted?
A szoftver rendszerek az életciklusuk során folyamatosan változnak. Új verziók készülnek el, gyorsabb hardver jelennek meg, új operációs rendszer frissítéseket telepítenek. A technikai jellegű változásokon kívül a felhasználók igényei is folyamatosan alakulnak.
Képzeljük el, hogy frissen becsatlakozol egy hosszú ideje futó fejlesztési projektbe. A munkád során feltérképezed, hogy a feladatot melyik osztályt érinti. Sajnos a módosítás során előjön egy olyan kivétel, amelyet nem tudsz értelmezni.
Kihez fordulnál segítségül?
Biztos hogy mindegyik szenior átlétja a program minden részét?
A vezető fejlesztő mindenre tudja a választ?
A fenti kérdéseket a verziókövetéssel és a projekt menetének folyamatos dokumentálásával érhető el. Egy jól felépített és helyesen használt verziókövető rendszer esetén nem csak az adott osztály, de akár a kérdéses sor szerzőét is pillanatok alatt le lehet kérdezni.
A CodeMetropolis jelenleg szorosan támaszkodik a BlockModifier csomagra. Vajon miért került ez ennyire kiszervezve? Miért nem része a render eszköznek?
Egyáltalán miért fontos ezt tudnunk? A központi projektbe beemeléssel csökken a kezelendő függőségek száma, egyetlen egy fordítási folyamattal elő tudjuk állítani a BlockModifier és a CodeMetropolis legfrissebb változatát.
Bár a rendszer használ verziókövetést, ezt úgy tűnik ebben az időszakban elég hiányosan tette. A vizsgált könyvtár egyetlen [egy commit-ban szerepel](https://github.com/codemetropolis/CodeMetropolis/commits/master/dependencies/codemetropolis/cmblockmodifier/1.0.1/cmblockmodifier-1.0.1.jar), abban ami valószínűleg a teljes projektet átemelte egy korábbi verziókezelő rendszerből. Ez 2016-ban volt, gyakorlatilag az [első olyan commit](https://github.com/codemetropolis/CodeMetropolis/commits/master?after=8b7204a757aa753824512d6bd5240712b15d873e+69&branch=master) amiben tényleges forráskód szerepel.
A fejlesztők nem emlékeznek a pontos okra, hogy miért került ez a csomag külön, így ez örökre feledésbe merül. A tudás hiánya sajnos rizikót is jelent. Vajon ha beemeljük a központi projektbe azzal nem okozunk-e olyan problémát amire már nem emlékszünk?
A hallgató a **Forráskód verziókövetése** részfeladatra összesen 4 pontot szerezhet. A hallgató feladata a forráskódon végzett módosítások folyamatos verziókövetése Git rendszer segítségével.
| részfeladat | maximális pontszám | kinek? |
|-------------|--------------------:|--------|
| Git és GitLab használat | 2 | mindenki |
| git flow követése | 2 | mindenki |
A hallgatónak törekednie kell hogy segítse a további módosítások bevezetését. A fejlesztés során használjuk a git-flow branching modelt. Az értékelés során csak azokat az elemeket vesszük figyelembe ami a saját felhasználóval került fel a hallgatói GitLab szerverre.
A fejlesztés során a forráskódon kívül sok más információ is keletkezik. Ezek nyomon-követése és gyűjtése legalább annyira fontos mint a kódbázis maga.
Pró Barbara és Teszt Elek hallgatók ugyan azon a funkció csoporton dolgoznak a félév során. Hétfőn mindkettőjüknek elmarad egy órája, így van idejük megbeszélni a következő lépéseket. Barbi nemrég hallott egy új programcsomagról ami szerinte remekül illene a feladathoz. Elek szeretné meg befejezni a választott issue-jához kapcsolódó rész átnézését. Így a csomag kipróbálását Barbi vállalja. A maradék időben a főbb megvalósítandó funkciókról esik szó.
Mindketten hazaindulnak, de Barbi a TIK-ben felejtette a táskáját ezért vissza kell mennie érte. A villamos lerobban félúton. Szóval ez nem az ő napja. Másnap eszébe jut a Kalkulus 2 ZH így egész héten arra készül. Elekkel péntek délután fut össze aki kíváncsian kérdi milyen az új programcsomag.
Barbinak nem érti mire gondol, volt valami a Rendszerfejlesztés 2 projektmunkával kapcsolatban, de kisebb gondja is nagyobb annál, hogy most ezzel foglalkozzon. Sajnos a határidő ettől nem változik, így mindketten egész hétvégén az új csomag megismerésével foglalkoznak, amit végül sikerül működésre bírni. Hétfő hajnalban már egyikőjük se mer módosítani a kódon, nem értik miért működik, ezért félnek hogy elromlik.
A fenti vitás helyzet és a határidőhöz közeli kapkodás részben elkerülhető lett volna a folyamatok megfelelő naplózása segítségével. A megbeszélések után célszerű memo-kat írni, melyből kiderül milyen döntésekben állapodtak meg. Az új feladatokat issue-k formájában szokták rögzíteni. A korábbi feladatokhoz kapcsolódó információkat az issue-k alá megjegyzésben írják, hogy minden egy helyen legyen. A határidőket és az egyes feladatok haladását, felelősét frissíteni kell az issue-k alatt. Ezzel nem csak azt érjük el, hogy mindenki számára egyértelmű lesz a saját felelőssége, hanem hogy ezeket az információkat bármikor a többiek zavarása nélkül is elérheti.
A (nagy) bináris fájlok tárolása nagyon lelassítja a Git működését. Ezért nem szoktunk ilyeneket feltölteni. Minden bináris fájlnak számít amit nem tudsz elolvasni, ha egyszerű Notpad-el megnyitod. Általában semmilyen generált fájlt sem töltünk fel, hiszen ezek előállíthatóak a forráskódból.
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 hallgató a **Fejlesztési folyamatok dokumentálása** részfeladatra összesen 5 pontot szerezhet. A félév során a következő fejlesztési elemek dokumentált használatát pontozzuk.
| részfeladat | maximális pontszám | kinek? |
|-------------|--------------------:|--------|
| issuek karbantartása | 1 | mindenki |
| heti megbeszélés memo ([példa]( http://gitlab-okt.sed.hu/root/Sample/wikis/sample-memo)) | 2 | felelősök |
| aktív részvétel heti megbeszélésen | 2 | nem felelősök |
| összegző dokumentum egységesítése | 2 | felelősök |
| összegző dokumentum kapcsolódó részeinek kitöltése | 2 | nem felelősök |
*Mindenki szerezhet 1 pontot + ((felelős szerezhet 2 + 2 pontot) __vagy__ (nem felelős szerezhet 2 + 2 pontoz)) = 5 pont mindenkinek.*
Az agilis módszertanokhoz hasonlóan kövessük nyomon a feladatok végrehajtását. Mindenkinek legyenek saját issuejai (válalt feladatok és részfeladatai). Ezek állapotát a hallgatói GitLab szerveren a saját gyakorlathoz tartozó issue board-on kell frissíteni folyamatosan a félév során.
A projekt lezárásaként egy összegző dokumentumot kell készíteni. Az összegzést a GitLab projekthez tartozó Wiki-ben kell elhelyezni és [MarkDown](https://docs.gitlab.com/ee/user/markdown.html) formátumban kell elkészülnie. Az oldalnak tartalmaznia kell kulcsfontosságú információkat.
A következőknek mindenképpen szerepelnie kell a dokumentumban:
- Felhasznált témák és technológiák bemutatása
- Leadandók eredményei linkjei
- Leadandókról született dokumentációk linkjei
- Összefoglalás és konklúzió
A dokumentumnak bizonyítania kell, hogy a hallgató elsajátította a módszereket és technológiákat, ami egy projekt karbantartásához kell.
Ahhoz, hogy ezt bizonyítsa átfogóan de lényegre törően kell bemutatni az alkalmazott technikákat a beadandó projekten. Ehhez hozzá tartozik a probléma lépésről lépésre történő megoldásának leírása az alkalmazott eszközök és azoknak használatával kibővítve.
Egy [korábbi példa](http://gitlab-okt.sed.hu/root/Sample/blob/master/README.md) amiből ki lehet indulni.
| részfeladat | maximális pontszám | kinek? | |
|---|---|---|---|
| kapcsolódó komponensek megismerése | 3 | mindenki | |
| Kapcsolódó issue-k összegyűjtése és munka összehangolása | kapcsolódó issue-k megjelölése | 2 | mindenki |
| felelős választása és megjelölése | 1 | mindenki | |
| egységesség segítése | 2 | felelősök | |
| egységesség alkalmazása | 2 | nem felelősök | |
| Forráskód verziókövetése | Git és GitLab használat | 2 | mindenki |
| git flow követése | 2 | mindenki | |
| Fejlesztési folyamatok dokumentálása | issuek karbantartása | 1 | mindenki |
| heti megbeszélés memo (példa) | 2 | felelősök | |
| aktív részvétel heti megbeszélésen | 2 | nem felelősök | |
| összegző dokumentum egységesítése | 2 | felelősök | |
| összegző dokumentum kapcsolódó részeinek kitöltése | 2 | nem felelősök | |
Az alábbi ábra informálisan mutatja a minőség főbb aspektusait. Az említett "működik", azaz funkcionálisan helyes, csak az első elem a listában.
Az alábbi feladatok közül a hallgató a projekt jellegét figyelembe véve és a gyakorlatvezető jóváhagyásával választ egy vagy több alfeladatot.
A kiválasztott alfeladatot jelezni kell a Coospace-en. A választás csak akkor számít elfogadottnak, ha azt a gyakorlatvezető megerősíti. A gyakorlatvezető jóváhagyása nélküli feladat végrehajtását és eredményét nem fogadjuk el.
A minőségbiztosítás témakörét két részre fogjuk bontani a gyakorlat során.
A tesztelés egy rendszer vagy program kontrollált körülmények melletti futtatása, és az eredmények kiértékelése. A hagyományos megközelítés szerint a tesztelés célja az, hogy a fejlesztés során létrejövő hibákat minél korábban felfedezze, és ezzel csökkentse azok kijavításának költségeit.
A gyakorlat során bevezetést adunk a tesztelés világába, melyet háromféle teszteléssel mutatunk be. A hallgatók, akik ennél mélyebben szeretnének elmerül a tesztelés világában javasoljuk a Szoftvertesztelés Alapjai tárgy felvételét és az ISTQB vizsga anyagok áttekintését.
A fejlesztés közben sokszor próbálgatjuk (pl. debug-golás során) a funkciót amit fejlesztünk. Példakódot írunk, `main` metódusokat hozzunk létre, hogy közvetlenül hívhassuk a fejlesztés alatt lévő részeket. Ezek a lépések fontosak, de nem számítanak tesztelésnek. A tesztelés szinte minden fajtájára elmondhatóak a következő irányelvek.
+ A tesztek futtatása megismételhető és konzisztens eredményt ad, amennyiben nem történt módosítás a kódbázisban.
+ A teszt pontosan leírja hogy milyen lépéseket kell végrehajtani az eredmény (elbukott vagy átment) érdekében.
+ A tesztek összekapcsolhatóak a rendszer valamely követelményeivel (nem feltétlenül funkcionális).
A kipróbálásokat nem fogadjuk el tesztként a gyakorlat során.
A próbálgatások hasznos alapot jelentenek a tesztek megírása során. A megvalósítás alatt lévő metódust meghívó példa main helyett (vagy alapján) készítsünk egy új egység vagy integrációs tesztet megvalósító metódust. A kipróbálások során követett felhasználási lépések alapján új végfelhasználói teszteset forgatókönyv készíthető.
A unit tesztek célja, hogy a rendszer legkisebb építőelemeit (melyek általában a metódusok) helyes működését igazolja megismételhető módon. Az egységteszteket mindig a fejlesztők írják, hiszen ők rendelkeznek megfelelő ismeretekkel a forráskódról ehhez.
Megfelelően megírt tesztekkel tudjuk igazolni, hogy tesztelt részek az elvárásoknak megfelelően működnek. Ha minden teszt csak egy adott metódus egy adott (fajta) bemenetre teszteli akkor az a hiba keresést és javítást is gyorsítja. Hiszen a hibás metódus az amelyiknek a tesztje elbukott és a tesztelt bemenet egyben példa adatokkal is szolgál.
Az egységteszteknek egymástól és külvilágtól is függetlennek kell lennie. Ez azt jelenti, hogy bármikor újrafuttatva konzisztens eredményt kell kapjunk. Tehát ha módosítás után valamelyik egységteszt elbukik, akkor a módosítás során hibát okoztunk a rendszerben.
A unittest-ek számtalan példát tartalmaznak a metódusok használatára. Ezekből nem csak a helyes paraméterezést tanulhatjuk meg, de képet kaphatunk az eredeti fejlesztő szándékáról is, hiszen a tesztek egyértelműen jelzik, hogy mi volt az elvárt viselkedés.
A unittest-ek megvalósítása forráskódban történik, általában valamilyen keretrendszer segítségével. A gyakorlat során a JUnit rendszert fogjuk használni. Az egységteszteket ugyanabban a verziókövető rendszerben szokták nyilván tartani, mint a kódbázis többi részét.
A korábban már elkezdett projektet szinte minden esetben már tartalmazni fog valamilyen egységtesztelési keretrendszert, ezért nem szükséges azt nekünk hozzá adni. Vagyis azt a verziót használjuk amelyet a projekt is előír. Jelenleg ez a definíció a CodeMetropolis esetében a [Maven leírófájlokban](https://github.com/codemetropolis/CodeMetropolis/blob/d5e8c804ad89df4dee2c61e70af0d140fd848d3a/sources/pom.xml#L41) található.
Az egységteszt keretrendszereket több más, automatizált tesztkészlet megvalósítására is használják a gyakorlatban. Ezeket nem tekintjük egységteszteknek, mivel nem tartják az egységtesztek irányelveit.
+ Ne teszteljünk triviális kódot, például egysoros ```getter``` és ```setter```.
+ A konstruktor szakszerű tesztelése általában technikai akadályokba ütközik.
A **Unittest-ek** részre a hallgató 3 pontot szerezhet. Feladat a projekthez unittest-ek implementálása és futtatása. A feladat során a unittest-ek forráskódját (`*.java` fájlok) a hallgatói GitLab szerveren kell elhelyezni. A tesztelésre kiválasztott metódusok során vegyük figyelembe a következőket.
- A saját változtatás megvalósításának tesztelése kötelező, 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).
??? example "De hát külön-külön jól működött!"
Az integrációs tesztek célja, hogy megismételhető módon igazolják, hogy a rendszer komponensei (metódusok, osztályok, csomagok, programok, ...) megfelelőképpen működnek együtt.
Tegyük fel, hogy a Placing és a Rendering CodeMetropolis program is koordináta és méret alapján helyezi el az épületeket. Pró Bea a Rendering-en dolgozik és az (x,y,z) koordináták alapján meghatározza az épület bal, alsó, első pontját. Ez egy szakmailag megalapozott döntés volt, hiszen így számtalan koordinátageometriai művelet egyszerűsödik a blokkok elhelyezése során. Teszt Elek issue-ja a Placing eszközhöz kapcsolódik. Az (x,y,z) koordináta nála az épület alapjának közepét jelenti. Ezzel sokkal egyszerűbben tudta középreigazítani az egymásra kerülő szinteket.
Mindketten megfelelő mennyiségű és minőségű egységteszteket készítettek, melyek sikeresen le is futottak. A két módosítás egyesítése után a generált városban mégis egymásba csúsztak az épületek. Az integrációs tesztek ilyen problémák kiszűrésére képesek.
A gyakorlaton az integrációs teszteket az egységtesztekkel megegyező keretrendszerrel valósítjuk meg. Ez egy elfogadott szakmai gyakorlat, azonban léteznek más módszerek is.
Az **integrációs tesztek** részfeladatra a hallgató 3 pontot szerezhet. Feladat a projekthez integrációs tesztek implementálása és futtatása. A feladat során az integrációs tesztek forráskódját (`*.java` fájlok) a hallgatói GitLab szerveren kell elhelyezni. A tesztelésre kiválasztott komponensek során vegyük figyelembe a következőket.
- A saját változtatás megvalósításának tesztelése kötelező, vagyis azokat a metódusokat amiket mi írtunk, vagy módosítottunk teszteljük le hogy továbbra is képes megfelelően együtt működni a közvetlen környezetével (osztály, csomag).
- 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).
- Végül teszteljük le, hogy az egyes programok továbbra is képesek az elvárt módon együttműködni.
A végfelhasználói tesztek feladata a teljes folyamat vagy funkcionalitás helyességének igazolása a felhasználó szemszögéből.
A felhasználó szemszöge alatt azt értjük, hogy a tesztelést végzőnek nincsen információja a rendszer belső működéséről. Ezt a fajta megkülönböztetést fekete- és fehér-doboz tesztelésnek hívjuk. Az egység tesztek tipikusan fehér-doboz tesztek, hiszen a fejlesztő tudja, hogy hogyan működik az adott metódus és ez alapján konstruálja meg a szükséges teszteseteket.
A végfelhasználói tesztek fekete-doboz tesztek, mivel a felhasználó nem ismeri és nem is fér hozzá a program belső logikájához. Az információ elsődleges forrása számára nem a belső működés, hanem a dokumentáció.
A CodeMetropolis Rendering programja az IXML fájlban megadott épületeket Minecraft világbeli blokkokká konvertálja. A folyamat általában percekig is eltart, a vizualizált program méretétől függően akár órákat is igénybe vehet. A CodeMetropolis egyik korábbi verziójában nem volt visszajelzés a folyamat közben. A tesztelés során a végfelhasználói teszt mutatott rá erre a hiányosságra.
A javítás első lépésben egy folyamatos jelzést jelentett, hogy a konverzió folyamatban van. További végfelhasználói tesztek jelezték, hogy a hosszú konverziók során a felhasználónak nincs tudomása róla hogy meddig tart a folyamat. Ez nagyban csökkentette a CodeMetropolis használhatóságát.
Ezt követte a funkció jelenlegi állapota, mely elfogadható pontossággal becsüli meg e fázis hosszát.
A végfelhasználói tesztet nem feltétlenül szükséges hogy szoftverfejlesztésben jártas szakember végezze, bár a közös előismeret segítheti a kommunikációt a fejlesztő csapattal. Ezeket a teszteket többször manuálisan végzik el, azonban előfordulhat hogy a kézi végrehajtást rögzítik és később ezzel szimulálják a valódi felhasználó cselekedeteit.
Bár a gyakorlaton ezzel a témával csak említés szintjén foglalkozunk, az érdeklődő hallgató további részleteket olvashat erről a [Selenium](https://www.selenium.dev/) és ehhez hasonló eszközök kapcsán.
Az tesztelésre kiválasztott issue-t jelezni kell a Coospace-n. A leadott anyagot csak akkor fogadjuk el, ha a gyakorlatvezető jóváhagyta a választást.
Igen. A tesztelésre kiválasztott issue-nak nem szükséges készen lennie. A tesztek hamarabb is elkészülhetnek mint a funkció vagy a követelmény maga. Ez az elv nagyon hasonló a [Tesztvezérelt fejlesztés](https://hu.wikipedia.org/wiki/Tesztvez%C3%A9relt_fejleszt%C3%A9s) alapjaihoz.
Természetesen ilyen esetben a tesztek el fognak bukni mindaddig amíg a követelmények nem készültek el. Ez **nem** azt jelenti, hogy a tesztet nem kell szakmailag megalapozott módon elkészíteni. Ha bizonytalan vagy minnél előbb fordulj a gyakorlatvezetődhöz.
A hallgatók a **Végfelhasználói tesztek** részre összesen 3 pontot kaphat. A hallgató feladata tetszőleges CodeMetropolis program végfelhasználói tesztjeinek elkészítése. A tesztelés során koncentráljunk egy tetszőleges issue-ban megadott követelményekre. A végfelhasználói teszteket a hallgatói GitLab issue-k formájában kell megadni, felhasználva a [sablont](https://okt.sed.hu/rf2/gyakorlat/projekt/test_sample). A tesztelésre kiválasztott issue-t minden esetben hivatkozni kell. A gyakorlat során (az egyszerűség kedvéért és a hallgatói feladatok mérséklése érdekében) csak kézzel végrehajtott végfelhasználó teszteseteket fogadunk el. A feladatban igazolni kell a tesztek végrehajtását (pl. képernyőképekkel).
A szoftverelemzés célja a szoftverrendszer objektív megismerése. Az elemzés általában tudományos módszereket használ és méréseken alapszik. A megismételhető és lehetőleg személyfüggetlen mérés alapján következtetéseket vonhatunk le a rendszerről és a hozzá kapcsolódó folyamatokról.
Képzeld el, hogy vezető fejlesztőként meg kell becsülnöd, hogy mennyi fejlesztő tud majd elvégezni egy új projektet határidőre. Első ötleted, hogy korábbi hasonló projektek erőforrása alapján adsz becslést. A korábbi projektek fejlesztéséhez szükséges fejlesztők száma és futamideje mind a folyamatokat jellemző mérés.
Bármelyik projekt megfelel a becslés alapjaként? Nyilván nem, csak a hasonlóak. Egy program hasonló, ha ugyanazokat a technológiákat használja? Hasonló ha ugyan annyi kódsort tartalmaz? Ezek mind a terméket jellemző metri
Tegyük fel hogy 5 fejlesztőre lesz szükség a becslés szerint. Mindegy hogy milyen a junior és a senior fejlesztők aránya? Minden senior fejlesztő ugyanakkora sebessége dolgozik? Minden junior fejlesztő ugyanolyan minőségű terméket állít elő? Ezek a tulajdonságok mind a fejlesztési folyamat szereplőit jellemzik és mérések segítségével határozhatóak meg.
A becslés folyamata tulajdonképpen egy elemzés ami tudományosan megalapozott módszerek alapján von le következtetést (mennyi fejlesztőre van szükség) a korábbi mérésekből (hasonló projektek erőforrásigénye).
A kódelemzés során a forráskódból gyűjtünk információt a rendszerről. Statikus elemzés során nem futtatjuk a kódot, míg dinamikus esetben (akár több) futás során gyűjtött adatokat használunk fel. 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. A minőség bármelyik korábban bemutatott aspektusát vizsgálhatjuk ezzel a módszerrel.
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. Ha bizonytalan vagy kérj tanácsot a gyakorlatvezetőtől! A nem megfelelő eszközökkel készült méréseket és az azok alapján levont hibás következtetések nem fogadjuk el.
A gyakorlaton időhiány miatt a dinamikus elemzést csak említés szintjén vesszük, ezért nem javasolt. De a hallgató saját felelősségére használhatja ezt a mérési módszert is.
Képzeljük el a következő hipotetikus esetet. **Jelenség:** A CodeMetropolis komplexitása (pl. az osztályok teljes McCabe komplexitása) több mint 30%-al nőtt az elmúlt fél év során. A többi statikus forráskód metrika nem változott jelentősen. Vagyis a kódbázis mérete is megközelítőleg azonos maradt. Ezek azok az adatok melyet statikus módszerek segítségével le tudunk mérni.
**Elemzés:** Az elemzés során elsősorban az okokat és a lehetséges következményeket keressük. Az adatokban látszik, hogy a legnagyobb komplexitás változás a Mapping és a Rendering eszközben figyelhető meg. A többi részek nagyságrendekkel kisebb mértékben változtak. A kapcsolódó események és a verziókövető rendszer adatai alapján megállapíthattuk, hogy az egyik legfontosabb függőség a Minecraft játék egyik nagyobb verziója ennek az időszaknak az elején jelent meg. A többi függőségben nem történt változás és új felhasználói követelményekről sem érkezett hír a rendszer issue-kezelő felületén.
**Okok:** A további vizsgálatok alapján feltételezzük, hogy mivel a kérdéses verzió számtalan új blokkot vezetett be, ezért a lelkes hallgatókból álló fejlesztőcsapat elkezdte ezek kihasználását új épület stílusok és változatok bevezetésével. A megvalósított issue-k is ezt támasztják alá.
**Következmények:** A komplexitás növekedése miatt a jövőben nehezebb lesz megérteni és a sok egyedi logika miatt módosítani a kapcsolódó Rendering és Mapping eszközök részeit. Vagyis az ezekhez kapcsolódó issue-k megoldása több erőforrást igényel.
Amennyiben a hallgató nem időben vagy nem egyértelműen (pl. GitLab link) jelzi az issue-hoz tartozó branch-et úgy a mérésekről saját maga kell hogy gondoskodjon.
A hallgató a **Minőségreport kódelemzés alapján** részfeladatra 4 pontot kaphat. A hallgató feladata, hogy méréseket végezzen a fejlesztés során. Ehhez a hallgatói GitLab projektek esetében automatikus folyamatok kerülnek beállításra a választott issue-ban jelzett branch-ekre.
A mérések alapján, a hallgató fejlesztések végén a projektről minőségriport készít a projekt állapotai alapján. A riportot a hallgatói GitLab projekt Wiki rendszerébe kell feltölteni.
Az elemzésben a következő szempontokat vegyük figyelembe és kérdésekre keressük a választ.
+ Milyen volt 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?
+ Hogyan változott a minőség a fejlesztés során? Milyen viszony alakult ki a kezdeti és a végső állapot között?
+ Milyen furcsa vagy meglepő jelenségeket tudunk megfigyelni a megvalósítás (forráskód) metrikákból levonható és konkrét példákkal alátámasztott jellegzetességeiből?
+ 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
+ Milyen szabálysértéseket találhatóak a forráskódban? Mi lehet ezek keletkezésének létezésének okai a verziókövető rendszer alapján?
+ Mely szabálysértések jeleznek valódi hibát? Miért?
+ Melyek leggyakoribb és legritkább jelzések?
+ Hogyan változtak a szabálysértések száma vagy aránya a fejlesztés során?
A tesztelést mint minden szoftverfejlesztéshez kapcsolódó tevékenységet lehet jól és rosszul végezni. A nem megfelelő minőségű tesztelés ritkán éri el a célját (a követelmények ellenőrzése), azonban legalább annyi erőforrást emészt fel mint szakmailag megalapozott változata. A tesztlefedettség viszgálata egy lehetséges módszer a tesztelés minőségének ellenőrzésére.
Nem. A lefedettséget általában a teszt csomag méretének és teljességének vizsgálatára szokták használni. Számos kutatás számára szolgál alapvető adatként egyéb minőségbeli jellemzők becslése során.
A lefedettség kifejezi, hogy az egyes tesztek végrehajtása (automatizált esetben futtatása) során mely kódrészletek kerültek futtatásra. Ezek számából meghatározható, hogy a tesztek mekkora mértékben érintették a forráskódot, vagyis hogy mekkora és melyek azok a részek, amelyek biztosan nem kerültek tesztelésre.
A lefedettség mérésének kulcsa, hogy valamilyen módszerrel feljegyezzük, hogy mely kódrészletek hajtódtak végre. Az ilyen naplózás aktiválása után a teszteket egyszerűen végrehajtjuk vagy automatizált esetben futtatjuk.
A példa kedvéért tegyük fel, hogy a CodeMetropolis Converter eszköz parancssori felületének megalkotás egy funkció csoport keretében történt (viszonylag egyidőben). A fejlesztő automatizált tesztek segítségével szeretne meggyőződni a funkcionális követelmények teljesítéséről. A tesztelés során csak két tesztesetet fogalmaz és valósít meg. Egyet-egyet `-t` (`type`) argumentum két értékére: `sourcemeter` és `sonarqube`. Hiszen fontos hogy a konvertálás jelenleg csak ezt a két formátumból lehetséges, így ezek tesztelése fontos.
A gondolatmente bár helyes, de hiányos. A lefedettségmérés egyértelműen kimutatja, hogy bár vannak olyan kódrészletek amelyeket érintenek a tesztek és a többi argumentumhoz kapcsolódnak, de ezek csak az alapértelmezett értékek kezelésével foglalkoznak. Vagyis a parancssori argumentumokat tesztelő csomag túl kicsi és nem teljes.
A lefedettség elemzése egy másik hiányosságra is rámutat ebben az esetben. A tesztelt `-t` argumentum kezelése során a hibás értékeket ellenőrző és jelző kódrészletek nem kerültek futtatásra. Vagyis ezen tesztek alapján nem tudunk meggyőződni ezek helyes működéséről.
Java nyelven írt projektek esetén javasoljuk az Eclipse fejlesztőkörnyezetbe alapértelmezett módon integrált [EclEmma](https://www.eclemma.org/) eszköz használatát.
A hallgató saját felelősségére és a gyakorlatvezető jóváhagyásával használhat más lefedettségmérő eszközt. Ha bizonytalan vagy kérd ki a gyakorlatvezető tanácsát! Nem megfelelően használt eszközökkel végzet mérést és ennek elemzését nem fogadjuk el.
Ahogy a fenti példából is látszik a nyers lefedettségi adatok közlése nem segíti a projekt fejlesztését. A lefedettség mérése a vizsgálat során csak az első lépés, melyet a többi minőség-ellenőrzéshez hasonlóan elemzési fázis követ. Ebben a fázisban a mért adatok okait (magyarázatát) és következményeit kutatjuk.
Az indoklás és magyarázat nélküli lefedettségi adatokat nem fogadjuk el. A legtöbb lefedettségmérő eszköz képes emberek számára könnyen olvasható riportot generálni. Ezek azonban csak a nyers adatokat tartalmazzák, vagyis nincs bennük a lehetséges okok és következmények vizsgálata. Ezek célja hogy felgyorsítsák a méréssel szerzett adatok bemutatását és az elemzés előkészítését. A generált riportokat felhasználhatjuk, mint első verzió a végleges jelentés elkészítése során.
A **Tesztlefedettség vizsgálata** alfeladatra a hallgató 4 pontot kaphat. Feladat a kiválasztott issue-ban leírt követelményekhez kapcsolódó módosításokhoz kapcsolódó tesztek lefedettségének mérése és a kapott adatok elemzése. A lefedettségi vizsgálatot a hallgatói GitLab szerver Wiki rendszerébe kell feltölteni.
A leadott anyagnak magyaráznia kell a tesztelés és a hozzá kapcsolódó mérés során kapott értékeket. 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
- a vizsgált teszt csomag bemutatása
- 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
- könnyen és nehezebben tesztelhető funkciók és változtatások
| részfeladat | maximális pontszám | |
|---|---|---|
| Tesztelés | Unittesztek | 8 |
| Integrációs tesztek | 8 | |
| Végfelhasználói tesztek | 8 | |
| Szoftverelemzés | Minőségriport kódelemzés alapján | 9 |
| Tesztlefedettség vizsgálata | 9 | |
Projekt megnevezése: (ide annak a konkrét projektnek a neve kerül, amin a csapat dolgozik)
| Hallgató neve | pl..: Kovács János |
| Hallgató neptun kódja | pl..: AAAAA |
| Hallgató szerepköre (ha van) | pl. build master |
| Gyakorlatvezető neve | pl..: Tóth László |
| Gyakorlat kódja | pl.: IB302G-11 |
| Jelentési időszak (-tól) | pl..: 2021.10.04 |
| Jelentési időszak (-ig) | pl.: 2021.10.10 |
| Feladat megnevezése | pl: build környezet testreszabása. |
| Mérföldkő | pl.: M1 |
| Határidő | pl.: 2021.12.22 |
| Státusz (nincs elkezdve, folyamatban, kész ) | pl.: folyamatban |
A munkanaplót az érintett időszak végén kell kitölteni és a következő gyakorlatot megelőző nap 24.00 - ig kell feltölteni a projekt Wiki oldalán belül a Hallgató munkanaplók page hallgatóhoz tartozó oldalra.
- Elindítom a Minecraftot
- Megnézem az első épületet
- stb...
Elégtelen minősítést kap az a hallgató, aki nem éri el bármelyik feladatból vagy részfeladatból a minimum pontszámokat (lásd lent), egyébként az érdemjegy az alábbiak szerint kerül megállapításra.
| min. | max. | érdemjegy |
|---|---|---|
| 90 | 100 | jeles |
| 75 | 89 | jó |
| 50 | 74 | közepes |
| 40 | 49 | elégséges |
| 0 | 39 | elégtelen |
A gyakorlaton összesen 167 pont szerezhető (bizonyos részek választhatóak). Az egyes feladatok közötti pontok eloszlását az alábbi diagram mutatja.
A további tudás és szakmai tapasztalatok megszerzése mellett, vegyük figyelembe, hogy a kötelező feladatok (zh és projektmunka) **hibátlan teljesítésével** csak jó minősítés szerezhető. A jeles érdemjegyhez további feladatok elvégzése szükséges.
Az egyes részekből elérhető minimális, kötelező és maximális pontszámokat az alábbi táblázatban soroltuk fel. Pluszpontokat a gyakorlatvezetők adják kiemelkedő teljesítményért.
| Feladat | Részfeladat | Pontszám | ||
|---|---|---|---|---|
| Min. | Kötelező | Max. | ||
| Zárthelyi dolgozat | 0 pont | 18 pont | 30 pont | |
| Projektmunka | Megvalósítás | 0 pont | 9 pont | 17 pont |
| Minőségbiztosítás | 0 pont | 9 pont | 17 pont | |
| Projekt menedzsment | 0 pont | 9 pont | 17 pont | |
| Pluszpont | 0 pont | nincs | 6 pont | |
| Mentorálás | Segédanyag összegyűjtése | 0 pont | nincs | 16 pont |
| Segítségnyújtás | -8 pont | nincs | 16 pont | |
| Pluszpont | 0 pont | nincs | 8 pont | |
| Kutatás | Kutatási terv | 0 pont | nincs | 32 pont |
| Pluszpont | 0 pont | nincs | 8 pont | |
A gyakorlaton egy zárthelyi dolgozatot kell megírni.
Aki nem éri el a minimális pontot, javító zh-t írhat az egész féléves anyagból. Azonban ekkor csak a kötelező pontszám érhető el.
A zh a saját gyakorlat időpontjában, a gyakorlaton előre kihirdetett időpontban lesz.
A javító zh időpontja a szorgalmi időszak utolsó hete.
Minden egyéb esetben a hatályos TVSZ-ben leírtak érvényesek.
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. Hogyan?
Mivel a projektmunka folyamatos 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 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. Betegség miatt előfordulhat, hogy hallgatók csúsznak a projektmunkával. A váratlan körülmény csak a körülmény idejében elvégzendő feladatnak a határidejét tudja befolyásolni és az elvégzendő munka mennyiségét illetve a további részek határidejét sem befolyásolja.
Minimális követelmény nincs, de ha a hallgató elhanyagolja a feladatot pontlevonást kap (legrosszabb esetben -8 pontot).
A kutatási munkát a hallgatók végezhetik szabadon választott csapatban, de az értékelés ekkor is egyénileg történik. Minden csapattag azonos pontot kap a minimum és a maximum között. A csapat szervezése és a részfeladatok felosztása a hallgatók feladata. A gyakorlat folyamatait a Gantt diagramra épülő esemény-lánc diagramok segítségével mutatjuk be. Ezek az ábrák az egyes feladatok időtartamát és időbeli elhelyezkedését is ábrázolják. Az diagramokon különböző nyilak jelölik az egyes (esetleg) bekövetkező eseményeket, melyek két félék lehetnek: rizikó (negatív) és lehetőség (pozitív). A diagramok értelmezésében az alábbi jelmagyarázat is segíthet.
A gyakorlat folyamata a következő részekből áll.
A tananyagot példákon keresztül fogjuk bemutatni, ami általában az óra első felében történik. Ezt követően a példák alapján mindenki bizonyos feladatokat fog végrehajtani az általa választott projektmunkával kapcsolatban. Az alábbi ábra az egyes anyagrészek időbeosztását mutatja heti lebontásban.
Az első két órán a gyakorlat folyamatainak ismertetésére kerül sor, ezen leírás alapján. A hallgató a megszerzett ismeretekről zárthelyi dolgozat során ad számot.
A hallgatók projektmunka készítése során mélyítik el a példákon keresztül megszerzett szaktudást. A projektmunka készítése részben az órán és részben azon kívül történik.
A hallgató feladatai közé tartozik, hogy a gyakorlatvezető szakmai tanácsait figyelembe véve beossza az órán kívüli idejét.
A fenti ábra a projektmunka időbeosztását mutatja be heti bontásban. Természetesen a hallgató hamarabb is megkezdheti az egyes részek kidolgozását, mint a fenti ajánlás.
A határidők betartása továbbra is a hallgató felelőssége.
Az ábrán jelöltük az egyes feladatokat befolyásoló rizikó tényezőket (lefelé mutató nyilak) és a rájuk adható, ill. hatásaikat csökkentő lehetőségeket (felfelé mutató nyilak). Ezek elkerülését és kezelését a gyakorlatvezetők a hallgatókkal együtt végzik. Vegyük észre, hogy az egyes feladatok elhanyagolása esetén nincs lehetőség a probléma orvoslására.
Az egyes lehetőségek felhasználása csakis a gyakorlatvezetővel történő egyeztetés után lehetséges. Pl.: más issue választását a gyakorlatvezetőnek jóvá kell hagynia.
A mélyebb ismeretek megszerzését és a korábbi hallgatók körében meglévő tudás terjedését mentorálás segítségével támogatjuk. A mentorálás történhet az órai feladatok megoldása során is, de általában tanórán kívüli tevékenység.
A mentor feladata, hogy segítse a hallgatótársait az általa korábban, vagy a félév során megismert témában. A segítség személyes vagy online megbeszélések során ill. segédanyagok publikálásán keresztül valósul meg.
Egy mentori témát összesen két hallgató választhat. A kiválasztott témában a teljesítéssel kapcsolatos felelősségük egyetemleges, de a teljesítéssel kapcsolatos feladatokat megoszthatják.
Az alábbi diagram a mentorálás javasolt heti időbeosztását mutatja.
A mentornak nem feladat a hallgatók helyett elvégezni a feladatokat. A segítségnyújtás során koncentráljunk arra, hogy a hallgató társ saját maga oldja meg a feladatot. Gondoljunk arra, hogy a munkahelyén se fogja senki megoldani helyette a problémákat.
A kutatási munka célja hogy tudományos módszerekkel és bizonyítékokkal új módszereket hozzunk létre, vagy korábbi technológiákat használjunk fel ill. értékeljünk ki eddig ismeretlen módon vagy környezetben.
A hallgatók saját belátásuk szerint csapatban is megvalósíthatják a kutatási feladatot. Ez a csapatbeosztás nem vonatkozik a többi feladatra.
A csapattagok munkájának értékelése továbbra is egyénileg történik. A kutatómunkára szerzett pontot nem osztjuk szét, minden megfelelően aktív csapattag azonos pontszámot kap. Csapaton belüli problémákat azonnal jelezni kell.
A hallgatók feladata, hogy a gyakorlaton elvégzett munkák adatait felhasználva eddig ismeretlen jelenségeket vagy kapcsolatokat tárjanak fel a kurzussal kapcsolatban. A feladat során nem várjuk el hogy teljesen kidolgozott tudományos publikációt készítsenek, azonban létre kell hozni egy tervezetet, mely alapján további erőforrásokat (pl. időt) felhasználva a kutatása elvégezhető.
Javasoljuk, hogy a hallgatók a kutatás során készítsenek több prototípus jellegű támogató programot (szkriptet). Ezek segítik a módszer egyértelmű bemutatását és az lépések automatizálását.
A kutatás céljának javasoljuk, hogy kisebb könnyen mérhető és ellenőrizhető hipotézist válasszatok. A legtöbb világraszóló tudományos eredmény rengetek apró lépés során jött létre.
A projekthez tartozó forráskód (általában *.java fájlok) és hozzá kapcsolódó erőforrásokat a hallgatók GitLab szerverére kell feltölteni, folyamatosan a félév során.
A feladatokhoz tartozó szöveges dokumentumokat MarkDown formátumba várjuk szintén a hallgatók GitLab szerverén. Ez a formátum lehetővé teszi a verziókövetést.
A projekt nyomonkövetését és a munka dokumentálását a hallgatók GitLab szerverén kell vezetni a megadott eszközökkel: issue-k, mérföldkövek, wiki oldalak, stb.
Kivetítendő fóliák készítése nem kötelező, de az elkészült munkát ettől függetlenül be kell mutatni. A prezentációt PDF forámtumba kérjük beadni, ezzel biztosítva, hogy mindenhol ugyan úgy jelenik meg. Ez elkészíthető LaTeX-ben, Microsoft PowerPoint-tal, vagy bármilyen egyéb programmal, mely képes PDF formátumba menteni a prezentációt.
Követelmények
A gyakorlaton a részvétel kötelező. A jelenlétet a Concierge rendszerben kell minden órán bejegyezni. Két igazolatlan hiányzást fogadunk el. Az elmaradás pótlása igazolt és igazolatlan esetben is a hallgató felelőssége. Minden egyéb esetben a hatályos TVSZ-ben leírtak érvényesek.
A gyakorlattal kapcsolatos kommunikáció történhet a következőképpen.
- Személyesen az órán
- CooSpace névtérben
- hallgatói GitLab szerveren
- CooSpace üzenetben
- E-mail-ben
A gyakorlattal kapcsolatos kommunikáció során csak az egyetemi (stud-os) email címről érkező leveleket fogadjuk el. A levél tárgya -- ha egyébként a leadandónál más nincs megszabva -- [RF2] prefixszel kezdődjön, például: [RF2] segítség a projektmunkával kapcsolatban.# Féléves menetrend
Az alábbi naptár mutatja a fontosabb eseményeket, a pontos időbeosztásról a gyakorlatvezetők adnak tájékoztatást.
A gyakorlaton kívüli események csak tájékoztató jelleggel kerültek feltüntetésre, hivatalos információ a TO-naptárban található.
Az alábbi linkek segítségével fel lehet iratkozni ezekre a naptárakra.
Ütemezés
ZH
Projektmunka
Mentorálás
Kutatás
Ez a dokumentum a jelenleg a Szegedi Tudományegyetemen bevezetett távoktatással kapcsolatos változásokat írja le kizárólag a Rendszerfejlesztés II. gyakorlat kurzusra vonatkozóan. Minden korábban kiadott tájékoztatás és követelmény leírás érvényben marad, kivéve ha ezeket az alábbiak módosítják vagy felülbírálják. Kérdéses esetben a gyakorlatvezetőhöz kell fordulni.
A gyakorlatot távoktatás keretében fogjuk megtartani.
A tananyagot ezen a honlapon tesszük közzé. Ettől való eltérés esetén az elérhetőség a Coospace-re kerül majd fel.
A gyakorlati példák elvégzéséhez szükséges környezet kialakítását a hallgatók a saját gépükön végzik a gyakorlatvezető által biztosított leírások és instrukciók alapján.
A tananyag elsajátítását a hallgatók továbbra is önnálóan végzik, melyhez koznultációs órák keretében segítséget kapnak az adott gyakorlat idejében a kurzus Discord szerverén a megfelelő hang-szobában.
Az elsődleges kommunikációs csatorna a diákok és gyakorlat vezetők között a közös gyakorlati Coospace fórum és hirdető tábla.
A gyakorlat során a zárthelyi dolgozat elektronikus formában kerül megírásra a Coospace-n keresztül.
A dolgozat kiértékelése részben manuálisan fog történni ezért az eredmények csak az értékelés után lesznek elérhetőek.
Személyes találkozást igénylő bemutatásra nem kerül sor, ezeket online hívással helyettesítjük a kurzus Discord szerverén.
A követelményekben megadott részekhez leadott anyagokat meg kell védeni a kurzus Discord szerverén.
- A bemutatás online hívás keretében történik az óra időpontjában.
- A bemutató elsődleges célja, hogy a gyakorlatvezető meggyőződjön arról, hogy az adott hallgató alkotói ismeretekkel rendelkezik a leadott teljesítésről.
A kurzus teljesítése továbbra is folytonos munkát kíván. Ezért javasoljuk a heti legalább 2 értékes commit/fő feltöltését a csapatok GitLab projektjébe.