Nem tudnak lépést tartani a szoftverfejlesztések a világgal

Új alkalmazások tömkelege kell a vállalatoknak

Napjainkban három releváns megatrend formálja a szoftverek fejlesztésének kereteit, amelyeknek közös jellemzője a gyors változás, véli Jan Zadak, a HP európai tevékenységéért felelős alelnöke. Az első, hogy az üzleti igények, feltételek szinte folyamatosan változnak, és gyors megoldásokat várnak el. A második, hogy a változások gyors ütemű kezelésében az IT kulcsszerepet játszik, beleértve a döntések, a hatékony üzletvitel támogatását, valamint az új elvárásokat kielégítő fejlesztéseket. Végezetül a változások harmadik pillére a weben felnőtt munkavállalók egy új generációja, amely a korábbinál sokkal fejlettebb kollaborációs igényeket támaszt informatikával szemben.

A világ más vezető informatikai szállítói is egyetértenek a HP-val abban, hogy ezek a trendek évek óta lényegében egy olyan vállalati modell létrejötte felé mutatnak, amelynek esszenciája az összes releváns üzleti információ folyamatos áramlása és szinte azonnali rendelkezésre állása, ahol a döntéseket a legfrissebb fejleményekre lehet alapozni, és azok hatása azonnal végigfut a vállalati idegrendszeren. A HP ezt instant-on vállalat névvel illeti, az IBM on-demandet mond évek óta, az SAP pedig nemrég kezdte el szajkózni a valós idejű cégek fogalmát.

Ennek megvalósításához azonban rengeteg új vagy módosított szoftverre, valamint a különböző szoftverek összeillesztésére van szükség, a régi, többnyire kisebb-nagyobb szigetcsoportonként működő alkalmazások nem alkalmasak arra, hogy hatékonyan cseréljenek információt. Napjaink egyik meghatározó, és az IT-vezetők fejében minden konferencián láthatóan hatalmas kérdőjeleket rajzoló újdonsága például az alkalmazottaknál lévő okostelefonok hadának lekezelése, azokat hogyan illesszék be a vállalati működésbe úgy, hogy a biztonság ne sérüljön. Az üzleti alkalmazások mobilizálódása egyértelműen a fejlesztések egyik fő fókuszát képezi a jövőben.

"Az összes ügyfél, akikkel beszélek, lecseréli a régi alkalmazásokat" - jelentette ki az idén Barcelonában megrendezett HP Software Universe konferencián Jonathan Rende, a HP BTO szoftverekért felelős alelnöke. Mint fogalmazott, a cégek versenyképességének szempontjából az alkalmazások egyre kritikusabbá válnak, de a fejlesztőcsapatok egyszerűen nem bírnak lépést tartani, mivel a régi módszerek és kódbázis visszafogja őket. "Ez nem azért van, mert a képességek nem elég jók, vagy mert az elemzők nem tudnak elég jó specifikációt előállítani. Ez azért van, mert mindenki silókban dolgozik" - jelentette ki Rende. Hozzátette, a fejlesztések kétharmada valamilyen formában nem teljesíti a célokat, vagy teljesen elbukik.

ALM 11: teljesen integrált projektmenedzsment

A válasz a HP, és mások, például a hazai Alvicom szerint is az úgynevezett agilis fejlesztési módszertanban keresendő, amely leginkább nem új technológiát vagy eszközöket takar, hanem egy újfajta megközelítést. A HP mint gyártó, ehhez természetesen új szoftvereket is el szeretne adni az új Application Lifecycle Management 11 (ALM 11) csomagban, amelyekkel állítása szerint nagyban csökkenthetőek a fejlesztési idők, a költségek, valamint magas fokon automatizálható a tesztelés, beleértve a biztonsági aspektusokat is. Az alkalmazások biztonsága kiemelten fontos egy olyan környezetben, ahol a klasszikus határvédelmi módszerek, mint például a tűzfalak vagy behatolásvédelem, nem alkalmazhatóak a határok elillanása miatt - gondoljunk a notebookokra, okostelefonokra, vagy a bárhonnan hozzáférhető webes felületű alkalmazásokra.

Az ALM 11 azzal az ígérettel érkezik, hogy felszámolja ezeket a silókat, és a szoftverfejlesztésben részt vevő összes érdekelt munkáját segít összehangolni. A vállalatoknál számos fejlesztői környezet megtalálható, minél nagyobb a cég, tipikusan annál többféle: Microsoft .NET, Java, SAP és Oracle fejlesztési csapatok, programozók, elemzők és tesztelők töredezik szét a cég belső projektjeit. A cél nem más, minthogy egységesített módszertan alapján folyjon a specifikálás, a fejlesztések nyomon követése, a funkcionális és teljesítménytesztelés, a biztonság garantálása. Az ALM 11 platformot ezzel a gondolattal bocsátotta útjára a HP.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

Az ALM 11 csomag a HP-eszközök, mint például a Quality Center korábbi kiadásaihoz képes számos fejlesztés és újdonságot vonultat fel, és a HP állítása szerint két év munkájának eredménye. A követelmény, teszt és hiba modulok még jobban összekapcsolódnak, és lényegében egy teljes, projektszemléletű fejlesztési menedzsment eszközkészletet bocsátanak rendelkezésre, kommentálta a bejelentést Sugár Ádám, az Alvicom vezető tanácsadója.

Jelentős újítás Sugár szerint, hogy a projektek módszertanának, mérföldköveinek kijelölése és nyomon követése mellett a követelményeket üzleti folyamatok importálásával lehet hierarchikusan generálni, a szoftver pedig igyekszik detektálni a kapcsolatokat, és megszüntetni a fejlesztési duplikációkat. A követelmények előállításában rich text editor és sablonok segítenek, valamint egy mátrix segít nyomon követni a teljesülést. Javult a fejlesztőkkel történő kommunikáció a követelményekben történő változások követés, és a forráskóddal történő összekötés révén.

