Fejlesztési módszertan

Bevezetés

Az ÁAFK Fejlesztési módszertan az Állami Alkalmazás-fejlesztési Környezetben (a továbbiakban: ÁAFK) javasolt alkalmazástervezési, alkalmazásfejlesztési alapkövetelményeket ismerteti, amelyeket a Megrendelő szerveknek a beszerzés, tervezés, végrehajtás, átadás-átvétel során ajánlott megkövetelni a Fejlesztő szervezettől. A módszertan részletesen kifejti az architektúra tervezése és az alkalmazás fejlesztése során betartandó alapelveket, általános és IT szakmai szabályokat és technológiai elvárásokat a forráskódformázási, erőforrás méretezési szempontokra, teljesítmény és megbízhatósági skálázásra, illetve a terhelési megfontolásokra vonatkozóan.

Az ÁAFK-ban különböző típusú alkalmazások fejlesztése valósítható meg. Az ÁAFK kiemelten a cloud native architekturális elvek mentén fejlesztett alkalmazásokat támogatja, ezek esetében áll rendelkezésre a legtöbb szolgáltatás.

Általános elvárások

Az alábbi fejezet az alkalmazástól megkövetelt általános elvárásokat részletezi.

Az egyes fejlesztendő alkalmazásokra vonatkozó részletes követelményrendszert a jelen dokumentumban összeállított alapkövetelmények figyelembevételével készített megrendelői igény és a fejlesztési-szakmai követelmény- és szabályrendszer alkotja.

Funkcionális alkalmasság

Az alkalmazás (szoftverterméknek) olyan funkciókat biztosítson, amelyek teljes mértékben megfelelnek a megrendelői specifikációban meghatározott és az azokból eredő igényeknek.

Az alkalmazás (szoftverterméknek) szolgáltasson az igényeknek megfelelő eredményeket a megkívánt pontossággal és meg kell könnyítenie a specifikált feladatok elvégzését.

Teljesítményhatékonyság

Az alkalmazásnak hatékonyan, takarékosan kell használnia a futtató környezet erőforrásait, a nagyobb terhelések esetén azonban képesnek kell lennie a rendelkezésére álló erőforrások maximális kihasználására is (skálázhatóság).

Az adatbázistervezés általános alapelveinek betartása kiemelten fontos: normalizálás, funkcionális függőségek, a lehető legkisebb redundanciára törekvés (relációs adatbázis esetén).

Az alkalmazásnak meg kell felelnie a specifikációban meghatározott performancia elvárásoknak.

Az alkalmazás automatizált szkriptek segítségével legyen közvetlenül a forráskódból és a hivatkozott függőségeiből fordítható, tesztelhető és build-elhető. A hivatkozott függőségek forráskódját is az ÁAFK kódtárolójában kell elhelyezni az ÁAFK-ban build-elhető formában.

A hosszan futó műveletek legyenek külön modulba leválasztva, és aszinkron módon lecsatolva a felhasználói felületet kiszolgáló kódtól.

Kompatibilitás

Az alkalmazásnak hatékonyan kell ellátnia feladatát osztott erőforrású környezetben is anélkül, hogy káros hatással lenne az infrastruktúra többi elemére.

Az alkalmazásnak kliens oldalon platformfüggetlen technológia alkalmazásával kell készülnie és web alapú felhasználói felületen keresztül kell elérhetőnek lennie.

Az alkalmazásnak a kormányzati infrastruktúrába – előre nem tervezett, illetve indokolatlan infrastruktúrafejlesztés nélkül – integrálhatónak kell lennie, kiemelt elvárás a Megrendelő szervnél rendelkezésre álló üzemeltetői kompetenciával és kapacitással stabilan működtethető technológiák használata.

A kód komplexitását célszerű a lehető legalacsonyabb szinten tartani, a konkrét célt nem szolgáló, funkció nélküli összetett hierarchiák és függőségek kerülendők.

