Rendszermodellezés verseny feladat

FIGYELEM: A tantárggyal kapcsolatos idei tudnivalók a kar Moodle rendszerén érhetők el.

Emlékeztetőül a versenykiírás elérhető: https://vik.hk/2021/04/kari-tanulmanyi-versenyek-2021-tavasz/

Határidő: 2021.05.03. hétfő 23:59

Feltöltés a Moodle felületén (04.26. után)

A feladat egy őstermelőktől történő, közösségi vásárlást támogató rendszer modelljének megalkotása.

A COVID járvány következtében a személyes megjelenéssel járó vásárlási formák népszerűsége jelentősen visszaesett, ugyanakkor továbbra is igény van olyan árucikkek beszerzésére, melyek a tipikus házhozszállítási szolgáltatók kínálatában nem érhetőek el.

Ennek egy példája a minőségi, háztáji élelmiszerek beszerzése (zöldség-gyümölcs, húsáru, tojás, méz, lekvár, stb.).

Egy olyan platformot tervezünk, amely támogatja az egyes kistermelők és a fogyasztók összekapcsolását az alábbi módon:

• Minden őstermelő meghirdethet adott típusú árut adott szállítási időszakban.
• Minden vásárló rendelhet adott szállítási időszakra adott termelő(k)től adott termék(ek)et. 
• Lehetséges későbbi kiszállítási időszakra is rendelni, ha a termelő arra adott fel hirdetést.
• Egy rendelés egy vásárló és egy termelő közt jön létre egy kiszállítási időszakban.
• A rendelés véglegesítésének feltétele a(z elektronikus) fizetés.
• A rendszer alapvetően egyenlegeket (csak ebben a rendszerben használható "folyószámlákat") kezel, ezekre pénzt lehet feltölteni, ill. a regisztrációkor megadott bankszámlára utalással jóváírni (a rendszerből pénzt kivenni).
• A kiszállítási időszak előtt T nappal (melyet a kistermelő állíthat be regisztrációkor) a rendelés mind a vevő, mind az eladó részéről díjtalanul lemondható (a befizetett összeg a vevő egyenlegén jóváírható), a határidő után ugyanakkor a teljes összeg 
• a vétlen felet illeti az egyenlegén történő jóváírással.
• A szolgáltató (a vásárlási szolgáltatást nyújtó cég, melynek rendszerét tervezzük) a beérkezett összegeket adott jutalék levonása után jóváírja a termelő egyenlegén.
• Bármelyik résztvevő vásárolhat a rendszerben egyenlegéből, ill. jóváírhat belőle a regisztrációkor megadott bankszámlán.
• A szállítási időszakban a futár jelzi, hogy milyen időpontban viszi ki az árut. Ezt a vevő (tekintettel ara, hogy úgyis otthon van) csak egy alkalommal módosíthatja.
• Ha a kiszállítás a vevő hibájából meghiúsul, a rendelést adott átvevőhelyeken lehet átvenni adott határidőig. Az át nem vett rendelések segélyszervezetekhez kerülnek, vevői visszatérítés nélkül.
• Ha a vevő egy adott rendelés minőségével elégedetlen, panaszt küldhet be a rendszer felületén (pl. fotó+leírás). A szolgáltató a panasz kivizsgálása után tetszőleges döntést hozhat (jóváír egy összeget a vevő egyenlegén, elutasítja a panaszt,felülvizsgálja a termelőt, stb).
• Egy adott személy lehet termelő és vásárló is egyben.

Az egyszerűség kedvéért a regisztrációs/bejelentkezési folyamatok modellezésétől eltekintünk.

A rendszert kiszolgáló főbb komponensek az alábbiak:

• Front-end, ami a megjelenítésért felelős. Minden felhasználói kérés fogadása és formai ellenőrzése ezen a komponensen történik.
• Back-end, ami az üzleti logika futtatásáért (a fenti specifikációnak megfelelő rendszer működtetéséért) felel. A back-end fogadja a front-end felől érkező kéréseket, adott esetben kommunikál az adatbázissal és a fizetési szolgáltatóval.
• Adatbázis, ami tárolja a termelők és a vevők adatait és egyenlegét, a vevők megrendeléseit, a kiszállítási időszakokat.
• Fizetési szolgáltató (Payment Gateway, PGW), melyen keresztül a) utalást lehet indítani a rendszerben megadott bankszámlára (a PGW visszaküldi, hogy sikeres volt-e az utalás), b) egy szerződött pénzintézet oldalára átirányítva ott bankkártyás fizetés kezdeményezhető (tetszőleges bankkártyával), aminek eredményét a PGW visszaadja a rendszernek.

A teljesítménnyel kapcsolatos aspektusokat egyelőre nem ismerjük, a tervezés során feladat annak megbecslése is, hogy az egyes feladatok melyik komponenshez tartoznak és mennyi ideig terhelik azt. Érzékenységvizsgálat szempontjából érdekes kérdés, hogy egy ezeket a számokat érintő tévedés hogyan érinti az egész rendszer teljesítményét. Amire a megrendelő kíváncsi, az az, hogy a fő folyamatokból óránként hány futhat le, valamint hogy melyik komponensből hány darabra van szükség, hogy azok kihasználtsága a lehető legegyenletesebb legyen.

Jótanácsok: A rendszer modellezése során sokféle modellt készíthet. Nem kell mindent egy modellre tenni, a modelleknek nem feltétlenül kell közvetlenül kapcsolódnia, az egyes aspektusok nyugodtan szétválaszthatók. Természetesen minél konzisztensebb a végső modell, annál jobb, de a közbenső, egyszerűbb modellek is értékesek (érdemes lehet dokumentálni, ha valahol finomítás történt). Ha valahol hiányos a specifikáció, az a követelmények részletezésével nyugodtan kiegészíthető, az ellentmondásokat tetszőlegesen fel szabad oldani, de ezek a döntések mindig legyenek dokumentálva, és lehetőség szerint minél jobban tartsák meg az eredeti szándékot. Mivel határidős versenyfeladatról van szó, egyáltalán nem elvárt, hogy minden részlettel foglalkozzon – az értékelés az összes beadott megoldás összehasonlításával történik majd.