Az e-ticket fejlesztés margójára

LEHETETLEN KÜLDETÉS?

Az elmúlt hetekben/hónapokban a különböző fórumokon és cikkekben az emberek ízekre szedtek egy hazai fejlesztésű online jegy rendszer hibáit (teljesen jogosan). A fejlesztő cég elsődleges mentsége a rendszer implementálására adott határidő rövidsége volt (3 hónap), ami szakmai szemmel nézve bizony egy szoros menetrendet követel meg. A feladatot objektíven megvizsgálva, valóban lehetetlen 3 hónap alatt egy jól működő és biztonságos e-ticket rendszert szállítani?

HOGY ÉRDEMES CSINÁLNI?

Tehát a feladat adott, egy online jegy értékesítési platform fejlesztése a (feltehetően) pontosan dokumentált megrendelői igények alapján.

A tervezési fázis egy fontos szakasza a kivitelezésnek – a megfelelő technológiák és program komponensek elméleti összeállítása. Mivel az e-ticket rendszer esetén nem egy speciális feladatról van szó, hanem egy legalább százezres nagyságrendben már implementált szolgáltatás fajtáról, a rendelkezésre álló tervezési minták és komponensek kiforrottak és megbízhatóak. Persze ezek használata mellett nem árt tisztában lenni a leggyakoribb kiber sebezhetőségek kivédéseivel sem.

Ilyen szoros határidő mellett érdemes az agilis projekt menedzsment felé elmozdulni a hagyományos vízesés modell helyett, azaz kis lépésekben, többszöri iteráció alatt kifejleszteni és tökéletesíteni a kért funkcionalitást, amit minden iterációval véleményezhet az ügyfél, tehát már nagyon hamar van egy részlegesen működő szolgáltatás, aminek a tökéletesítésére több fejlesztési-tesztelési ciklus is a rendelkezésre áll.

A szoftver minőségét hogyan lehet a legjobban mérni? Véleményem szerint az éles környezetbe kikerült hibák száma erre egy jó mérőszám. Manapság az automatizált tesztelés és a környezetek közötti verzió promótálással (Continuous Delivery) a hibák jelentős részét még az éles környezet előtt kiszűrhetjük. A tesztek megírása és karbantartása természetesen plusz időként jelenik meg a projekt tervben, ami azonban értékes hiba javítási időtől (és a bizalom elvesztésétől) menti meg a szolgáltató céget.

Ne feledkezzünk az alkalmazás platform összeállításásról, és az azokat támogatási munkákról sem, ami a webes rendszer mellett a mobil platformok széleskörű tesztelhetőségére is ki kell, hogy terjedjen. Ez önerőből megint egy nagy feladat lehet, azonban a publikus felhő szolgáltatók mára a hasonló fejlesztési projektek teljes életciklusát támogatják.

Ez azt jelenti, hogy egy standard alkalmazás platform, például egy Java EE alkalmazásnak, cirka 10 perc alatt rendelkezésre állhat a manapság népszerű adatbázis kezelőkkel, terheléselosztókkal, caching és számos egyéb megoldásokkal. A könnyen duplikálható rendszerek a tesztelésnél hatalmas előnyt jelentenek, hiszen olcsón, több párhuzamosan futó, az éles rendszerrel megegyező teszt rendszert futtathatunk különféle tesztelési metódusoknak, ezáltal mire a rendszerünk a végfelhasználókhoz jut, már tisztában vagyunk a maximális terhelhetőségével és potenciális sebezhetőségeivel.

Az automatikus teszteléshez szükséges teljes fejlesztői eszközök elindítása az alkalmazás platformhoz hasonlóan 10 percekben mérhető. Az eszközök hatékonyan támogatják a verzió követést, automatikus tesztelést és kód minőség mérést, tehát az esetleges hibák még a korai szakaszokban felfedezését.

Mobil platform integráció és teszteléshez automatizált tesztek indíthatók az elmúlt 4-5 év népszerű telefon típusaihoz, amivel a felhasználók telefon készülékeinek zömét lefedhetjük.

Végül, mivel egy jó tervezés az adat begyűjtés, feldolgozás és analitikát sem hagyja figyelmen kívül mint távlati célt, az elérhető Big Data szolgáltatások színvonala és rendelkezésre állása is egyértelmű előnyt jelent a publikus felhő szolgáltatások választásakor.

MI MARADT HÁTRA?

Tehát a fenti módszertanok és szolgáltatások megfelelő alkalmazása után mi maradt a projekt feladataiból?

• Tesztek megtervezése és megírása
• A tesztek alapján a funkcionalitás folyamatos, iteratív implementálása.
• A megfelelő szoftver komponensek integrálása az alkalmazásunkba
• Funkcionális, performancia, stress stb. tesztelés
• Változások éles rendszerbe promótálása, majd újabb iterációja a fenti lépéseknek

Jobban, rövidebb idő alatt