A kód nem tartalmazhat statikus hivatkozásokat, a működéshez szükséges valamennyi információ adatbázisban vagy konfigurációban tárolandó. (pl. IP címek, beégetett könyvtárhivatkozások, titkosítatlan jelszavak).

Használhatóság

• Felhasználóbarát megjelenés:

  1. A kezelése legyen ergonomikus, logikus, következetes, könnyen áttekinthető.
  2. A kezelőfelületek legyenek jól olvashatóak, az aktuális képernyő felbontáshoz igazodók (reszponzív).
  3. Magyar nyelvű felhasználói felülettel is rendelkezzen.
  4. A felhasználók számára is érthető (hiba)üzenetek.

• Felhasználóbarát működés:

  1. Kezelése legyen könnyen megtanulható.
  2. Törekedni kell a felhasználók által végzett műveletek egyszerűségére, a manuálisan végzendő műveletek minimalizálására.
  3. A rendszer kezelőfelületein olyan ellenőrzések, figyelmeztetések beépítése szükséges, amelyek lehetőség szerint védik a felhasználókat a nem szabályszerű vagy nem szándékosan végzett műveletek végrehajtásától.
  4. Gyors válaszidők.

• Felhasználóbarát dokumentáció:

  1. A rendszer valós működését leíró magyar nyelven is elérhető felhasználói dokumentáció.
  2. A felhasználók számára könnyen értelmezhető fogalmazás, az értelmezést segítő ábrák használata.
  3. Széleskörűen használt elektronikus formátum.

Megbízhatóság

• Az alkalmazásnak tartósan a specifikációban elvárt funkcionalitást és teljesítményt biztosítva kell működnie.

• Robosztus, stabil működés, széles körben használt technikák, technológiák alkalmazása.

• Magas rendelkezésre állást, skálázhatóságot biztosító környezetbe való illeszthetőség biztosítása.

Biztonság

• Az alkalmazásban biztosítani kell a kezelt, feldolgozott és a benne tárolt adatok védelmét.

• Biztosítani kell, hogy az adatokhoz csak az arra feljogosított személyek és rendszerek férhessenek hozzá.

• A hazai és Európai Uniós adatvédelmi, adatbiztonsági jogszabályokat, alapelveket nem sértő technikák alkalmazása.

• Naplózás (pl. biztonsági, felhasználói szokások, performancia):

  1. A naplózó funkcióknak célhoz kötöttnek, erőforrás-takarékosnak, továbbá könnyen visszakereshetőknek és értelmezhetőknek kell lenniük;
  2. Az adatkezeléssel járó felhasználói és egyéb tevékenységeknek minden esetben hitelesen naplózottnak kell lenniük a hamisíthatatlanság érdekében;
  3. Az adatkezeléssel járó tevékenységeket naplózó funkció nem lehet megkerülhető, kikapcsolható;
  4. A felhasználói szokások és a performancia naplózásának az üzemeltetési feladatokhoz is felhasználhatónak kell lennie. Az erőforrások takarékos használata érdekében célszerű, ha a működése ki/bekapcsolható;
  5. A naplóállományoknak önmagukban is menthetőnek, archiválhatónak kell lenniük.

• Címtárintegrált jogosultságkezelés.

• A jogosultságkezelő funkciónak alkalmasnak kell lennie az aktuális jogosultságok lekérdezésére, a jogosultságváltozások történeti visszakereshetőségére személyenként és jogosultságonként is.

• A jogosultságkezelésnek hamisíthatatlannak és megkerülhetetlennek kell lennie, biztosítania kell az egyes szerepkörök hozzáférési szintjeinek szétválaszthatóságát.

• Védelmi mechanizmusok kialakítása szükséges az alkalmazás sérülékenységi kockázatainak minimalizálása érdekében.

• Az alkalmazásba épített védelmi mechanizmusok által érzékelt támadásgyanús eseményeket is naplózni kell. (biztonsági naplóban) Az eseményről a naplózó funkción keresztül értesítést kell küldeni a kijelölt személynek.

