Hip-hop megjelent a számítógép és megjelent a szoftver amely az önmagában halom vasat értékes eszközzé teszi.
A számítógépek fejlődésével együtt járt a szoftver fejlesztése is. Fejlesztő környezetek, eszközök és módszerek is egyre gyorsulva fejlődtek.
Hogy is zajlott ez le?
Ez a folyamatosan fejlődő operációs rendszerek, azokon nyújtott magasabb szintű szolgáltatások kultúrájának növekedését eredményezte a felhasználói interakciókból származó hatalmas mennyiségű adat gyűjtése, tárolása és feldolgozása és ehhez alkalmazkodás.
Az igény a mozgatórugó, amely megköveteli hogy egy-egy alkalmazás/program/szoftver ne évente változzon hanem képes legyen hetente megújulni.
Most ne is beszéljünk a biztonság, adatvédelem, BigData szorító kényszereiről mert az más jellegű aspektus felé kormányozna bennünket.
Hát a teremtés (számító gép létrehozása) után egyből jött a visszajelzés, hogy ez jó.
Hogy mire? Milyen módon? Mennyire? Miért? .. még nem volt világos a szegényes elinduláskor mutatott jellemzők, szegényesek és csak egy szűk csoportnak voltak elérhetőek.
Mint a gáton a repedés, megállíthatatlan elemi erővel utat törő fejlődés zajlott le, amelynél egymást ráncigálta előre a szoftver és hardver oldal.
És ennek szerintem a legfőbb tényezője, az volt hogy játszani is lehet vele.
Komoly számítások, tudományos kutatás támogatása, kukafolyamatom integrálása és támogatása mellet a szórakozásba beintegrálódása lett az igazi húzó tényező.
Már nem is a számítógép volt a fontos, hanem a speciális vas és a program egysége ez bevonult a telefon, fényképezőgép, videó felvevő, ... de a mosógép és traktorok világába is.
Ezekkel az informatikai fejlesztésekkel működés közben figyelhettük meg Moore törvényét, amely azt állítja, hogy az egy mikrochipen található tranzisztorok száma 2 évente megduplázódik, bár a számítógépek ára megfeleződik.
Tehát rohanunk minden tekintetben hogy az igényeket kielégíthessünk és folyamatosan élményeket tudjunk nyújtani az ebbe beleszülető új nemzedékeknek is.
A fejlesztési igényeket előszór felmérték, ezek alapján specifikáltak, modelleztek, prototípust gyártottak, a kész programokat tovább fejlesztettek.
Most már programok próbálják kitalálni a trendeket és a leghatékonyabbak kielégíteni az elvárásokat.
A fejlesztési modell nem vízesés, nem agilis, nem DevOps, hanem AI (mesterséges intelligencia) ML (gépi tanulás) felhasználásával kialakított MLOps.
Az iteratív szoftverfejlesztési módszertanok lényege a rövid időszakonkénti release (kiadott verzió) előállítása. A helyesen alkalmazott Scrum esetében ez az időtartam néhány egymást követő fejlesztési sprintet jelent.
A gyakorlatban egy teljes iteráció, melynek a végeredménye egy kiadható verzió egy néhány hetes, esetleg néhány hónapos időintervallumot ölelhet fel.
A ciklikus demók következtében a fejlesztés során is közel stabil állapotú szoftvereket kapunk, melyek lehetőséget biztosítanak a folyamatos újra tervezésre, a gyors változtatásra, ami nagyon hasznos lehet minden alkalmazási területen.
A korszerű technológiák alkalmazása a szoftver fejlesztőket is új kihívások elé állítja. Ha a megrendelői oldalról plusz erőforrásnak tekinthető a szakértő beépítése a fejlesztő csapatba, akkor a fejlesztők oldaláról is extra energiaráfordítás az azonosított funkciókra, konkrét fejlesztési feladatokra vonatkozó automatizált tesztek elkészítése.
A vízesés módszerrel szemben az Agile megközelítés precíz és felhasználóközpontú valamint a módszer kétirányú és megpróbálja bevonja a végfelhasználókat vagy ügyfeleket a fejlesztési és tesztelési folyamatba, így részesekké válva lehetőségük van tesztelni, visszajelezni és javításokat kérni már a projekt fejlesztési korai folyamatában, mér akár az előkészítési fázisai során is.
Az újdonság az agilitásban a követelmény elemzését, apró feladatokra lebontását együttesen egyszerűen el tudják végezni, meghatározzák az új és megváltoztatandó használati eseteket, majd ezt követően változtathatnak a rendszer működését vezérlő/megvalósító kódján.
Ezen az úton a következő lépést a scrum szerint ez a product backlog, avagy termék-feladatlista, arról nem szól ez a módszertan, hogyan lehet ezt a feladatlistát elkészíteni.
A módszer hatékonysága azonban nagy mértékben függ a gyors visszajelzést adóktól és a specifikálást végzők hatékonyságától , majdnem egyfajta kutatási tevékenységgé válik egy adott sprint-re vonatkozó részletes specifikáció előállítása.
Mivel a témával kapcsolatos tárgyi tudás és az automatizált tesztkörnyezetben létező szoftver viselkedése, vizsgálata alapján elemzések kiértékelése szerint már konkrétan meghatározhatóak a követelmények a következő 1-2 sprintre.
Tehát komoly szakértelem és szaktudás kell amit tanulni kell, tehát tanuló modellt kell bevetni a hatékonyság folyamatos fenntartásáért. Ez a folyamatosan képzett kiértékelés és optimalizálást végző 'elme' nem is kell, hogy ember legyen.
Tehát a rendszeres sprinttervezések során az igény oldalról, a fejlesztők és tesztelők részéről nagyon hasznos és lényegi észrevételek hangozhatnak el az implementációval kapcsolatban, melyek a konkrét fejlesztési feladatok meghatározásánál fontosak lehetnek. Célok, prioritás, súlyozás folyamatosan változhatnak (kimeneti tényezők / elvárások)
A sprint tervezésben a cél az, hogy jól átgondolt alacsony szintű követelmények és megvalósítási tervek szülessenek, ám az itt feltárt összefüggések visszahathatnak a teljes követelményrendszerre is. Nem szabad elfelejteni, hogy a megoldások hatással lehetnek az egyes követelményekre vagy extrém esetben a teljes követelményrendszerre is.
Mi is valójában a gépi tanulás?
Hát nem csupán egy programkód ami egy feladatot elvégez, ennél azért több mert a kód és az adat kéz a kézben jár. Az adat alapvető fontosságú az ilyen modelleknél, főleg az adat frissessége megújulása teszi roppant hatékonnyá a kód mellet amely az adatot speciálisan kezeli úgy, hogy megoldási ötleteket nyerhetünk belőle.
A gépi tanulás forradalmi megközelítése nélkül eltérés indulhat ki abban, ahogy a kód és adat fejlődik, amely problémákat okozhat a tovább haladásban, megtorpanásokat, lassulásokat okozhat, és olyan nem várt, rossz eredményekhez vezet, amelyeket nehéz követni és reprodukálni.
A fejlesztési folyamatban is nagyon sok adat képződik amelyek emberi feldolgozással válnak információvá és döntéseken keresztül fejthetik ki javító hatásukat.
A fejlesztési folyamatban itt levőknek folyamatosan tanulniuk elemezniük és döntéseket kell hozni, hogy a legoptimálisabb fejlesztési eredmény jöjjön létre a fent említett folyamatosan változó igénykörben is. MLOps-nál ez nem kell, hogy ember legyen.
Megjegyzések
Megjegyzés küldése