2. rész – Programozás az AI korában
Kérek egy sajtburgert, de nézzen ki BigMacnek…
Az első részben megnéztük, hogyan indul a projekt, most menjünk tovább!
Kérdések, megfigyelés, elemzés – specifikáció
A business analyst (vagy ebben a szerepkörben eljáró kolléga – az „elemző”) úgy dolgozik, hogy rengeteg kérdést tesz fel az ügyfélnek, ami segít neki tisztázni a megalkotandó szoftver tulajdonságait.
Ha van lehetősége rá, akkor kimegy a megrendelő telephelyére, megnézi, hogyan is zajlanak a folyamatok (de ehhez kell telephely és kell, hogy legyen valamilyen aktuális üzleti folyamat, aminek kiváltásán dolgozni fog a csapat. Tehát simán előfordulhat az is, hogy amit az ügyfél elképzelt az szuper, csak éppen a cége struktúrája/működése nem tart ott, hogy ez megvalósulhasson.).
A tevékenységének eredményét dokumentálja, amit nevezzünk specifikációnak.
A jó (teljes, ellentmondásmentes) specifikáció megalkotása nem egyszerű feladat, vannak, akik lehetetlennek tartják.
Ebből kifolyólag van olyan módszertan is, ahol nem tekintik ennyire lényegesnek a kész specifikáció létét, sokkal inkább történetmeséléshez hasonló módon rögzítik azt, hogy ki és mire fogja használni az adott rendszert (agilis módszertanok „user story”-ja), és akkor abból majd egyrészt minden résztvevő (ügyfél és fejlesztők) érti, hogy mire gondoltunk eredetileg, másrészt későbbre tolja a végső pontosítást. Az ilyen agilis fejlesztési módszertanok esetében rendszeresen bemutatjuk a készülő szoftvert a megrendelőnek, és így ő tud pontosítani, hogy mit szeretne, nem megyünk nagyon félre. Veszély ugyanakkor, hogy a kezdeti hiányzó pontosítás később mégiscsak visszaüt, és esetleg átsiklunk olyan követelményeken, ami alapjaiban megrengetheti mindazt, amit addig elkészítettünk.
Mint egy autónál: bemutatjuk a kombi Opelt, és elkezdünk az ügyféllel arról beszélni, hogy mekkora legyen a csomagtér. Erre az ügyfél elmondja, hogy 10 tonnát mindenképpen el kell bírnia. Ez lehet félreértés, abból a szempontból, hogy az ügyfél nem gondolta, hogy ez fontos információ lehet a legelején, vagy az is előfordulhat, hogy menet közben támadt új ötlete, csak nem gondolta, hogy ez alapjaiban befolyásolja az egész projektet. Ezért nagyon fontos, hogy feltegyük a megfelelő kérdéseket.
A specifikáció változik
Ritka az, hogy a specifikáció ne változna meg a fejlesztés folyamán:
- Egyrészt azért lehet módosulás, mert az elemző nem végzett tökéletes munkát – ellentmondások maradtak a specifikációban, esetleg részek hiányoznak. Mint mondtam, ez nehéz, könnyen előfordulnak hiányosságok.
- Másrészt azért is lehet, mert ahogy készül a rendszer – vagy akár már a kész rendszer láttán – a megrendelőnek „megjön az étvágya”, és újabb ötleteket dob be, álmodik meg.
A projekt nyereségessége szempontjából kardinális, hogy hogyan kezeljük a megváltozó specifikációt, az újonnan jött ügyféligényeket. Vannak apróságok, amiknek a bevezetése nem jelent jelentős időköltséget a csapatnak (valahol más szín vagy betűtípus használata), és vannak azok, amik teljesen egyértelműen látszik mindenki számára, hogy eredetileg szó sem volt egy funkcióról (pl. egy webshopnál eddig csak egyféle kártyás fizetési szolgáltató beépítéséről volt szó, de az ügyfél szeretne egy másodikat is), és van a kettő között a „szürke zóna”.
Nagyon ügyesen kell tárgyalni ezen helyzetekben, hogy ne legyen a végén az, hogy a csapat mindent megcsinál, amit a megrendelő álmodik, többszörösen túllépve az eredeti költségvetést, veszteséget okozva a fejlesztőcégnek. (Könnyen eljuthatunk a középkategóriás kombi Opeltől a fenti 400-zal száguldó kamion/busz hibridig – sokszor ugyanazon megbízási díj mellett). Több cégnél és projektben használták ennél a pontnál a CR (céer) rövidítést, ami kifejtve „change request”, arra az ügyféligényre, ami a korábbi megállapodás/szerződés módosítását igényli. És ezen felül extra költséget. „Ez belefér, ez meg CR!”
Ahhoz, hogy jó specifikáció készüljön, nagyon fontos, hogy átlássuk a rendszert és annak minden elemét. Az is nagy segítség lesz a projektmenedzsernek (vagy bárkinek, aki a specifikációt írja és az ügyféllel egyeztet), ha programozóként jó kérdéseket tudsz megfogalmazni és nem kezelsz semmit evidenciának. Arról nem beszélve, hogy ezzel a saját életedet is megkönnyíted hosszabb távon.
A fentiek miatt hatalmas kincs egy jó projektmenedzser vagy business analyst a csapatban! Nagyon fontos a munkájuk, hogy mind a megrendelő, mind a programozócsapat, boldog legyen és mindenki elégedetten rázhasson kezet a projekt végén.
Pályaváltóként lehet, hogy már rendelkezel is azokkal a tapasztalatokkal, skillekkel, amelyek ezekhez a szerepkörökhöz kellenek. Ha elkezdesz programozást tanulni, akkor ezáltal fejleszted az analitikus képességeidet (ráérzel, milyen kérdéseket kell feltenni, milyen alternatívák lehetségesek), és a részekből kész megoldást alkotó vénádat, valamint gyakorlod a tiszta, racionális, logikus gondolkodást, ami ilyen munkakört betöltve nagy áldás – a cégednek is és így neked is.
Egy projekt kivitelezéséhez sokféle tudás kell, így a programozáson kívül is akad bőven tennivaló, amihez azonban nagyon jól jönnek a programozói ismeretek.
Rendszerarchitektúra kialakítása
Az autók építésénél könnyebben érthető, hogy attól függően, hogy kamiont tervezünk vagy versenyautót, teljesen másképp kell elindulni már a projekt legelején. Az első pillanatban tudnunk kell már, hogy mi lesz nagyjából az autó. Azt nem kell tudni még ekkor, hogy milyen ívben jön majd a fényszóró, meg milyen audió-rendszer lesz benne hányas Bluetooth-szal, de azért azt, hogy busz, kamion, személyautó vagy sportautó, azt mindenképpen.
A szoftverek esetében is megvan ugyanez, rendszerarchitektúrának (vagy csak architektúrának) hívják. Az autókkal szemben az a nehéz, hogy míg azt, hogy „kerék” meg „ajtó” meg „teherbírás” a legtöbb ember ismeri, a szoftverprojekt architektúrájának az összetevői is meghaladják az átlagember tudását.
A rendszerarchitektúra kialakítása az architect dolga. (Jó esetben van rá külön ember, rosszabb esetben egy vagy több tapasztaltabb szoftverfejlesztő kolléga fogja ezt a feladatot elvégezni.)
Az informatikai rendszereknek számos aspektusa van, ami befolyásolja a kialakítandó architektúrát, itt most a teljesség igénye nélkül kettőt ragadok ki: a terhelést (load, traffic) és a rendelkezésreállást (availability).
A terhelés azt jelenti, hogy egy-egy másodperc alatt hány látogatót kell kiszolgálnunk, illetve, hogy mi az a látogatószám, aminek a kiszolgálására a rendszerünket szánjuk. Ha naponta van néhány kérés összesen, akkor azt még egy Raspberry Pi (egy kis kapacitású, kisméretű, olcsó, de közel teljes értékű számítógép – https://www.raspberrypi.org/) is ki tudja szolgálni az íróasztalunkra elhelyezve.
Ahogy egyre több a látogató, úgy kell mindenképpen komolyabb számítógépet beállítani, szerverszámítógépet üzemeltetni. És eljön az a pont, amikor búcsút kell mondanunk az egyszámítógépes rendszernek: egy számítógépnek már nem tud elegendően gyors lenni a processzora, hálózati kapcsolata, elegendően gyors és nagy lenni a memóriája, hogy az összes kérést ki tudja egymaga szolgálni. Itt jön az, hogy mindenképpen több számítógép kell nekünk, ami lehet saját üzemeltetésünkben lévő szerverpark, vagy lehet más valaki(k) számítógépe, azaz a cloud.
A rendelkezésreállás azt jelenti, hogy mit vállalunk vagy szeretnénk, hogy a rendszerünk elérhető legyen a felhasználók számára. Azaz egy időegység alatt (mondjuk egy év) mennyi idő az, amikor minden rendben és megfelelő sebességgel üzemel. A mértékegysége a %, a „minden oké” időszakok aránya a teljes időszakhoz képest. Átlagosnak mondható a 99,9%, ami azt jelenti, hogy egy év (8700 körüli óra) alatt 0,1%, azaz 8,7 óra a maximális kiesés.
Nagyon sarkalatos esetben lehet elegendő az, hogy a Raspberry Pi-t bekapcsoljuk akkor, amikor éppen az irodában vagyunk, és a rendszerünk elérhető arra a heti kb. 40 órára, amikor éppen dolgozunk, egyébként meg nem.
A legtöbb rendszertől azért ennél többet várunk 2024-ben: minimum az, hogy általában legyen elérhető, éjjel-nappal, de ha van egy-két napnyi kiesés vagy nehezebb működés, az még megfelelő. (Ilyenkor már mindenképpen egy állandó áram- és internetellátással ellátott gépről beszélünk, aminek lehet, hogy már egy megfelelően üzemeltetett adatközpontban van a jó helye, de még megfelelő az, ha valamelyik alkatrész meghibásodik, akkor addig leáll a rendszer, és ha megjavítottuk, akkor újraindítjuk).
Ha még nagyobb rendelkezésreállást szeretnénk, akkor már egyre kevésbé megengedhető, hogy bármilyen hardver- vagy akár szoftverhiba esetén megálljon a szolgáltatás. Ez pedig a rendszer felépítésére is hatással van: legyen több áramellátás, mert ha az egyik kiesik, akkor ott legyen a másik. Több internetkapcsolat több vezetéken, hogy ha elvágják az egyiket építkezés közben, akkor se legyen kiesés, legyen több számítógép, több adatbázis, és kb. mindenből több, hogy ne legyen egy olyan pontja sem a rendszernek, ami ha tönkremegy, bajban vagyunk, leáll a szolgáltatásunk (SPOF – single point of failure). Szélsőséges esetben a rendszerünknek azt is túl kell tudni élnie, ha az adatközpontot (az a speciális ingatlan, ahol a számítógépek dolgoznak megfelelő hűtés, áram- és internetellátás mellett) elöntötte az árvíz, és a szerverek (kiszolgáló számítógépek) másfél méteres vízben állnak, vagy lángokban áll az egész adatközpont. Hajmeresztő szélsőségnek tűnik, de mindkettő valós esemény volt a múltban.
Mindezzel csak azt akartam érzékeltetni, hogy az informatika világában is vannak olyan követelmények, amiket előre rögzíteni kell, mert meghatározzák az egész felépítést, és amit később már csak újraépítéssel lehet megváltoztatni. (Versenyautó legyen vagy mopedautó?). Az architektúra megválasztása pedig hatással van nemcsak a szoftver fejlesztési költségére, hanem a rendszert kiszolgáló hardverkörnyezet (infrastruktúra) beszerzési költségére is. Ha elég egy Raspberry Pi, akkor az 50.000 Ft lesz, ha pedig magunknak építünk több kis méretű adatközpontot, akkor az pedig sokmillió USA dollár.
Nagyon fontos, hogy tisztában legyünk a munka minden aspektusával, mint akár a terhelés vagy a rendelkezésreállás. Ha még a fogalmakat sem ismerjük, nem fogjuk tudni megkérni az AI-t sem arra, hogy vegye figyelembe ezt is a tervezésnél. Így ez az aspektus kimaradhat, és előfordulhat, hogy senki nem veszi észre, hogy egy Raspberry Pi-jal akarjuk kiszolgálni a következő parlamenti választás eredményközlését. Ahogy halad előre a világ, még a korábbiaknál is sokkal fontosabb lesz a mélyreható szakmai tudás, analitikus és kreatív gondolkodás.
Ezek kifejlesztésére pedig jelen pillanatban nem ismerek jobb megoldást, mint a programozás gyakorlását.
(Képek forrása: freepik, StudiCore, BingAI)
Olvasnál még tőlünk?
Iratkozz fel HÍRLEVELÜNKRE, így biztosan nem maradsz le a legújabb tartalmakról!
Kipróbálnád a programozást? Kipróbálnád magad?
Töltsd ki a tesztünket!