• Az alkalmazás használata során minden esetben biztosítani kell az adatok integritását.

• Az adatkezelési műveletek után az adatok minden esetben konzisztens állapotban legyenek.

Karbantarthatóság

• A rendszert úgy kell kialakítani, hogy az könnyen javítható, módosítható, továbbfejleszthető legyen.

• A rendszermodulok tesztelhetők, újrafelhasználhatók, a fejlesztett kódok könnyen értelmezhetők, elemezhetők legyenek.

• Az alkalmazott technikák és technológiák semmilyen módon nem korlátozhatják a versenyt a későbbi módosításra, továbbfejlesztésre kiírt pályázat estén.

• A meghatározott kódformázási szabályoknak való megfelelés.

• A forráskód legyen egyszerű, áttekinthető, könnyen értelmezhető, ismétlődésektől mentes és könnyen karbantartható.

• Az egyes elemek szerepének, működésének megértését segítő megjegyzések használata.

• Egységes, egyértelmű névkonvenciók használata.

• SOLID alapelvek figyelembevétele.

• Széles körben elterjedt verziókezelő technológia használata. Az alkalmazás átadásakor a kiadott verzióhoz tartozó forráskódokat a verziókezelőből exportált állományként át kell adni.

• Csak olyan, széles körben elterjedt technológiák, keretrendszerek használhatók, amelyek bárki számára elérhetőek, nem kötődnek a fejlesztést végző céghez vagy annak érdekköréhez.

• Többrétegű architektúra (pl. üzleti logika réteg, perzisztencia réteg). A szükséges rétegek számát és funkcióját az egyes feladathoz igazítottan, többek közt a várható terhelés figyelembevételével, a robusztusság, skálázhatóság és a hatékony, gazdaságos üzemeltethetőség érdekében kell meghatározni.

• Preferált a perzisztens, állapotmentes üzleti logikai és prezentációs réteg kialakítása. Az alkalmazás üzleti logikáját megvalósító modul rugalmasan legyen skálázható, ne kelljen az alkalmazásspecifikus állapot szinkronizációt figyelembe venni a skálázás során.

• Moduláris felépítés

  1. A kialakított szoftverrendszer különálló, egymással csak a saját interfészükön kommunikáló, lazán csatolt modulok strukturált halmazaként legyen kialakítva.
  2. Az alkalmazás mikroszolgáltatás tervezési elvek mentén kerüljön kialakításra. A tervezés és fejlesztés során törekedni kell arra, hogy a rendszer egységbe zárt legyen.
  3. Az egyes rétegekben a funkciókat megvalósító rendszerkomponensek interfészeit dokumentált, biztonságos, uniformizált módon kell kialakítani. A modulok közti kölcsönös függőséget minimalizálni kell.
  4. A moduláris felépítés biztosítsa az alkalmazás hatékony továbbfejleszthetőségét, módosíthatóságát a meglévő modulok, kódok újrafelhasználhatóságát, újhasznosíthatóságát.
  5. Az alkalmazás kezelje, ha egy-egy modul átmenetileg nem elérhető. Ilyen helyzetben is részlegesen használható maradjon az alkalmazás.
  6. A különböző rétegekben futó szolgáltatások elérési paramétereit környezeti változókból töltse be az alkalmazás.

Hordozhatóság

• Olyan technológiák és technikák alkalmazásával kell az alkalmazást elkészíteni, amelyek minimális erőforrás ráfordítással lehetővé teszik, az alkalmazásátköltöztetését és működtetését egy másik infrastruktúra környezetbe.

• Nyílt forráskódú technológia elemek előnyben részesítése, alkalmazása.

• A kód nem tartalmazhat statikus hivatkozásokat (pl. IP cím, elérési út).

• A lehető legnagyobb mértékben automatizálni kell a telepítés és beállítás folyamatát.