A tanácsadó azonban úgy véli, a legfontosabb a Sprinter modul megjelenése, amely egy manuális tesztfuttató eszköz. A lényege, hogy a Quality Center (QC) elindítása nélkül lehet az ott meghatározott teszteket lefuttatni az alkalmazáson, amelynek folyamatát videóként vagy felvételsorozatként rögzíti a szoftver, ahogyan szkriptet is képes generálni a felhasználói aktivitásról, hogy azokat később futtatni lehessen tetszőleges számú gépen. A hibajelentés a körülményekkel és tesztlépéssekkel együtt visszakerül a QC-be, ahol a fejlesztők azonnal láthatják, és nekiállhatnak a hiba javításának. A HP az ALM 11-gyel számos tesztelésautomatizációs eszközt is ad a funkcionális és teljesítménytesztelés gyorsítása érdekében.

Az agilis fejlesztésé a jövő

Az Alvicom szintén az agilis fejlesztési megközelítés mellett tör pálcát, ha másért nem, akkor azért, mert a klasszikus fejlesztési projekteknek mindössze harmada sikeres. Magyarországon különösen igaz a nagyvállalati fejlesztésekre, hogy előre rögzített büdzsével, határidővel és specifikációval rendelkezik, ami Tanács Lajos fejlesztési igazgató szerint magában hordozza a későbbi problémákat. A projektbe ugyanis rengeteg bizonytalansági tényező épül be a becslések révén, előre kellene tudni megmondani, hogy adott célok elérésére mennyi időre és fejlesztési órára van szükség, miközben maguk a specifikációk is sokszor csak közelítőek, és az ügyfél sem képes pontos képet adni arról, mit szeretne látni. "Olyasmit alkotunk, amely előtte még sosem létezett, így kódolt a tévedés".

Ezt a feszültséget csak úgy lehet feloldani, ha kimondjuk, az ügyfélnek joga van változtatni a célokon, jelentette ki Tanács, aki szerint ehhez kölcsönös bizalmat kell táplálnia egymás felé a megrendelőnek és beszállítónak, túllépve azon, hogy előbbi szerint csak sok pénzt akarnak tőle kitalicskázni, utóbbi pedig a modern kizsákmányolót látja az ügyfélben, aki ugyanannyi pénzért egyre többet és többet akar.

Az agilis fejlesztési módszertanok alapvetése, hogy a projekt kis szeletekben, úgynevezett sprintekben halad előre, amelyek végén legalább részben funkcionálisan működő szoftvert prezentál a fejlesztőcsapat és az ügyfél elé. Egy-egy ilyen sprint tipikusan néhány hét hosszú, és a végén iteratívan módosítják a specifikációkat, valamint újrapriorizálják a célokat az ügyfél aktuális igényei alapján, mondta el Lakatos Attila, az Alvicom projektmenedzsere. A sprintek alatt is folyamatosan, a nightly buildeken fut a kód automatizált tesztelése, hogy kövessék a kód minőségét. Az Alvicom a scrum módszertan mellett tette le a voksát.

Lehetetlen, hogy a szoftver elsőre úgy nézzen ki vagy működjön, ahogyan az ügyfél elképzelte. "Az ügyfél először akkor érti meg, mit kért, amikor látja", és az agilis megközelítés ezt az időpontot hozza előre, fogalmazott Tanács. Lakatos hozzátette, hogy minél későbbi időpontban történik változtatás, vagy fedeznek fel hibát, annál többe kerül a javítás, akár nagyságrendekkel, így az iteratív megközelítés, valamint a folyamatos minőségellenőrzés rendkívül fontos.

Cserébe az ügyfélnek is el kell fogadnia, hogy egyes, alacsonyabb prioritású képességek nem készülnek el határidőre, esetleg kiderül, nem férnek bele a büdzsébe, ugyanakkor sokkal nagyobb biztonsággal kap használható szoftvert a kijelölt időpontban. Kétségtelen, hogy a vállalatok többségénél ez ma problémába ütközik, mert ha a fejlesztésekért felelős vezetők el is fogadják ezt, a beszerzési osztályon ezt még akkor is keresztül kell nyomni.

Az Alvicom maga is a scrum módszertan alkalmazása mellett tette le a voksát, és így készítette el például új, Automatizált Portarendszerét, amely termelőipari vagy logisztikai cégek számára kínál magas fokon automatizált szállítmányozási nyilvántartást a teherautók forgalmáról. Tanács úgy gondolja, a fejlesztő vagy projektmenedzsment eszközök kiválasztásánál is sokkal fontosabb a szabályok, elvek betartása, akár Excellel is lehetne projektet vezetni.

Arra a kérdésre, hogy hatékonyságban, produktivitásban számszerűsíthető-e az agilis fejlesztési módszertanok hatása, Tanács úgy felelt, hogy tapasztalatai szerint rengeteg vitától és adminisztratív tehertől lehet megszabadulni, ha a felek kölcsönösen elfogadják a specifikációk rugalmas alakíthatóságát. Mivel a megközelítés iteratív, ezért a kezdeti követelmények meghatározása sem rejt olyan jelentős kockázatokat mint korábban, ezért sokkal kevesebb időt kell a kidolgozásukra, véglegesítésükre is fordítani. A projekt teljes időtartamára vetítve így drasztikusan lecsökken a nem produktív, tehát nem a fejlesztésre, tesztelésre vagy bevezetésre fordított idő, a projekt felgyorsul, miközben a sikerráta is megnövekszik.