1. sz. melléklet: „Komplex portálrendszer fejlesztése” szakmai specifikációja
1. Bevezető 1.1. A dokumentum célja Az OTP Fáy András Alapítvány 2012-ben 1.103.552.921 Ft összegű vissza nem térítendő támogatást nyert a TÁMOP-3.2.1.B-11/1-2012-0001 azonosító számú pályázatával a Középiskolások Országos Pénzügyi és Gazdasági Oktatóközpontja létrehozására és működtetésére, mely kiemelt kormányzati projekt. E projekt révén egy hiánypótló, Magyarországon és a közép-európai térségben egyedülálló, gazdasági és pénzügyi élethelyzetekre felkészítő, magabiztos helyzetfelismerésre és problémamegoldó képességre ösztönző szolgáltatás jön létre, mely a jelenlegi igényeknek megfelelően a legkorszerűbb kommunikációs és egyéb eszközök alkalmazásával juttatja el az információkat a célközönséghez. A röviden O.K. Központnak nevezett intézmény Budapest VI. kerületében, a Benczúr u. 26. szám alatt működik. A projekt általános célja: A kiemelt projekt célja a közoktatási intézmények szerepbővítésével az egész életen át tartó tanuláshoz kapcsolódóan a középiskolások számára olyan ismeretek átadása, amelyek szükségesek a pénzügyi-gazdasági világban való eligazodáshoz, az adósságcsapdák elkerüléséhez, a döntésképes és pénzügyileg tudatos állampolgári magatartás kialakításához. A projekt konkrét célja: A projekt célja, hogy a pénzügyi és gazdasági ismereteket az általuk legkönnyebben elérhető csatornákon keresztül juttassa el a fiatalokhoz, amelynek eredményeként tudatos és eredményes pénzügyi és gazdasági ismeretanyag, szemléletmód alakulhat ki náluk, amely által a fiatalok az alapvető információk birtokában a felnőtt élethez szükséges döntésképes, jövőtudatos aktív polgárként hagyják el a középiskolát megfelelő ismeretekkel és képességekkel felruházva. Az Alapítvány pályázatában vállalta, hogy létrehoz egy önálló portált a fenti projektre, melyen keresztül az O.K. Központ szolgáltatásai online módon is elérhetők a diákok és más érdeklődők számára, illetve melyen figyelemmel kísérhető a projekt megvalósulásának folyamata. A portál központi eleme logikailag a CRM rendszer. Az Alapítvány kulcsfontosságúnak tartja továbbá, hogy a tervezett honlap okostelefonokon keresztül is könnyen elérhető és átlátható legyen, így legalább a két legelterjedtebb platformra (Android és iOS) mobil applikációt is fejlesztet. 1.2. Alapkoncepció A cél, egy többnyelvű, nem monolitikus felépítésű, teljes mértékben moduláris, könnyen frissíthető, üzemeltethető és a későbbiek folyamán akár tovább is fejleszthető portál rendszer készítése, amely rendelkezik olyan, az alább specifikált funkciókkal, amelyek segítségével az Alapítvány az Interneten keresztül is támogathatja a Központban folyó oktatást.
1.3. Fogalmak Portál: http://www.okkozpont.hu és a hozzátartozó aloldalak gyűjtőneve. Keretrendszer: A Portál és a hozzátartozó alrendszerek szoftveres környezete, amelybe a későbbiek során felsorolt modulokat működteti. Layout: A portál és a hozzátartozó alrendszerek grafikai megjelenésének, kinézetének összesítő neve. Modul: A keretrendszerbe beépülő program részek, amelyek tetszőleges üzleti logikát és a hozzátartozó megjelenítést valósítanak meg. Publikus felület: A végfelhasználók és a weboldalt látogatók által látott felület. Szerkesztőségi rendszer: A belső felhasználók és adminisztrátorok által használt, jelszóval védett felület, amelyen az oldal tartalmát és beállításait lehet módosítani. 1.4. Fejlesztési irányelvek A Portál fejlesztése folyamán maximálisan meg kell felelni az MVC fejlesztési modellnek (model-view-controller) és törekedni kell az átlátható, objektum orientált fejlesztésre. Tekintettel a várható terhelésre, a keretrendszer és a modulok kialakításánál egyaránt fokozott figyelmet kell szentelni az optimális erőforrás-használatra. A fejlesztés és a layout kialakításakor fokozottan ügyelni kell az ismert WEB-es szabványok betartására, és az fejlesztés megkezdésekor aktuális, “nem fejlesztői” verziójának való megfelelésre: W3C HTML 5, vagy annál frissebb, CSS 3.0, vagy annál frissebb. A széleskörű felhasználói bázis miatt kiemelten fontos, hogy az összes ismert asztali és mobil böngészőben teljes mértékben elérhető legyen a portál, de legalább az alábbiakban: Internet Explorer 10.0, vagy annál frisebb, Firefox 22.0, vagy annál frisebb, Google Chrome 28.0, vagy annál frisebb, Safari 6.0, vagy annál frisebb, Opera 15.0 vagy annál frisebb. A portál minden moduljának, minden vezérlő funkciójának elérhetőnek kell lennie egy szabványos API-n keresztül (pl. SOAP, XMLRPC, JSON, stb.), megfelelőnek kell lennie a jelen dokumentumban tárgyalt okostelefon applikáció, illetve a jövőben kidolgozni és illeszteni kívánt további fejlesztések egységes kommunikációs felületen és adatmodellen történő integrációjára. A portált és a hozzátartozó adatbázis rendszert úgy kell kialakítani, hogy a nagy terhelés esetén könnyedén több kiszolgálóra telepíthessük, az alábbiak szerint: A statikus tartalom (a jelszóval védettek is) külön, az ilyen célra tervezett webszerverre való telepítése (pl. lighttpd, Nginx) Olyan adatbázis szerver választása, amellyel a “master-slave” clusterezés kialakítható, további plusz költségek nélkül A dinamikus tartalom több kiszolgálóra való osztás, egy közös hálózati adattároló esetén, további szoftver költségek felmerülése nélkül
1.5. Nemzetköziség A portál magyar és angol nyelven kezdi meg működését, így az összes tartalomnak és vezérlő moduloknak, a szerkesztőségi rendszerből választható módon, több nyelven is elérhetőnek kell lennie, erre a tényre fokozottan ügyelni kell a layout és a keretrendszer tervezése és fejlesztése folyamán. A jelenlegi specifikációban tárgyalt minden modulnak szükséges az angol és magyar változatát egyaránt 100%-osan működőképesen elkészíteni. 1.6. Üzemeltetés, felhasznált szoftverek A portál üzemeltetését és elhelyezését az Alapítvány saját hatáskörében, a saját infrastruktúráján, a saját informatikai munkatársai által végzi, FreeBSD és Linux alapokon. A jelenlegi infrastruktúra az alábbi szoftver környezetekkel kompatibilis, így a rendelkezésre álló belső erőforrások valamint üzemeltetési tapasztalatok miatt ezek az elfogadható platformok a fejlesztés során. Alkalmazási réteg PHP 5.3 és vagy újabb, Java (és/vagy bármilyen Java alapú keretrendszer), Groovy, Ruby on Rails, Adatbázis réteg MySQL 5.5 vagy frissebb, PostgreSQL 8.4 vagy frissebb. Nyertes ajánlattevő köteles a fejlesztés során felhasznált szoftverek – minden korlátozástól mentes – felhasználási jogát a munka befejeztével az Alapítványra rendelkezésre bocsátani. Az elvégzett munka ellenértéke magában foglalja a felhasználási jog átengedésének díját is. 1.7. Felhasználók, látogatók A várható felhasználói adatbázis mérete jelenleg nem ismert pontosan, de legfeljebb kétmillió regisztrált felhasználóra számítunk. Hétköznapokon délelőtt, az iskolai tanítás ideje alatt kb. 80-100.000, délutáni-esti időszakban és hétvégén kb. 30-50.000 látogató várható.
2. Arculat 2.1. Általános információk Tekintettel arra, hogy a portál fejlesztése TÁMOP projekt keretében, európai uniós forrásból valósul meg, a portál designjának teljes mértékben meg kell felelnie a hatályos ÚSZT Arculati kézikönyvben egy honlappal szemben támasztott előírásoknak.
Az ÚSZT Arculati kézikönyv az alábbi linkről tölthető le: http://www.nfu.hu/doc/25 Ezen túlmenően a portálnak alkalmazkodnia kell az Alapítvány O.K. Központra vonatkozó logó használati kézikönyvéhez, illetve az O.K. Központ jelenlegi fizikai arculatához, ami a fiatalos, modern és dinamikus szavakkal jellemezhető. A használati szabályokra vonatkozó előírásokat tartalmazó leírás jelen dokumentumhoz csatolásra kerül. 2.2. Akadálymentesítés A portálnak az esélyegyenlőségi szempontokat is teljes mértékben figyelembe kell vennie, és mindenki számára biztosítani kell az egyenlő esélyű, teljes értékű hozzáférés lehetőségét az interaktív szolgáltatásokhoz a honlap info-kommunikációs akadálymentesítésével. Ez gyakorlatban azt jelenti, hogy törekedni kell a szemantikus kialakításra és nagyobb hangsúlyt kell fektetni a tartalomra, mint a designra, a W3C által kiadott ún. WCAG ajánlásban foglaltaknak a lehetőség szerint legjobban meg kell felelni. A legfőbb, de nem kizárólagos és önmagában elégséges elvárások a témában: Központi, jól látható helyen található gomb a betűméret globális, legalább három méretben történő növelésére. Főmenük és navigációs részek szigorúan szöveges kialakítása, megtámogatva a felolvasó szoftverek helyes működését. Billentyűzetről vezérelhető navigáció. Multimédiás tartalmakhoz megfelelő mennyiségű és minőségű „feliratozás” lehetősége (pl. alt, title tagek) Videók esetén feliratozás lehetősége (a feliratok elkészítése Ajánlatkérő feladata) 2.3. „Reszponzív” design A layout kialakításánál fokozott figyelmet kell fordítani az ún. „reszponzív design” kialakítására, hogy minél többféle felbontásban és minél több eszközön elérhetővé váljon a portál. Ez azért is fontos, mert a Magyarországon található középiskolák nem rendelkeznek homogén informatikai rendszerekkel és Ajánlatkérő célja, hogy minél szélesebb körben elérhetővé váljon portáljának tartalma.
2.4. Hozzáférések A weboldal tartalmaihoz és szolgáltatásaihoz a hozzáféréseket két csoportra bontjuk: látogatói és belső felhasználókra. A látogatói felhasználók attribútumairól a CRM rész rendelkezik.
2.5. Belső felhasználók
A tartalmak feltöltését és kezelését több alapítványi munkatárs fogja végezni, ezért a felhasználók hozzáféréseit, modulokra bontott jogosultsági mátrixban kell tudnunk kialakítani. Az alábbi főbb, előre definiált felhasználói csoportokat kell létrehozni, amelyektől a későbbiekben akár el is térhetünk egy-egy felhasználó esetén. Típus
Hozzáférés típusa
Adminisztrátor
Teljes hozzáférés.
Szerkesztő
Teljes hozzáférés, kivéve a CRM.
Cikkíró
Létrehozhat és módosíthat cikkeket, de azok szerkesztői jóváhagyás nélkül nem publikálódnak.
Teszt értékelő
Csak a kvízek és tesztek modulhoz fér hozzá, a leadott nem automatikusan értékelt teszteket értékeli.
Blog moderátor
Az elkészült „postokat” és kommenteket hagyja jóvá.
Blogger
A saját blogjához teljes hozzáférése van, de a moderátor nélkül nem publikálhat.
Multimédia szerkesztő
Multimédiás modulokhoz teljes hozzáféréssel rendelkezik.
Multimédia feltöltő
Multimédiás anyagok feltöltője, de a multimédia szerkesztő jóváhagyása nélkül azok nem publikálódnak.
CRM adminisztrátor
CRM rendszerhez teljes hozzáférése van.
CRM feltöltő
CRM rendszerben adatokat tölt fel, de nem tud véglegesen törölni / módosítani.
A belső felhasználókat kezelő adminisztrátori modul legalább az alábbi funkciókat valósítsa meg: Új felhasználó létrehozása Létező felhasználó adatainak módosítása, törlése, kitiltása Meglévő felhasználó jogosultsági mátrixának másolása Elfelejtett jelszó esetén egy új jelszót generáló e-mailben küldése 2.6. Belső felhasználók naplózása A párhuzamos, több belső felhasználó által folyó tartalomfeltöltés miatt kiemelten fontos, hogy az Adminisztrátorok minden elvégzett műveletről részletes naplózást kapjanak, amely kiterjed minden alapvető műveletre ellenőrzés céljából. Alapvető műveletnek számít: Be- és kijelentkezés Listázás
Módosítás, elmentve a korábbi és a „módosult” adatokat szérializálva (kivéve
multimédiás anyagok) Törlés
A felhasználói naplózás legyen kereshető és szűrhető vagy/és kapcsolatban:
Felhasználóra Adott modulra Idő intervallumra Bizonyos műveletekre A naplózásban szabad szavas keresésre
3. CRM rendszer A teljes rendszer központi eleme logikailag a CRM rendszer. Ebben valósul meg az adatok gyűjtése, rendszerezése, szűrése, kiértékelése. Az adatok tárolásán és feldolgozásán, az analitikai készségeken kívül a CRM rendszer vezérlési funkciót is ellát. Minden külső alrendszer ebből táplálkozik, a megvalósítandó külső funkciók vezérlését pedig elképzelés szerint a CRM látja el. Feladatokat oszt ki, vezérlési feladatokat végez, adatokkal látja el a külső rendszereket, visszacsatolásként pedig begyűjtött, vagy éppen a kiosztott feladatok feldolgozott értékeit várja (gyűjti be) a külső programoktól. Legyen szó egy kérdőívről, az információs portál, vagy éppen a mobilalkalmazások adatgyűjtéseiről – mindegyiknek, ha áttételesen is, de a CRM-mel kell kommunikálnia – egy központi felületen kell megvalósítani a komplex adatgyűjtési feladatokat. Technikai szempontból a fejlesztési irányelvekben megfogalmazott követelményeknek kell, hogy megfeleljen a CRM. Mivel a teljes rendszernek ez a központi eleme, és minden alrendszernek, illetve a CRM moduljainak magának is egységes adatszerkezetben és formában kell adatokat mozgatnia-kezelnie, a következő szempontokat kell a tervezés és megvalósítás során szem előtt tartani: modern API kialakítása (SOAP, XML, vagy JSON, szabadon választott) ilyen módon egységesített kommunikációs metódusok kialakítása a teljes rendszerben ezek részletes, tételes dokumentálása a CRM oldalán, legalább hivatkozás a külső modulok dokumentációjában adatszerkezetek dokumentálása, majd implementálása (mi mivel áll kapcsolatban, a forgalmazott adat milyen minőségben, hol és hogyan kerül tárolásra) Szintén a korábbi, integrációval kapcsolatban megfogalmazott elvárások és az EU szabályozások miatt a rendszernek minden regisztrált felhasználót nyomon kell követnie. Ez kiemelten érvényes az elvégzett tesztek, e-learning anyagok, kvízek tekintetében. Szavazásokból kivételként választhatóan lehet zárt, csak regisztrált felhasználóknak szóló, de lehet nyilvános, statisztikai adatgyűjtést szolgáló célú is. Cél ugyanakkor az oktatási anyagok állandó fejlesztésén keresztül a minőségi tartalom folyamatos közvetítése a felhasználók számára. Ennek érdekében a rendszernek állandó kapcsolatot kell tudni tartani a felhasználókkal. Ez más, egyedi módon azonosítható adat hiányában az e-mail cím, mint egyedi kulcs meglétét feltételezi. A rendszer megvalósítása során elsődleges fontosságú tehát a felhasználó mindenkori e-mail címének ismerete, és a változások aktualizálása,
összevezetése. Egy felhasználó rendelkezhet több e-mail címmel is, illetve a jelenlegi tervek alapján elkészült rendszerben az adatfeltöltések és változások során könnyen előfordulhatnak duplikátumok, így ezek kezelésének megoldása is elengedhetetlen (adatok, előtörténetek összevonási lehetősége, ütközések kezelése). Ahhoz, hogy a rendszerezést és keresést átláthatóan és hatékonyan lehessen megvalósítani, valamint a napi rutin adminisztrációs munkák elvégezhetők legyenek, egy komplex, eredményhalmazok műveletvégzését és az eredményhalmazok adatainak tömeges kezelését is lehetővé tevő komplex kereső megvalósítása szükséges. Ez a rendszerben több ponton is használható. Működésének alapelvei a következők: Keresünk egy csoportra, vagy csoport bizonyos tagjaira, kapunk egy halmazt, Tovább keresünk tetszőleges alkalommal, újabb eredményhalmazt kapva, Az így kapott halmazok között egyszerű logikai műveleteket végezhetünk, pl. kérjük az első halmazba tartozó, de a másodikba nem tartozó elemeket (ÉS, VAGY, NEM), A keresések végén az így kapott halmazok műveletekkel szűrt elemeire végzünk egy bizonyos tevékenységet, például levelet küldünk neki, frissítjük bizonyos mezőit, éppen az elvégezni kívánt funkció szerint. Könnyítés, hogy a kereső csak egyfajta entitási eredménytípussal rendelkezik, műveleteket csak ezekkel a halmazokkal lehet végezni, tehát a mezők számossága és a mezőtípusok minden esetben egyeznek. A CRM rendszerben szükséges vezetni az O.K. Központ látogatóinak és diákjainak „eseményeit”, dinamikusan felépíthető, tetszőleges adatmezőkkel. Ide tartoznak a csoportok szervezésére és részvételére vonatkozó csoport- és egyedi információk (pl. a diákok jelenléti ívei, vagy az oktatásokon való részvétel tényének adatai). Ezek csoport és egyén szinten köthetők kell, hogy legyenek, akár örökléssel, akár manuális módon az elemekre egyenként, ez a megvalósításnál szabadon választott, azonban a funkciók az adminisztrációs munkafolyamatok során egyszerűen átlátható és kezelhető formában kell, hogy megvalósításra kerüljenek. Javasolt a komplex keresési és szűrő funkciók eredményhalmazaira alkalmazott műveletvégzés alkalmazása ebben az esetben is. Ehhez kapcsolódóan a következő eseményeket: Meghívók küldése eseményeken való részvételre. (ez lehet oktatás, de akár nyári fesztivál is) Ezekre érkezett válaszok értékelése (visszajeleztek, vagy nem, részt vesznek, hány fővel, stb.) Egy létező felhasználó jelzett, kérdezett valamit, és az erre adott válasz. (erről bővebben a Felhasználói üzenetek és Online tanácsadás résznél) Oktatások adatai: résztvevők, nem jöttek el, stb. Magának az oktatásnak az eseményei, megjegyzései, melyek nem köthetőek személyekhez (oktatás mellé kapcsolt “Egyéb megjegyzés” mező) Minden kommunikációs folyamatot egyértelműen le kell tudni zárni egy eredménnyel. A rendszer egészére tekintve is általánosan igaz, hogy a tevékenység jellegétől függően nyilván az is lehet eredmény, ha nincs eredmény, például nem jeleznek vissza többszöri megkeresésre sem, de nem maradhat a rendszerben hosszú távon nyitott munkafolyamat, esemény. A lezárás lehet automata bizonyos feltételek teljesülése mellett, de manuális, kifejezetten kezelői beavatkozást igénylő is, például egy kifejtést igénylő kérdés kiértékelése.
Egy felhasználót tetszőleges mennyiségű csoportba is kell tudni rendezni, akár úgy is, hogy egy felhasználó több csoport tagja is lehet. A felhasználókhoz tetszőleges mennyiségű plusz adatmezőt szeretnénk rendelni és ezekre a mezőkre a globális adatlekérő és szűrő segítségével tetszőleges lekéréseket, adatgyűjtéseket szeretnénk végezni. A lekéréseket akár paraméterezhető formában tárolnánk, így a későbbiekben ezek sablonként szolgálhatnak további lekérdezésekhez, vagy pár gombnyomással újra végrehajthatóak. Az egészet az adatbázisok analógiájára mintegy SQL lekérdezés-tárként kell elképzelni, paraméterezve, a query-k mellé előre eltárolt javasolt, de bármikor változtatható paraméterekkel. A következő funkciók megvalósítása kiemelten szükséges: Lekérdezés létrehozása, szerkesztése Paraméterek értékeinek változtatása Lekérdezés másolása, új paraméterekkel való tárolás Az adatgyűjtések eredményét exportálni lehessen a felhasznált irodai programcsomagok (MS Office, OpenOffice, LibreOffice) által értelmezhető és a későbbi feldolgozást lehetővé tévő Excel, CSV, vagy XML formátumba. A CRM rendszernek kommunikációs feladatokat is el kell látnia. Igényeink szerint hírlevelet küldenénk belőle, a már tárgyalt komplex keresési-szűrési feltételek alapján előállított tetszőleges eredményhalmazok elemeire. Kommunikáció tekintetében az események követése, kiértesítés, visszaigazolás kezelése is a CRM feladata; eredményei be kell, hogy kerüljenek a rendszerbe: pl. a szervezői munka során kiválasztott csoportok és/vagy egyének értesítése az egyeztetett látogatási időpontról, visszaigazolás kérése jóváhagyással, stb. A folyamatvezérlés megoldása tetszőleges módszerrel történhet, parametrizálás tekintetében az adatok körében alkalmazott rugalmas bővíthetőség szem előtt tartásával. A kommunikációs feladatok kezelésének témakörébe tartozik a kommunikáció teljes körű naplózása is. A kiküldött e-mailek, hírlevelek, kampányok kezelése, naplózása, visszajelzések megfelelő helyre kapcsolása a folyamatokban, azok kiértékelése, illetve a munkafolyamatok követésén felül például a telefonhívások tényének és eredményének MANUÁLIS rögzítése is a CRM feladata. A CRM rendszer feladata a nem aktív fiókok (userek, e-mailek) detektálása (például az e-mail kézbesítési jelentések alapján). Ez szerves egységet képez a teljes rendszer használata során a belépések, aktivitások naplózásával, ki kell tudni például szűrni és kezelni kell tudni a nem létező e-maillel, de aktív fiókkal rendelkező felhasználókat, és az alrendszerek használata során időről időre figyelmeztetni kell őket az elérhetőségi adatok aktualizálásának szükségességére. Megadhatóak opcionális adatmezők is, mint telefonszám, ezek tartalmának mindenkori meglétére azonban nem számíthatunk teljes biztonsággal. Törekedni kell arra, hogy a felhasználóhoz tartozó fiók elérhetőségi információi minden időben a lehető legfrissebb adatokat tartalmazzák. Ennek érdekében elképzelhető a jövőben e-mail elérhetetlenség és mobilszám megléte esetén például SMS-ben történő kommunikáció is. Fentebb említésre került, de újra kiemelendő és fontos, hogy az adatmezők nem lehetnek fixek, ajánlatkérő szeretné a későbbiek folyamán felépíteni a struktúrát.
Ezekre is a fentebb leírt módon életszerű adattartalmak esetén a fenti szabályokat kell tudni az adminisztráció során alkalmazni. A fenti irányelvek szem előtt tartásával a rendszer felhasználóit (elsősorban a tanárokat és diákokat) ösztönözni kell a rendszer látogatására, törekedni kell az adatok minél egyszerűbb és gyorsabb kézbesítésére. Ennek elsődleges módja az e-mail kommunikáció, másodlagos módja az alrendszerek (portál, mobil alkalmazás) felületén az azonosítási folyamat után a megfelelő csoportnak/egyénnek szóló üzenetek megjelenítése. Az oktatási anyagokon, híreken, más információkon keresztül bármely alrendszer meglátogatása, használata során a felhasználó, ha áttételesen is, de a CRM rendszerrel interakcióba kerül, így fenntartható az állandó kapcsolat a teljes életciklus alatt. A még nem regisztrált látogatók számára létre kell hozni a regisztrációs folyamatot, melynek során az alábbi, kötelező mezőket kell megadni: Vezetéknév, Keresztnév Látogató típusa (diák, tanár, szülő, egyéb) Nem Születési dátum Lakhely (település neve) E-mail cím A jelenlegi iskola típusa (általános, közép, felső oktatási intézmény) A jelenlegi iskola neve A regisztrációkor aktuális osztály megjelölése diákok esetén, mely automatikusan frissül évente, de feltételekkel és megerősítéssel, parametrizálni kell az osztályok konfigurációját is (4+4+4, 4+2+8, 4+6, stb), valamint lehetővé kell tenni a rendszerben a továbbtanulás követését is ide kapcsolódóan. Jelszó Hírlevél igénylés (igen/nem választható) Szolgáltatási feltételek elfogadása (adatvédelem, stb) – Enélkül nem léphet tovább A felhasználó profiloldalán lehetőséget kell biztosítani az adatok módosítására, további iskolák feltöltésének javasolására, fiók törlésének online kérésére, valamint a rendszerrel való kommunikációra (üzenet az adminnak). A felhasználó email címét csak visszaigazolással változtathatja meg. A profiloldalon kell megjelenjenek a regisztráció során hiányzó adatokra való visszautalások is. A felhasználó profil oldalán megadott adatokat a CRM rendszeren belül is láthatóvá kell tenni és az esetleges „adat konfliktusok” esetén értesíteni kell a kezelőket (pl. már rögzítettük ezt az e-mail címet egy korábbi oktatáson részt vett egy, vagy több csoportnál). A külső rendszerekbe felkerülő korlátozott tartalmakhoz való hozzáférést a CRM modulban adjuk a felhasználóknak, tehát a vezérlést ebben az esetben is a CRM végzi. Lehetőséget kell biztosítani a kezelőknek adatok tömeges importjára CSV, vagy XML file-okból. A mezők megfeleltetettségét a megkívánt flexibilis, előre nem látható adatstruktúrák miatt tárolni szükséges, azaz menthetővé kell tenni az import file-ok datamap-jét a későbbi gyors felhasználhatóság érdekében egy újabb, hasonló import végrehajtása során. Az adatok importja során a CRM rendszerben az ütközések, duplikátumok kezelését a már fentebb említett módon szükséges megvalósítani. Lehetőséget kell biztosítani azonos típusú entitások halmazán belül a keresésre, tömeges
műveletvégzésre, csoportképzésre és besorolásra, valamint az entitások és összes kapcsolt adatuk egyesítésére is. A rendszer felhasználójává háromféleképpen válhat egy személy: feliratkozás a fentebb említett regisztrációs folyamat segítségével adatfeldolgozás során történő egyedi kezelői adatfelvitel vagy tömeges import során. A felhasználó mielőtt hozzáférést kap a rendszerhez, azaz fiókja teljes értékűen aktiválódik, mindenképpen ellenőrzési folyamaton kell átessen. Az ellenőrzési folyamat kezelői segítséggel átugorható, bármely fiók megbízhatónak minősíthető egy flag beállításával. Az ellenőrzési folyamat egyszerű, kétlépéses e-mail ellenőrzés. Regisztráció esetén a rendszer kiküld egy e-mailt, a benne lévő linkre kattintva a felhasználói fiók aktiválódik. Bármely egyéb esetben (adatfelvitel vagy tömeges import során) a megbízhatósági flag állítható a felvitel során, amennyiben azonban nem ellenőrzött fiókként kerül a rekord felvitelre, a normál e-mailes visszaigazolási eljárás érvényes. Egyedi felvitel vagy tömeges import esetén generálható a jelszó, amit titkosított formában kell a rendszerben tárolni. Ezt egyszeri alkalommal, egy jelszó generáló e-mail formájában a rendszer kiküldi a felhasználónak. Biztosítani kell a felhasználónak a jelszó vissza- vagy beállítás lehetőségét is (elfelejtett jelszó esete), szintén e-mail címéhez kötött módon. A rendszer publikus felhasználói nem látják az audit logban szereplő, fiókjukhoz kapcsolt tételeket, ennek megvalósítása nem szükséges. Az adatkezelési törvényi megfelelőség miatt szükséges a fiókok törlési lehetőségének megvalósítása is. Ez kiemelten adminisztrátori funkció, és az adatok teljes körű, ellenőrizhető törlésével jár a felhasználó fiókjának minden kapcsolt adata tekintetében. 4. Online szolgáltatások A portálon keresztül online formában is elérhetővé válnak az O.K. Központ által biztosított szolgáltatások. Míg a projektről szóló, az O.K. Központ tevékenységével kapcsolatos általános információk regisztráció nélkül bárki számára elérhetők, addig az oktatási tartalmak csak regisztrációt követően, amelynek paramétereit a CRM rendszerben határozzuk meg. 4.1. Felhasználói üzenetek A felhasználóknak szánt értesítéseket párhuzamosan, két szinten: e-mailen és a belső üzenetküldő rendszeren keresztül valósítjuk meg. Minden felhasználó rendelkezik egy saját fiókkal, amelyhez a web felületen és a mobil applikáción keresztül férhet hozzá. A felhasználó üzenetet küldhet az Alapítványnak és más regisztrált felhasználónak, amennyiben ismeri az azonosítóját (regisztrációnál használt e-mail cím). Ehhez megvalósítandók legalább az alábbi alapvető üzenetkezelési feladatok: új üzenet törlés válasz továbbítás
SPAM/illegális tartalom jelentése
4.2. Tartalom kezelés, CMS 4.2.1. Általános információk A tartalomkezelő rendszer jelenlegi megvalósításában korszerű technikákat kell alkalmazzon, moduláris felépítésű kell legyen. Az alkalmazott szerkesztőfelületnek WYSIWYG editor segítségével kell a tartalom kezelését megvalósítani, hogy a feldolgozás során a publikus felületre kikerülő minden informácó és tartalom már a szerkesztési fázisban a végleges állapothoz legközelebbi képet mutathassa, így a legegyszerűbb módon behatárolható legyen a végeredménye minősége. Amit a jövőben elvárunk tőle: moduláris felépítés pl. a WYSIWYG editor komponens magában is frissíthető, cserélhető legyen egy esetleges frissítés esetén (mivel ezek főként biztonsági frissítések, így mielőbbi alkalmazásuk erősen ajánlott). A CMS, (azaz Content Management System), segítségével szerkeszthető tartalmak létrehozása, szerkesztése, valamint a létrehozott tartalmak strukturálása a cél. A CMS-t úgy kell kialakítani, hogy általa a tartalmakat csoportokba szervezhessük, menüket alakíthassunk ki, mindezt nyelvesítéssel együtt kényelmesen, egy központi felületről kezelve, hogy az egész rendszert egyben láthassuk. Szükséges az adminisztrációs felületet kialakítása, ahol a rendszerbe bevitt adatokat irányított módon a felhasználók felé tudjuk közvetíteni. Sarokpontok, melyeket figyelembe kell venni a CMS fejlesztéskor: Méretezhetőség Sebesség, gyorsaság (Cache, Memcache, stb. a méretezhetőséggel összhangban) Biztonság Keresőbarát kialakítás (Meta elemek, mezők kezelésének lehetősége) Többnyelvűség (dinamikusan bővíthető, nyelvi paraméterek) Intuitivitás (egyszerűen használható, elegáns, érthető, következetes admin interface) Jövőbeli bővíthetőség Építkezzen biztonságos, de könnyű alapokra. Külső komponensek felhasználása esetén azok moduláris jellegű felhasználására törekedni kell. 4.3. Sebesség Tekintettel arra, hogy a felhasználók rangsorolásában fontos tényezőként szerepel egy rendszer gyorsasága, az oldalakat gyorsan kell generálni, és a távoli látogatókhoz kézbesíteni. Ezért a rendszernek Cache-ből (gyorsítótár) kell dolgoznia. Ez megvalósulhat több szinten, ennek kialakítását a megvalósítóra bízzuk, javaslatokat várunk. Az elérni kívánt cél az oldalak 2 másodperc alatti időben történő generálása, még nagyobb terhelés, sok egyidejű látogató esetén is. 4.4. Biztonság Mivel a tervezett rendszer publikus felületeinek nagy része az interneten keresztül potenciálisan bárki számára hozzáférhető, fontos hogy biztonságos webes rendszer készüljön. A teljes rendszer megvalósítása során arra kell törekedni, hogy az adatbeviteli
és -feldolgozási folyamatok során a rendszerbe kerülő adatok ne okozhassanak fennakadást a működésben. Főbb pontok e tekintetben: Beviteli mezők típusainak ellenőrzése, adott esetben a bevitt adatok típuskényszerítése (pl. ne írhasson dátum mezőbe „esernyő”-t) Az adatbeviteli és feldolgozási folyamat biztonsága (XSS, SQL Injection elleni atomi szintű védelem) Az adatok hozzáférési szintjének ellenőrzése az adatbeviteli és lekérdezési folyamatokban is egyaránt. (ne tudjon egy felhasználó egy másik felhasználó adataihoz hozzáférni pl. egy beviteli mező értékének, vagy egy változó értékének manuális felülírásával hozzáférni) A rendszerben folyó adatáramlás biztonságossá tétele pl. SSL használatával a kívánt pontokon (jelszavak, vagy egyéb érzékeny, személyes adatok mozgása). Ügyelni kell az SSL be- és kilépési pontoknál a megfelelő adatátadási mechanizmus kialakítására is, célszerű lehet például egy központi felhasználó-azonosítási pont kialakítása, amivel az összes modul kommunikál szükség esetén. 4.4.1. Keresőbarát kialakítás A rendszer fontos feladata a felvitt tartalom közvetítése a meglévő, valamint a potenciális felhasználók számára. Részlegesen zárt rendszerről lévén szó itt elsősorban a publikus tartalmak rendszerezése során kell a keresőkben elfoglalt pozíciók minél előnyösebb módon történő megszerzésére és megtartására koncentrálni. Ennek érdekében úgy kell kialakítani a rendszer szerkezetét, hogy a publikált oldalak rövid időn belül a találati listára kerülhessenek. Az ehhez szükséges mezők köre a következő (szintén nyelvenként változó): cím (title) kulcsszavak (keywords) leírás (description) nyelvkód (language) 4.4.2. Többnyelvű CMS Angol és magyar nyelven kommunikál az oldal a látogatókkal, kezdetben erre kel felkészíteni a rendszert. A nyelvek rugalmas bővíthetőségének lehetőségét azonban meg kell teremteni minden tartalmi elem és objektum szintjén. A nyelvesített tartalmak nem okvetlen kerülnek tükörfordításra minden esetben, elképzelhető, hogy a rendszer használata során egyes elemek (hír, cikk, oldal) nem kerülnek egy az egyben lefordításra, így a menü struktúrában sem játszanak az adott nyelven szerepet. Lehetőséget kell biztosítani ugyanakkor a kapcsolódó nyelvi tartalmak párosítására is (például könnyen meg kell tudni találni egy angol nyelvű cikkhez a magyar vagy később mondjuk francia fordítását, amennyiben létezik ilyen). Optimális esetben ez mindenhol egy gombnyomás kell legyen. 4.4.3. Intuitivitás Az adminisztráció könnyű kezelhetősége, átláthatósága alapelvárás. A rendszer fejlesztése és bevezetése során hangsúlyt kell fektetni a következetes UI tervezésre, valamint az elemek (gombok, vezérlő eszközök) szerepének következetes használatára ergonómiai és logikai szempontból egyaránt. A tartalomkezelők, és rendszerüzemeltetők általában nem programozó képzettségűek, ezért olyan felületi megvalósításokkal, UI elemekkel kell dolgozni, melyek egyértelműek, könnyen
tanulhatók, netán más rendszerekből már ismerősek. Ugyanez érvényes mind az adminisztrációs, mind pedig a publikus felületekre. 4.4.4. Bővíthetőség Az O.K. Központ szándéka további alrendszerek és modulok fejlesztése a jövőben, ezért a rendszert úgy kell kialakítani, hogy később további modulok legyenek hozzá kapcsolhatók, vagy a meglévők átalakíthatók. 4.4.5. A teljes rendszer építkezzen biztonságos és könnyű keretrendszerre és komponensekre Fontos szempont, hogy a kész rendszert egyszerűen üzembe lehessen helyezni, könnyen lehessen az automatizmusok segítségével üzemeltetni, és maga a rendszermag is a lehető legbiztonságosabb legyen. Ennek érdekében a Fejlesztő használhat valamilyen keretrendszert, vagy keretrendszereket, és külső komponenseket. Ezek beépítése során fokozottan ügyelni kell a modularitás megtartására, az egyes komponensek frissítéseinek külön-külön alkalmazhatóaknak kell lenni a teljes rendszer egységének megbolygatása nélkül. A frisssítések során előfordulhatnak inkompatibilitási problémák, ezek kezelése egyedi feladat a későbbiekben. Szem előtt kell tartani a moduláris felépítésből adódó előnyök megtartását. Lehetőség szerint előnyben kell részesíteni a legújabb, akár jelenleg béta állapotú komponensek beépítését, tekintettel a fejlesztés idejének nagyjából 9 hónapos, valamint az éles üzembeállítás tervezett idejének 1-2 hónapos időtartamára. A szerződést megkötésének idejében elérhető lehető legfrissebb és támogatott komponensek használatával. Nem szabad olyan komponenseket használni, ahol a tervezett időben már valószínűsíthetően újabb verzió kerül kibocsájtásra, és ez a rendszer működésében fennakadásokat okozhat. 4.4.6. Moduláris design A megjelenítési feltételeket kiegészítjük azzal, hogy bármely oldalhoz lehessen kiválasztani más-más sablont, ily módon a rendszer publikus felülete több sablont kell kezeljen. A rendszer felépítésének moduláris voltából fakadóan célszerű lenne a központi CRM rendszer és a külső rendszerek, valamint azok moduljainak egységes programozási szerkezetben és térben történő elhelyezése, valamint keretrendszer a teljes rendszerre vetítve. 4.4.7. Korszerű komponensek, dokumentáltság Fontos, hogy a rendszer az élesítés időpontjában a lehető legkorszerűbb eszközöket használja. A rendszernek jól dokumentáltnak kell lennie mind felhasználói, mind pedig technikai-programozói szempontból, akár már menet közben is. A tervezés és megvalósítás során MVC szerkezet alkalmazása elvárt. A fejlesztési folyamat során valamilyen verziókövető rendszer használata elvárt. Ismert, stabil, jól dokumentált osztályok használata követelmény a fejlesztéshez. Az CMS használata során a fájlkezelés, meta elemek kezelése, az egyszerű szerkeszthetőség és az átlátható adminisztrációs felület megvalósítása kiemelkedő szerepet kap. Fontos, hogy a rendszert bárki egyszerűen kezelhesse, a tartalomkezelő átlátható, ismerős elemekből és logikával építkezzen. Arra kell törekedni, hogy leegyszerűsítsük az adminisztrációt. Fontos, hogy bármely tartalmi elemhez, cikkhez, hírhez lehessen fájt feltölteni és meta leírásokat megadni. File feltöltés alatt a file-ok
típusainak egy-egy zárt körét értjük, mely a tartalom kontextusában változó módon, de egységes vezérlési struktúrával oldja meg a kapcsolt tartalmak kezelését, legyen szó képi, vagy dokumentum elemekről, pl. kapcsolt PDF file. Az állományok és könyvtárak esetén megvalósítandó funkciók: Fájlkezelés - Médiatár kezelése Fájlkezelés - Minden modulhoz Meta elemek kezelése Iframe megjelenítése WYSIWYG editor Felhasználói élményt javító modulok Admin sablon 4.4.8. A fájlkezelővel szemben támasztott elvárások Fontos, hogy olyan fájlkezelőt fejlesszünk, amivel egy központi helyen szinten mindent elintézhetünk. Fontos szempont itt is a biztonság. Külső komponens választása esetén figyelembe kell venni, hogy a választott fájlkezelő folyamatos fejlesztés alatt legyen, valamint a beépítés során a fentebb említett modularitási követelményeknek feleljen meg, azaz használjon adott esetben bővítményeket, azonban a felhasznált komponens kódbázisán a lehető legkisebb, vagy semmilyen mértékben se módosítson direkt módon a fejlesztés során. Így cserélhető, frissíthető marad az adott komponens a későbbiekben. A fejlesztés során a következő funciókat kell megvalósítani: Biztonság (kezelt fileok típusellenőrzése, végrehajtás kizárása) Csoportos fájl feltöltés (video, kép, szöveg, egyéb csatolmány típusok) Mappa létrehozás Mappa attríbútumainak állítása (nem filerendszer szintű, hanem meta adatok, naplózva és jogosultságkezeléssel) Fájlok átnevezése Fájlok mozgatása Fájlok megtekintése, letöltése, kiszolgálása Fájlok címkézése Felhasználói szintek kezelése hozzáféréseknél Beállítási lehetőségek (maximum méretek, feltölthető fájlok, kiszolgálás) Korlátozható legyen fájl méretre és típusra Képekkel kapcsolatos műveletek: Képek szerkesztése Képek forgatása Képek kivágása Képek átméretezése Kép megtekintése A média kezelőnek, mint komponensnek a fájlok útvonalát vissza kell tudnia adni pl.: egy input mezőbe. pl. rákattintunk egy input[text] mezőre, bejön a médiatár és kiválasztjuk a fájlt. Dupla kattintással visszaadja a fájl útvonalát. Ezen kívül még szükség van egy olyan fájlkezelőre, amivel minden modulhoz (modul, rekord, cikk, hír, vagy egyéb tartalmi elem), fel tudunk tölteni képeket, videókat, fájlokat és ezeket a file-okat képesek vagyunk kezelni is egyúttal, lehetőleg ugyanabban a rendszerben. (kategóriák, címkék, feltöltés, törlés, aktív/inaktív állapotok, csoportos műveletek, leírások megadása)
Mind a média kezelőnél, mind pedig egyébként a rendszer külső forrásból származó egyéb komponenseinél fontos, hogy ne tegyük olyan alapértelmezett elérési útvonalra, amit a leírásokban javasolnak, az interneten automaták keresik a sérülékenységeket, napi több száz kérés érkezik pl. a phpmyamin vagy az fckeditor alapértelmezett könyvtáraira esetleges betörési kísérletek előkészítése okán. 4.4.9. Szempontok a modulokhoz kapcsolható fájloknál Többnyelvű leírások (alt, title, description, címkézés) Csoportos műveletek végzésének lehetősége (feltöltés, törlés, be-és kikapcsolás) Tudja megkülönböztetni a képfájlt, videót, dokumentumot és ennek megfelelően készítse el hozzá a bélyeg képeket, illetve kérje le a szükséges adatokat hozzá (pl. hivatkozott Youtube videó). 4.4.10. Meta elemek leírása Minden oldalhoz, modulhoz kell legyen egyedi meta leírás megadásának lehetősége. Ez főleg a keresők számára értékes információ. Ezt globálisan is meg lehet oldani automatizálva, vagy egyedi módon objektumonként is meg kell legyen adható az információ. 4.4.11. WYSIWYG editor A szerkeszthető honlapok lényege a jól kiválasztott editor, amit a felhasználók egyszerűen használhatnak. A WYSIWYG editor a CMS központi eleme, ez maga a szerkesztő felület. A szerkesztő felület lehetőség szerint mindig csak a megkívánt funkcióknak megfelelő kontrollokat jelenítse meg a teljes eszközkészletből, ne adjon módot oda nem illő formázások, funkciók használatára, amivel felhasználói szinten elrontható az előre meghatározott arculat. A WYSIWYG editorral szemben megfogalmazott elvárások: Tudjon több változatot kezelni Egyszerűen lehessen inicializálni Ne legyen terhelő kliens oldalon Kódbázisa álljon folyamatos fejlesztés alatt 4.4.12. Szerkesztőségi rendszer layoutja Mivel a CMS felhasználók nem informatikai szakemberek, többségük semmit nem tud a HTML-ről, CSS-ről és hasonló szakszavakról, ezért a lehető legegyszerűbben, desktop jelleggel kell megvalósítani mindent, hogy élmény legyen a tartalomkészítés, az adminisztráció és minél kevesebb időbe teljen mindez. 4.5. Hírek Folyamatosan, napi szinten frissülő és megújuló tartalom, kategorizálható, akár időzített megjelenéssel is. Minden hírhez legyen lehetőség kulcsszavak és a kereső marketinget támogató paraméterek beállítására is (HTML Title, keywords, description). Amennyiben ez kézzel nincs beállítva, ezeket a paramétereket automatikusan állítsa össze a rendszer a tartalomból kiemelt, leggyakrabban előforduló szavak-kifejezések alapján. Ezen mezők
értékei a tartalom alkalmi változtatásával együtt annak megfelelően dinamikusan frissüljenek. Automatikus beállítás esetén maximum 5-10 kulcsszót tegyen össze a rendszer a címből és a tartalomból. A híreknek hírfolyamban kell megjelenniük, mégpedig úgy, hogy a dátum alapján a legutoljára létrehozott cikk legyen az első. Szükség van arra is, hogy bizonyos kiválasztott cikkek (legalább 3 db) kiemelt cikként jelenjenek meg az oldalon. Legyen lehetőség egy adott aloldalra egy vagy több kategóriából, akár kulcsszó alapján is, egy szűrt hírfolyam létrehozására, amely szintén tartalmazhat saját kiemelt cikkeket. Akár a teljes, akár a szűrt hírfolyamhoz teljes RSS feed szükséges, továbbá az összes ismert „web 2.0” megosztási lehetőség (Facebook, Twitter, G+). A web 2.0 megosztási lehetőségek köre a későbbiekben legyen bővíthető. 4.6. Statikus oldalak A szerkesztőségi felületnek rendelkeznie kell egy ún. statikus oldal létrehozásának lehetőségével, amellyel tetszőleges számú és szintű aloldal hozható létre. Ezek az aloldalak egy, a címből készült URL-en érhetők el és a továbbiakban így lehet rájuk hivatkozni. Az alábbi aloldalak aktívan, a Főmenüben is megjelennek a portálon. 4.7. Központi tevékenység A tartalma alapvetően fix, de meg kell hagyni annak lehetőségét, hogy a tartalma bővüljön, változzon. A menüpontnak be kell mutatnia mind az Alapítvány pénzügyi, gazdasági edukációs tevékenységét, mind pedig az európai uniós projektnek, az O.K. Központnak a tevékenységét. Az egységen beül mind a menüpontokat, mind a cikkek számát lehessen módosítani, bővíteni. 4.8. Pénzügyi, gazdasági, gazdálkodási ismeretek Az Alapítvány pénzügyi, gazdasági, gazdálkodási ismereteinek (pl. oktatási tananyagok, filmek, stb.) elektronikus megvalósítása, statikusan letölthető tartalmi elemekkel. A tartalmi elemek hozzáférhetőségét tetszőlegesen lehessen beállítani a CRM modulból. 4.9. Videó riportok A hírekhez hasonlóan folyamatosan frissülő videó tartalom. Ennek is alkalmasnak kell lennie arra, hogy kiemelt cikként jelenjen meg a főoldalon. 4.10. Közérdekű adatok
Az európai uniós projektek kötelező nyilvánosságára vonatkozó szabályozók szerinti tájékoztató oldal, tartalma alapvetően fix: adott időközönként, letölthető formában beszámolókat és egyéb dokumentumokat kell közzétenni. 4.11. Gyakran Ismételt Kérdések Folyamatosan lehessen fejleszteni a friss tartalmakkal. Ez segít megszűrni az érdeklődőket. Sokan az általános kérdéseikre megkaphatják a választ, így ha esetleg további kérdésük merül fel, az már jóval konkrétabb. Ezzel az ügyfélszolgálat erőforrásaival lehet takarékosabban bánni, a kiszolgálási idő csökkenthető, több kérdés megválaszolására nyílik lehetőség. 4.12. Tesztek, kvízek 4.12.1. Általános információk A kiegészítő modulok (kvízek, tesztek, rejtvények), illetve a működéssel kapcsolatos tartalmak folyamatosan kerülnek fejlesztésre és a honlapon elhelyezésre. A folyamatos teszt és kvíz fejlesztéshez első körben egy általános, absztrakt belső keretrendszer elkészítése szükséges, melynek segítségével a későbbiek folyamán különböző „teszteket” valósítunk meg. A tesztekhez szükséges kérdéseket és válaszokat az Alapítvány tölti fel. 4.12.2. Teszt adatok Kétféle teszttípust határozunk meg: az elsőnél automatikusan történik az értékelés, a második típusnál az értékelés személyi beavatkozást igényel. Egy kérdés tartalmazhat szöveget vagy képet, a kérdést szerkesztőnek egy cikk szerkesztővel azonos tulajdonságokkal kell bírnia, kiegészítve azzal, hogy a kérdések sorrendjét tetszőlegesen lehessen állítani. Az alábbi válasz típusok lehetségesek: Kérdés típus
Lehetséges válaszok
Automatikus értékelés
Eldöntendő
Igaz / Hamis
X
Kiválasztós
Többféle válasz (szöveg/kép)
X
Kifejtős
Szöveg mező
X
Dokumentum feltöltés
Bármilyen file
X
Emberi értékelés
4.12.3. Kiértékelés Amennyiben csak „automatikusan értékelhető” választ tartalmaz egy teszt, a pontszámot a kérdések feltöltésénél definiált válasz pontszámokból számoljuk ki összeadással. Amennyiben a kiértékelés emberi beavatkozást igényel, a Teszt értékelő felhasználói jogosultsággal rendelkező személy fogja értékelni. 4.12.4. Értesítés A tesztek kitöltése után a kitöltő személy megnézheti eredményeket, amennyiben automatikusan értékelhető a teszt. Ezeket adatbázisban tároljuk, valamit regisztrált felhasználóként e-mailben értesítést kap róla. Amennyiben emberi beavatkozást igényel a teszt kiértékelése, egy „Hamarosan értesítjük az eredményről.” üzenetet kap a felhasználó. A teszt kiértékelése után a rendszer a felhasználó választható beállításainak megfelelő email és/vagy belső üzenetet küld a kiértékelés tényéről. Ezek után a felhasználó megtekintheti az eredményeit. 4.13. Online tanácsadás Az online tanácsadás modul feladata a rendszerben a felhasználókkal való kapcsolattartás egyik aspektusának megvalósítása. Célja bizonyos fokú interaktiviás megvalósítása, ezt feladata szerint két lépésben érheti el. A kommunikáció két módon valósulhat meg: lehet bizalmas, privát jellegű kérdést, kérést intézni az O.K. Központhoz, vagy a felhasználó jelezheti azt is, hogy publikus kérdést tesz fel. Erre minden esetben fel kell hívni a figyelmét, legyen szó akár interaktív chat, akár írásos, fórum jellegű kérdésfeltevésről. Első megközelítésben a kapcsolat kétirányú és teljes mértékben valós időben, online zajlik, chat jelleggel. Ehhez megfelelő eszköz a Skype használata, egy "Skype Me" gomb beépítése a rendszerbe, vagy más, ehhez hasonló megoldás használata. Javasolt elhelyezés a kapcsolat oldalon, ahol az elérhetőségek és a kapcsolati információk mellett a kapcsolatfelvételi űrlap mellett lehetőség kell legyen interakcióba lépni a megfelelő kirendelt operátorral is, amennyiben a munkaállomás előtt tartózkodik. Ez a funkció munkaidőben, 9-17 óra között elérhető, amennyiben ezen kívüli időpontról beszélünk, a következő munkanapon üzenetként megjelenik. Ebben az esetben a felhasználó miután kapcsolatba lépett az operátorral, minden esetben először meg kell kapja a publicitásra vonatkozó kérdést. A kérdés kezelése ennek megfelelően történik a továbbiakban. Chat kapcsolat esetén is a beszélgetéseket jogi okokból minden esetben tárolni kell, a logokat lementeni és kézzel feltölteni a CRM rendszerbe. Ennek tényére is fel kell hívni a felhasználók figyelmét, ezt elegendő lehet a Felhasználási feltételek, és/vagy az Adatkezelési tájékoztató ide vonatkozó részében megtenni. Adatfeldolgozási és statisztikai szempontból fontos lehet, hogy a beszélgetést valamilyen módon a rendszerben később kötni kell a rendszer egy regisztrált felhasználójához, vagy meg kell jelölni, hogy külső, nem ismert tagtól érkezett, amennyiben ennek a ténynek a megállapítására lehetőség van. Ugyanezen kommunikációs metódus másik megközelítése egy fokkal kevésbé interaktív, azonban a napi rutinmunka szempontjából jobban ütemezhető és automatizálható. Itt a kérdést a felhasználó egy űrlap segítségével teheti fel, ahol adatainak megadása után (bejelentkezés után ezen adatokat már ismerjük,
automatikusan kitölthető a legtöbb mező) a kérdés bekerül a CRM rendszerbe, és feldolgozásra kerül a hozzárendelt operátor által. A rendszer a felvett adatokat automatikusan továbbítja a kezelőnek, aki megválaszolja azt. A felhasználó értesítést az online felületen és/vagy emailben kap, esetleg általa kiválasztható módon. A kérdés és válasz minden esetben archiválásra kerül a CRM rendszerben, és a felvetés időpontjában meghatározott publicitás alapján láthatóvá válik akár mások számára is. Idővel így egyfajta tudásbázis építhető a felhasználók aktív közreműködésével az őket érintő és érdeklő legfontosabb kérdésekből. Kiemelnénk, hogy ezzel a módszerrel csak a rendszer regisztrált felhasználói tehetnek fel kérdéseket, így a követés és egyénhez-csoporthoz kötés egy lépésben és egyszerűen megvalósulhat. Összességében azt mondhatjuk, hogy az online tanácsadási modul egyfajta fórumként működik, ahol a regisztrált felhasználó kérdést tehet fel az Alapítvány tanácsadóinak. A kérdező eldöntheti, hogy személyes (e-mail-ben) vagy nyilvános (a fórumon) választ akar kapni a kérdésének függvényében. Személyes kérdés esetén a kommunikáció privát, publikus esetén azonban archív formában megjelenik a kérdés és a válasz is a publikus felületen thread szerűen akár több mélységű kérdés-válaszok formában. A CRM oldaláról minden kérdés és válasz kezelhető-kereshető kell legyen. Az online írásos kommunikáción felül a videokommunikációra alkalmas, kamerás, „Skype me” gomb integrációra is szükség van, ennek a funkciónak azonban ki-bekapcsolhatónak kell lennie. A feltett kérdéseket célszerű a jobb átláthatóság és kezelhetőség miatt csoportokba, témakörök köré szervezni. Ezek struktúrája egyelőre pontosan nem ismert, a rendszernek lehetőséget kell adnia a teljes tartalmi bázis kezelésére, elemek mozgatására, csoportokba szervezésére. Egy-egy kérdést ki kell tudni emelni a megjelenítés során, a publikus felületen ezen felül kereshetőnek kell lennie a teljes publikus tartalomnak mind csoport mind pedig szabad szavas keresési módszerrel. Az ide vonatkozó tartalmi és funkcionális készségek nagyjából megfeleltethetőek a file- és médiakezelés logikai leírásával, csoportosítási lehetőségeinek. (Létrehozás, törlés, kiemelés, tagelés, stb.). Egy-egy kérdéssel kapcsolatban a felhasználó és a kezelő addig tud kommunikálni, amíg a thread lezárásra nem kerül. Ez történhet manuálisan, vagy lezáratlan threadek esetén a kezelő/üzemeltető egyidejű értesítése mellett automatikusan megadott inaktivitási idő után. Ez a gyakorlatban annyit jelent, hogy nyitva kell hagyni a kommunikáció lehetőségét a felhasználók számára, azonban ha egy kérdésre egyértelmű választ adtunk, akkor oda már ne tegyenek fel újabb kérdést, mert elsikkadhat, ezeket a szálakat a rendszernek el kell tudnia varrni. A törlés és thread lezárás funkció nem okozhat végleges törlést, ahogyan a rendszer más moduljainál, itt sem valósít meg fizikai törlést, csak elrejti az elérhető adatok közül a felületről a kívánt tartalmat. Egyes elemek, de akár tartalmi csoportok (teljes könyvtárak) is elrejthetőek. Talán kézenfekvő az ötlet, hogy a törölni kívánt elemeket egy "Kuka" szerű, nem látható csoportba(könyvtárba) helyezzük, ahonnan azok igény esetén visszaállíthatóak eredeti helyükre. 4.14. Multimédia 4.14.1. Képtár Képgaléria rendszer fa-struktúra kiépítésben, rendszerezetten, tetszőleges mélységű kategorizálhatósági lehetőséggel. Szükség van tömeges feltöltési lehetőségre
automatikus képméretezéssel. A szerkesztőségi rendszernek tudnia kell, hogy bármelyik tartalmi elembe (cikk, aloldal, blog, stb.) egy galériát be lehessen fűzni, előre kiválasztott nyitóképpel. Egy adott galériánál vagy galéria kategóriánál szükség lesz jelszavas vagy felhasználói csoportos hozzáférési szűrésre is. 4.14.2. Videótár Videótár rendszer fa-struktúraszerű kiépítésben, tetszőleges alkategorizálhatósági lehetőséggel. Szükség van tömeges feltöltési lehetőségre automatikus konvertálással megadott videotípus formátumokba. Ezek várhatóan AVI, x264 formátumok lesznek, pontos meghatározásuk később történik. A szerkesztőségi rendszernek tudnia kell, hogy bármelyik tartalmi elembe (cikk, aloldal, blog, stb.) egy vagy akár több videót be lehessen fűzni. Egy adott videónál vagy kategóriánál szükség lesz jelszavas vagy felhasználói csoportos hozzáférési szűrésre is. 4.14.3. Belső elemzésre szánt adatbázisok Tipikusan statikus dokumentumok, amelyeket csak bizonyos felhasználói csoportok láthatnak. 4.14.4. Egyéb Olyan letölthető eszközök is megtalálhatók a portálon, melyek a témakörökhöz kapcsolódóan nyújtanak tájékozódási lehetőséget, illetve segítséget. 4.15. Blog Az oldalhoz tetszőleges mennyiségű blog-ot kell tudni hozzárendelni, tipikusan egy központi és trénerenként, kiemelt munkatársanként egy-egy blogot. A blogok http://blog.okkozpont.hu/blogneve címen érhetők el és a tartalmi szerkesztéséhez csak blogger vagy afölötti felhasználói típus férhessen hozzá. A blogokban csak regisztrált felhasználók szólhatnak hozzá, minden egyes hozzászólásról a blog moderátor egy értesítést kap, amelyben elfogadja vagy megtiltja az adott hozzászólás megjelenését. Egy új blog bejegyzés elkészüléséről szintén értesítést kap a moderátor, amit szintén jóváhagy, vagy megtilt. 5. Kiegészítő elemek 5.1. Szavazás modul Szükséges egy olyan szavazó modul kialakítása, amely szabadon alakítható és hozzárendelhető a weboldalon megjelent tartalmakhoz (cikkek, tesztek, bejegyzések, stb.). Legyen lehetőség a szavazásnak lezárási határidőt szabni. A szavazás lezárása
után, opcionálisan, a regisztrált felhasználók e-mailben értesítést kapnak az eredményről, amennyiben ezt kérik és a szavazás szerkesztésénél beállították. Minimum elvárások a modullal kapcsolatban: Tetszőleges mennyiségű aktív szavazás lehetősége Tetszőleges számú válasz, akár szöveges és képes formában is Publikus felületen a szavazás állásának megtekintése Szavazás határidő beállításának lehetősége Szavazás lezárulásáról / eredményéről értesítést lehetősége a szavazóknak a belső üzenetküldő rendszeren Adott szavazás archiválása (publikus felületeken az eredmény sem látható) 5.2. Bannerek A nyitó- és aloldalakon, legalább 2-2 db, de legfeljebb 5-5 db banner helynek kell lennie, amelyek az adott oldal felületének maximum 10%-át foglalhatják el. A bannerek megjelenéseit a szerkesztőségi rendszerből kell állíthatóvá tenni. A bannerek standard IAB banner méreteket kell használjanak, erre a design során is figyelni kell. Ide vonatkozólag a következő oldal szolgál iránymutatásokkal: http://www.iab.net/guidelines
Egy banner helyre akár több különböző banner is tehető, beállítva a megjelenések súlyozását. Ezen felül be kell tudni állítani véletlenszerű megjelenést, vagy teljesen fix hozzárendelést is. Egy bannernek az alábbi paraméterekkel kell rendelkeznie: Megjelenés időpontja (-tól –ig / visszavonásig) Kattintások száma Megjelenés száma (véletlenszerű / súlyozott megjelenés esetén) 5.3. Közösségi média A portálnak rendelkeznie kell automatikus „posztolási funkcióval”, tipikusan a hírek, cikkek és galériák szerkesztésénél. Amennyiben a feltöltés során bekapcsoljuk, az előre beállított Alapítványi accountokra feltölt egy rövid, általunk meghatározott tartalmat a linkkel együtt. Ennek a modulnak meg kell valósítani legalább a Facebook, Twitter és G+ API idevonatkozó részeit és fenn kell tartani a lehetőséget a további bővítésre. 5.4. Statisztikák A méréséhez rendelkezésre álló eszközök: az Alapítvány szolgáltatásait igénybe vevők számáról vezetett statisztikai kimutatás a szolgáltatásokat igénybe vevők körében végzett felmérés a programok, szolgáltatások hatékonyságáról, informáló erejéről
a honlapot látogatók számának elemzése a regisztrált felhasználók száma
A kutatások eredményei az O.K. Központ honlapján online módon is elérhetők lesznek. 5.5. E-learning Az O.K. Központban és helyben, az iskolákban megtartott képzések oktatási tartalmai – a csatorna igényei alapján módosítva – a honlapon keresztül is elérhetők lesznek online, de nem letölthető verzióban. Ezeket az e-tananyagokat azonban csak a regisztrált felhasználók érhetik el. Ez a modul az Alapítvány meglévő e-learning rendszerének integrációjáról szól, a szoftver részletes specifikációjáról a http://docs.moodle.org/ címen lehet olvasni. Az integráció az alábbi feladatokból áll: A meglévő E-learning rendszer az elkészült arculathoz való igazítása CRM rendszerből történő autentikáció megvalósítása Az elvégzett tesztek, kurzusok visszajelzéseinek megvalósítása a CRM rendszerbe A meglévő rendszer lokalizációja
5.6. Hírlevél küldése A regisztrált felhasználóknak időközönként, akár előre időzített időpontban bekészített hírleveleket szeretnénk küldeni, akár az összes vagy csak felhasználói csoportra bontva. A hírleveleket és a kiküldésre jelölt felhasználói listát tárolni szükséges, a későbbi visszakereshetőség miatt. A hírlevelek tartalma HTML és szöveges alapú, HTML-re koncentrálva. Az arculati elemeknek a portálon való megjelenési módjához hasonlóan, a hírlevelekben egységes kinézetben kell megjelennie. Amennyiben HTML formában nem tudja megnyitni a hírlevelet, TEXT formátumban tartalmazzon egy linket, ami a portálon személyre szabottan megtekinthetővé teszi az emailt a felhasználó megfelelő azonosítása után. A hírlevél írásakor a portál szerkesztői felületein alkalmazott szerkesztő használat az elvárt, hiszen az funkcionalitásban megfelel az összes elvárásnak (képek, szövegek, formázás kezelése), valamint így egy komponenssel oldható meg egy újabb kívánt funkció. A hírlevelek címzettjeit a keresővel - akár komplexebb műveletek segítségével kiválasztva a listát menthetjük, valamit ehhez rendelhetünk egy új, vagy akár már egy megszerkesztett hírlevél tartalmat.
A tartalmakat menteni, szerkeszteni, átnevezni, törölni, másolni kell tudni, így ha egy hírlevelet újra kell küldeni, vagy csak kis mértékben módosítani, akkor ez a művelet egyszerűen elvégezhető. Az aktuális tartalom véglegesítése után a küldés a fentebb leírt módon egy időpont megadásával, vagy azonnali módon történhet. A hírlevél küldését ezek után a rendszer SMTP rétege veszi át, de a visszapattanó leveleket kezelnie kell IMAP/POP3 protokoll segítségével. Nagyságrendileg maximum 200-300 000 levél egyidejű kiküldésére kell számítani a méretezés és ütemezés során. A tervezésnél ezeket az irányszámokat kérjük figyelembe venni. A kézbesítésnek nem kell azonnalinak lenni, de egy hírlevél kiküldése nem lehet 24 óránál hosszabb idő. 6. Mobil applikáció A mobil applikációs fejlesztés célja Android és IOS platformon futó, mindkét platformon natív kóddal rendelkező applikáció létrehozása, mely a portál alábbi felhasználói funkcióit hiánytalanul, a portálon futó formában megvalósítja: Hírek megjelenítése Riportok megjelenítése Összes statikus aloldal megjelenítése, menükbe szervezve, strukturáltan Tesztek és kvízek kezelése Online tanácsadás (kérdés felvetése, és válasz megjelenítése egyaránt) Multimédia tár (böngészés) Közösségi hálózatok kezelése (postolás Facebookra, G+-ra) A mobil applikációban nem szükséges megjeleníteni semelyik modul felhasználóra vonatkozó történetét, erre a célra megfelel a portál oldala. Így nincs arra vonatkozó elvárás például, hogy a mobilon megjelenjen az "eddig kitöltött kvízeim", vagy hasonló funkció. A mobil applikációnak kezelnie kell a felhasználóknak vagy felhasználói csoportoknak küldött üzenetek megjelenítését is. Az üzenetek közvetítése ebben az esetben egyirányú, az olvasottság és az üzenetek kezelése a portállal közös alapon történik, tehát egyazon üzenet nem kerül kétszer kézbesítésre. Lehetőséget kell ugyanakkor biztosítani mobilexkluzív üzenetek közvetítésére, melyeket a CRM rendszerből leválogatott felhasználói csoport számára, csak a mobil applikáción keresztül jelenítünk meg. Az üzenet közvetítése itt is egyirányú, esetleges visszacsatolás egy webes linken keresztül lehetséges, például valamilyen akció esetén felhívhatjuk egy adott régióban élő felhasználók figyelmét, és erről mobilon keresztül értesülhetnek. ("Gyere a VOLT fesztiválra, megtalálhatóak vagyunk június 1-től 10-ig az OK sátornál!") Ez összekapcsolható feltételesen a geolokációs adatokkal is, idő validitási feltétellel. Az üzeneteknek mobil esetben is kell lehessen időbeni validitást adni, csakúgy, mint a normál üzenetek esetén, hiszen például a fesztivál végén már felesleges kézbesíteni azokaz. Lehetőség van a mobil applikációban esetlegesen a weboldal tartalmainak korlátozottabb, mobilra optimalizált formában történő közvetítésére is, ez azonban visszahat a rendszer tervezésének és fejlesztésének folyamataira, ezt figyelembe kell
venni például a médiakezelésnél, vagy a szöveges és képi tartalmak formázásánál. Itt a mobil készülékre optimalizált felbontásokra, formátumokra gondolunk, azaz a becsült látogatószám és forgalom miatt célszerű lehet megvalósítani már a feltöltéskor a megfelelő átalakításokat, így később ne valós idejű konverziókkal terheljük a rendszert, a feltöltött fileokból készüljön azonnal mobilra szánt változat is, amennyiben szükséges. Érdemes lehet figyelembe venni a sávszélesség, vagy a megjelenítő tulajdonságait ebből a szempontból. Az oldalak tartalmait egyszerűen kell tudni a közösségi megosztókra továbbítani, egyszerű lehetőséget kell biztosítani a felhasználók számára a kapcsolattartásra, és az információk megosztására ezeken a felületeken. Ez jelentheti a mobilos alkalmazás egyik igazi erejét, a megcélzott felhasználói kör ugyanis ideje túlnyomó részében pont erre a célra használja a készülékeket. Az applikációt forrás szinten fel kell készíteni a jövőben újabb, akár külső forrásból származó modulok fogadásának lehetőségére is. A dokumentációban a kapcsolódási pontokat, API-kat és a használt metódusokat egyértelműen szükséges megjelölni. Javasolt egy "teszt", vagy prototípus modul elkészítése, amiből a későbbiekben ki lehet a fejlesztés során indulni újabb CRM, vagy portálfunkció megvalósítása esetén. Az applikációban folytatott mindennemű tevékenységeknek meg kell jelennie a CRM rendszerben. Célszerű a mobil alkalmazást szintén direkt módon a CRM API-n keresztül meghajtani. A tárolni kívánt események kiemelt, de nem teljes köre a következő: Programfrissítések Felhasználó bejelentkezése Felhasználó kijelentkezése Tesztek, kvízek lekérdezése és a felhasználó arra adott válaszai Tanácsadási kommunikációs események Közösségi hálóra történő megosztások eseményei A jövőben kifejlesztett és a rendszerbe kapcsolt újabb modulok adatai A mérések során szét kell tudni választani a statisztikailag mérhető, releváns adatokat a látogatási adatoktól. Nem elegendő ilyen módon csak a kiszolgáló webszerver naplófileja alapján naplózni például az eseményeket, de ez is opcionálisan összevethető a CRM rendszerben a kimutatásokkal, mindenképpen hordozhat hasznos információt. A kiemelt, felhasználóhoz kötött eseményeket célszerű lehet a CRM API-n keresztül naplózni "Mobil adat" kiegészítő információ tárolásának segítségével, így adott esetben az is szűrhetővé és kezelhetővé válik, hogy mely típusú interaktív modult milyen felületen használják a felhasználók. Elvárás, hogy a mobil applikáció indításakor jelenjen meg az ÚSZT logó és EU zászló Európai Unió felirattal (lsd. ÚSZT Arculati kézikönyv). A mobil applikáció fejlesztésének tekintetében a portál kódolási irányelveit szükséges alkalmazni. A felhasznált komponensek, keretrendszer, külső modulok a lehető legfrissebb, forráskövetéssel és frissítéssel rendelkező modulok kell legyenek, törekedve arra, hogy a rendszer indulásának pillanatában minden kód a lehető leghatékonyabban legyen kezelhető, és a későbbiekben karban tartható, frissíthető. A fejlesztés folyamán a forráskódok tárolásának, közzétételének, illetve
dokumentálásának módja szintén megegyezik a portál részben tárgyalt verziókövetési és dokumentálási móddal és elvárásokkal. Figyelemmel kell lenni a mobil applikációs piacterek (Play Store illetve App Store) arra a sajátosságára is, hogy a bekerülés ideje a legjobb esetben is 3-4 hét a beadástól számítva az elbírálással együtt, ha nincs semmi probléma. Az alkalmazás fejlesztését úgy kell időzíteni, hogy annak a piactérre kerülése semmi esetre sem csúsztathatja hetekkel a teljes projekt befejezését. A teljes fejlesztési projekt befejezésének elengedhetetlen feltétele az alkalmazás elkészítésén felül a piactérre kikerülés, az alkalmazásnak onnan bárki számára elérhetőnek, letölthetőnek kell lennie a megadott határidőre. Statisztikai okokból a mobilalkalmazásnak szükséges a saját verziószámát és a futtató platform paramétereit a felhasználó által választható, adatvédelmi okokból akár anonim módon a rendszer felé közvetíteni. Lehetőséget kell a rendszerben biztosítani arra, hogy bizonyos minimális verzió alatt a mobil applikáció működése megszakítható legyen, esetleges programozási hibák, vagy adatstruktúra változások követése céljából. Ilyen esetekben az elvárt működés egy figyelmeztető ablak megjelenése, mely a felhasználót a mobil applikáció frissítésére kényszeríti, ezzel a hiba javítható, vagy éppen új funkcionalitás telepítése valósítható meg a rendszer integritásának sérülése nélkül. Az alkalmazásoknak a platformokon belül azok különböző variánsain egyaránt a platformnak megfelelő megjelenésben, zökkenőmentesen kell működnie, elterjedtsége miatt figyelembe kell venni a mobil platformok telefonos és tabletes változatait is. Az elvárt futtatókörnyezet minimum szoftververziói iOS esetén 6.0, Android esetén 4.0 verzióban kerülnek meghatározásra. Az ezektől eltérő, alacsonyabb operációs rendszerek verzióinak támogatása pozitívum lehet, de nem elvárt. 7. Fejlesztési szakaszok A nyertes ajánlattevő kiválasztása után, az alábbi szakaszokban kell a fejlesztésnek megvalósulnia. 7.1. Végleges rendszer terv és layout elkészítése A fejlesztő saját maga részére technikai specifikációt készít és ez alapján a végleges layoutot készít web és a mobil platformokhoz. Ezeket a layoutokat az Alapítványnak írásban jóvá kell hagynia. Teljesítési határidő: a szerződés aláírásától számított maximum 28. nap (4 hét). 7.2. Fejlesztés, fejlesztés nyomonkövetése Az elkészült specifikáció és a layout alapján megkezdődik a portál fejlesztése. A fejlesztés folyamán lehetőséget kell biztosítani az Alapítványnak a folyamatok ellenőrzésére és az esetleges hibák jelzésére. A fázisok, folyamatok naplózása, folyamatos követése érdekében a fejlesztő verziókövető rendszert kell alkalmazzon a teljes fejlesztési folyamat során. A konkrét
verziókövető rendszer megválasztása a fejlesztő hatásköre, azonban ügyelni kell arra, hogy a projekteket és a forráskódok csoportjait a kezdetektől fogva úgy alakítsák ki, hogy azon a teljes fejlesztési folyamat során bármely időpontban szabadon telepíthetőek legyenek az Alapítvány rendszerére (GIT clone, SVN checkout, stb). Ezzel a rendszer tesztelése mind a fejlesztő, mind az Alapítvány számára folyamatában biztosítottá válik, egy-egy újabb komponens elkészítése esetén annak például tesztelésre az Alapítványhoz eljuttatása pár perc alatt megoldható. Teljesítési határidő: a szerződés aláírásától számított maximum 168. nap (24 hét). A mobil applikáció fejlesztése esetén a teljesítési határidő: a szerződés aláírásától számított maximum 210. nap (30 hét). A közösségi média fejlesztés teljesítési határideje: a szerződés aláírásától számított maximum 217. nap (31 hét). 7.3. Béta teszt A véglegesnek szánt rendszer telepítése az Alapítvány infrastruktúrájára, az Alapítvány informatikusainak közreműködésével, a specifikációban foglalt funkciók ellenőrzése, az esetleges hibák javítása. Teljesítési határidő: a szerződés aláírásától számított maximum 189. nap (27 hét). 7.4. Oktatás A portálrendszer szerkesztőségi rendszeréből és annak üzemeltetéséből tartott oktatás az Alapítvány munkatársainak, amelyben részletesen taglalják a szerkesztőségi felület funkcióit és működését. Teljesítési határidő: a szerződés aláírásától számított maximum 196. nap (28 hét). 7.5. Végleges verzió telepítése Az elfogadott, a béta tesztelésnél esetlegesen felmerült hibák javított, az Alapítvány által véglegesként jóváhagyott verziójának telepítése, a kész anyag élesítése. Teljesítési határidő: a szerződés aláírásától számított maximum 203. nap (29 hét). 7.6. Adatok offline átadása Az éles rendszer átadása után az alábbi anyagokat offline (pl. DVD, USB, stb.) formában is át kell adni: Teljes forráskód, titkosítás nélkül, főbb funkciók kommentekkel ellátva Részletes technikai és fejlesztési dokumentáció Részletes felhasználói dokumentáció a szerkesztőségi rendszer használatáról Részletes technikai dokumentáció – példa programokkal ellátva –, amely bemutatja a lehetséges új modul fejlesztésének menetét és követelményeit. Üzemeltetési dokumentáció
Az összes grafikai anyag, nyers (pl. PSD) formátumban Igazolás a szoftverek használati jogairól
Teljesítési határidő: a szerződés aláírásától számított maximum 224. nap (32 hét). 7.7. Nyomon követés, támogatás Az adatok offline átadását követően a nyertes ajánlattevőnek további 56 napon (8 hét) keresztül, vagyis a szerződés aláírásától számított 280. napig (40 hét) rendelkezésre kell állnia, támogatást kell nyújtania az elkészült portál és mobil applikáció üzemeltetéséhez, valamint fejlesztési erőforrást kell biztosítania az Alapítvány számára, amelyet a későbbiekben kialakuló, szigorúan a portálrendszerhez kapcsolódó új dolgok elkészítésére és integrálására fordít. A konkrét fejlesztési feladatok meghatározása a fejlesztés lezárultát követően, későbbi egyeztetés alapján történik. A rendelkezésre állást, támogatást és fejlesztést összesen 80 mérnökórában kell biztosítani a 8 hét alatt.