• A telepítési, áttelepítési és az eltávolítási leírásnak aktuálisnak, részletesnek, folyamatszerűnek és követhetőnek kell lenni. Tartalmaznia kell a függőségeket és a várható kimeneteket.

Műszaki elvárások

A hatékony üzemeltethetőség, továbbfejleszthetőség, módosíthatóság szempontjait már az alkalmazás tervezési szakaszában figyelembe kell venni.

Leállítási jelzések kezelése

A fejlesztett alkalmazásnak kötelező kezelnie a leállításra utaló jelzéseket. A leállítási jelzés után új tranzakciókat kezdeni nem szabad, a nyitott kapcsolatokat, állapotokat le kell zárni vagy át kell adni más rendszereknek.

Állapotmentesség

Az alkalmazás működése legyen független az eltárolt állapottól.

Egy több példányban futó alkalmazásban egy konténer írhat adatot egy diszkre, de előfordulhat, hogy az egyik példány próbálja olvasni, míg egy másik írni az adatot. Kivételt képez a helyesen megvalósított gyorsítótárazás (cache-elés). Itt az alkalmazás olyan adatot tárol a diszken, melyet az bármikor elérhet vagy előállíthat. A fájlok csak hálózati vagy erőforrás-takarékosságot jelentenek, de hiányuk esetén az alkalmazás teljesen azonos kimenetet állít elő.

1. ábra: Példa állapotfüggő és állapotmentes rendszerekre

Funkció-jelzők használata

Az alkalmazás tartalmazzon funkció-jelzőket (feature flag) melyek be- és kikapcsolhatják a felhasználói funkciókat. A funkció-jelzőket az adminisztrátorok élesben használhatják, pl. problémakezelés során, korlátozások bevezetésére vagy diagnosztikai ellenőrzésekre.

A funkció-jelzők segítenek:

• a problémás funkciók kikapcsolásában, ha a funkció átmenetileg nem működik,
• a rendszer egészének üzemben tartásában,
• új funkciók bevezetését verziófrissítések után.

2. ábra: Felhasználók és funkció-jelzők kapcsolata

Ellenőrző HTTP kérések fogadása

Az alkalmazás válaszoljon az ellenőrző HTTP (HyperText Transfer Protocol) kérésekre valamelyik portján, akkor is, ha az alkalmazás jellemzően nem HTTP kérésekkel dolgozik. A kérést az üzemeltető környezet küldi, ezzel ellenőrizve azt, hogy az alkalmazás helyesen működik-e. Ha az hibásan működik, a környezet leállítja az alkalmazást, majd egy új példányt indít belőle, ahol megismétli a HTTP kérést a helyes működésről való meggyőződés érdekében.

Hálózati kiesés kezelése

Az alkalmazás kezelje a hálózati kapcsolat megszakadását. Az újracsatlakozáskor használjon olyan késleltetési módszert, amely kevésbé terheli meg a szolgáltatót a kapcsolat helyreállása esetén.

Dinamikus címzés

Az alkalmazás a külső szolgáltatásokat érje el dinamikus konfigurációként. Az alkalmazás a környezetleíró változóból olvassa ki és kapja meg a hosztneveket, IP címeket portokat, felhasználóneveket vagy jelszavakat. Ha változik a konfiguráció, a rendszer a régi példányokat leállítja és újakat indít el.

Adatok megfelelő védelme

Az alkalmazás fejlesztése során keletkeznek bizalmas adatok, mint pl. jelszavak, titkos kulcsok, tokenek. Az alkalmazás ezeket mindig szoftveresen hozza létre. Az alkalmazás tartsa az adatokat a környezetben, kerülje azok verziózását és használjon erős jelszavakat, vagy megfelelően komplex titkosítást.

Változáskezelés: adatbázis séma

Az alkalmazás tegye lehetővé a folyamatos működést verzióváltás során. Ha verzióváltás során változhat az adatbázisséma is, akkor vagy a korábbi verzió kezelje a mellékhatásokat, vagy az új verzió működjön helyesen, amíg a séma nem frissült. Ellenkező esetben nem lehetséges a gördülő frissítés (Rolling Update), csak a teljes leállás és elindítás. Ezek szolgáltatáskieséssel járnak és ellentétesek a modern fejlesztési irányvonalakkal.

Változáskezelés: verzióváltozások

Az alkalmazás fejlesztése és frissítése során szem előtt kell tartani, hogy a gördülő telepítés (Rolling Deployment) során egyszerre fut a régebbi és az újabb verzió az alkalmazásból, így az átmeneti állapot során vegyes szerkezetű adatok kerülhetnek rögzítésre. Ez jellemzően nem okoz problémát, ha a fejlesztés és frissítés folyamatosan zajlik, azonban intenzív fejlesztés és ritka frissítés mellett számottevő lehet a működési eltérés, és ennek következményeit, kockázatait a fejlesztő feladata kezelni.

Hálózati kapcsolatok időtartama

A fejlesztés során javasolt kerülni a hosszútávú hálózati kapcsolatokat, hiszen maga a kapcsolat egy logikai állapot, tárolást feltételez. Inkább a rövid HTTP alapú kérés-válasz kommunikáció a követendő, úgy, hogy a kliens sose feltételezheti, hogy ugyanaz a szerver válaszol az egymást követő kérdésekre (állapotmentesség).

Alkalmazástervezési ajánlások

Az alkalmazások tervezése során célszerű előre megtervezni a felhőalapú futtatási képességek biztosítását. Az alkalmazásokat három fő kategóriába lehet sorolni:

• nem felhő-kompatibilis,
• felhő-kompatibilis (cloud ready),
• felhő-orientált (cloud native).

Az alkalmazások felhőalapú futtatási képességére vonatkozó extra elvárások jellemzően mind olyan tervezési elvárások, amelyeknek történő megfelelés abban az esetben is igen hasznos, ha az alkalmazást végül nem felhőalapú környezetben működtetjük. Ezért az új fejlesztések során célszerű felhőorientált architektúra szerint felépíteni a rendszert, mivel ezek az elvek általában segítik a rugalmas és hibatűrő alkalmazás architektúra kialakítását. A felhőalapú alkalmazásokkal szemben támasztott fő követelményeket az alábbi alfejezetek mutatják be.

Rendelkezésre állás

Egy rendszer akkor áll rendelkezésre, ha az elérhető és működőképes. Jellemzően a teljes futási idő százalékos hányadaként mérik. Befolyásolhatják:

• rendszerhibák,
• infrastruktúra problémák,
• rosszindulatú támadások,
• terheltségi szintek.

A rendszerek jellemzően elvárt szolgáltatási szintek mentén üzemelnek, ezért a rendelkezésre állás mindig fontos szempont a tervezés során.

Adatok kezelése

Felhőalapú alkalmazások tervezése során az adatkezelés fontos szempont és sok minőségi jellemzőre van hatással. Az alkalmazás az adatokat jellemzően több helyen tárolja, különféle szervereken, mindezt teljesítmény, skálázási és rendelkezésre állási okokból. Ebből fakadóan számos kihívással kell szembenézni a tervezés során. Az alkalmazás biztosítsa az adatok konzisztenciáját és szinkronizálja azokat az egyes tárolási helyek között.

Tervezés és megvalósítás

Tervezés során figyelembe kell venni a rendszerkomponensek konzisztens és koherens működési elveit, a karbantarthatóságot, és az újrafelhasználhatóságot, ezáltal hatékonyabbá téve a leendő rendszer adminisztrációs és fejlesztési folyamatait. A tervezés és megvalósítás nagy hatással van a későbbi rendszer minőségére.

Üzenetek kezelése

A felhőalapú rendszerek üzenetalapú kommunikációs réteget használnak az egyes komponensek összekötésére. A komponensek lazán csatoltak a nagyobb léptékű skálázhatóság érdekében. Aszinkron kommunikáció használata esetén ajánlott figyelmet fordítani például az üzenetek sorrendjére vagy a hibás üzenetek kezelésére.

Menedzsment és monitorozás

Felhőalapú futtató környezetben az alkalmazások jellemzően magasabb szinten izolált környezetben futnak (pl. konténerben) és gyakran nem biztosított az alacsony szintű infrastruktúrához, vagy operációs rendszerhez való hozzáférés. Az alkalmazások tegyék közzé a futás idejű jellemzőket, paramétereket és ellenőrzéseket. Az adminisztrátorok és üzemeltetők ezeket nyomon követhetik, valamint ezeken keresztül irányíthatják a rendszer működését, illetve adott esetben paraméterezhetik, finomíthatják/optimalizálhatják a működését a rendszer leállítása vagy újratelepítése nélkül.

Teljesítmény és skálázás

A teljesítmény a rendszer válaszadási képességének adott időn belüli mértéke. A skálázás a rendszer azon képessége, hogy a teljesítmény romlása nélkül legyen képes kezelni nagyobb terheléseket, szükség esetén az erőforrások arányos növelése árán. A felhőalapú alkalmazások jellemzően hatékonyan működnek változó terhelési jellemzők mellett, és rugalmasan skálázódnak. A skálázás kapcsán nem csak a számítási kapacitásra kell tervezni, hanem adattárolásra, üzenetkezelési infrastruktúrára, illetve további hasonló alapvető erőforrásokra.

Rugalmasság

Egy rugalmas rendszer fennakadás nélkül kezeli a hibákat és helyreáll azokból. A rendszert úgy kell megtervezni, hogy különféle területeken fellépő átmeneti vagy állandó hibák esetén is minél rugalmasabban képes legyen ezekre reagálni, valamint lehetőség szerint a szolgáltatás minőségében bekövetkező csökkenés arányos legyen a hibával. A rugalmassághoz fontos a hibák mielőbbi pontos felismerése, és az azokból való helyreállás hatékony és gyors megvalósítása.

Biztonság

Egy biztonságos rendszer megelőzi a véletlen vagy szándékos károkozást, a rendszer nem rendeltetésszerű használatát. Az alkalmazásokat úgy kell megtervezni és beüzemelni, hogy biztosított legyen a rosszindulatú támadások elleni védelem. A rendszer csak az engedélyezett felhasználók számára legyen elérhető, és az adatok megfelelő védelmet élvezzenek.

Fejlesztési ajánlások

Az ÁAFK használatára vonatkozó szabályok nem tartalmaznak korlátozást a benne fejlesztett alkalmazások architektúráját illetően. Az alkalmazott technológiáktól és architektúrától függően eltérő módon vehetők igénybe a fent definiált fejlesztéstámogató eszközök. Az ÁAFK előnyben részesíti a modern felépítésű, jól üzemeltethető, fejleszthető és skálázható alkalmazásokat.

Az ÁAFK-ban biztosított futtatókörnyezet funkcionális tesztkörnyezet létrehozását teszi lehetővé. Ez a konténerklaszter-alapú futtatókörnyezet a modern, felhőalapú technológiákra épül, és emiatt megkövetel bizonyos iparági legjobb gyakorlatok szerinti működést, például:

• deklaratív infrastruktúra definíció létrehozását,
• SDN-alapú környezetből eredő megkötéseket,
• konténerek közötti minimum TCP alapú protokoll használatát (preferált a HTTP-alapú kommunikáció),
• konténerek állapotmentes használatát.

A fenti példák mellett figyelembe kell venni a futtatókörnyezet specifikumait is az alkalmazás tervezése, fejlesztése során. A Szolgáltató által közzétett tervezési és fejlesztési ajánlások elérhetőek az ORION tudásbázisban.