Alkalmazás életciklus-kezelés Ker-Soft Módra, IBM Eszközökkel

Az IBM Magyarország és a Ker-Soft Számítástechnikai Kft. 2013. március 21.-én tartotta Alkalmazás életciklus-kezelés c. szakmai szemináriumát, ahol áttekintést adtak az IBM Rational termékcsaládról, s a benne rejlő lehetőségekről.

Az IBM Rational az üzleti igények világának szoftverfejlesztési környezete. Vezető piackutató cégek szerint az IBM vonatkozó eszközei piacvezetők az alkalmazásfejlesztés teljes életciklusának kezelésében, a követelmények összegyűjtésétől, a kódoláson keresztül egészen a tesztelésig. Az IBM teljes körű fejlesztési környezetet kínál a vállalatoknak az üzleti folyamataik integrálásához cégen belül és ügyfeleiknél egyaránt.

Dr.Vinkovits Eszter, a Ker-Soft cégvezetője utalt rá, rendezvény keretében először foglalkoznak IBM témával,

az életciklus kezelés témaköre pedig rendkívül kiterjedt, így néhány fontosnak tartott részre összpontosítanak.

A mai gazdasági környezetben nagyon fontos, hogy a fejlesztések során kitűzött célokat gazdaságosan, gyorsan, a kockázatok csökkentésével tudjuk elérni. A megvalósítás során a csoportmunka szervezéséhez meg kell találni a megfelelő eszközöket. Az igény felmerülésétől kezdve, a fejlesztésen keresztül, az üzembe helyezéshez, sőt az üzemeltetéshez is a csoportok együttműködése, „kollaborálása" szükséges, ennek eszközei az IBM Rational eszköztárában megtalálhatók.

Nyikes Tamás, a Ker-Soft értékesítési vezetője az alkalmazás-életciklus menedzsment (Application Lifecycle Management, ALM) témakör alapjairól szólt előadásában. A Magyarországon kevéssé ismert ALM fogalma 2005-ben jött létre. Világszerte sokan használták már.

Az ALM fogalmát tisztázandó, tudnunk kell, az alkalmazások fejlesztése nem csak a kódolásból és a hozzá szorosan kapcsolódó dolgokból áll, hanem egyéb összetevőkből is. Általánosságban, minden projektre igaz, hogy a követelmények összegyűjtése az egyik legfontosabb teendő. Ezeket fejben is összegyűjthetjük, vagy papíron átadhatjuk, erre ma nincs szabványos követelmény-rendszer, strukturálatlan adatok halmazaként állanak rendelkezésre, ezért kezelésük nem egyszerű. Az informatikában és általában a projekt-menedzsmentben elterjedt

a követelmény-specifikáció fogalma, ami egy részét jelenti a követelmény-kezelésnek. Fontos tehát, hogy tisztában legyünk az igényekkel, amelyek mindig az egyes szereplők, érdekeltek igényeként jelennek meg. Más lehet egy végfelhasználó és más egy szponzor igénye, aki az alkalmazást használni fogja. A követelmények összegyűjtésénél ezek fontos szempontok, a vezetők szintén megjelenhetnek szponzori szerepben, ezért a követelménykezelésnél már előjönnek a szerepek az adott ALM esetében, minden egyes projekt, minden folyamat esetében.

Ezt követően van szükség a tervezésre, dizájnra, ahol az architektura kialakítása történik.

A kódolásra az IBM eszköze (Eclipse) rendelkezésre áll.

A minőségmenedzsment és tesztelés korábban egymásból következő fizikai lépések voltak, ahol visszacsatolásokra kevéssé volt lehetőség. Ma, a minőségmenedzselés hangsúlyozásakor, ebben bennfoglaltatik a tesztelés is, tehát nem egyszerű tesztelésről van itt már szó. A minőségmenedzsment átfogja az egész ciklust, tehát akár az architektúra szinten, a követelménykezelés szinten is megjelenhet egyfajta minőségkezelés. Ez egy összetett, önmagába záródó kört jelent.

Az ALM területét tehát az üzletmenedzsment és a szoftverfejlesztés ötvözetének tekinthetjük, melynek főbb részterületei;

követelménykezelés,

architektúra,

kódolás, változás- és konfiguráció-kezelés,

minőségmenedzsment, tesztelés,

követés,

kiadáskezelés.

Az ALM piaci helyzetét a Forrester Research piackutató cég 2012-es októberi jelentése alapján tekinthetjük át. Eszerint; az ALM eredeti célja a folyamat-fejlesztés volt, felmerülnek itt bizonyos paradoxonok, mint az elhíresült Cobb féle projektmenedzsment paradoxon. Ennek lényege; hiába tudjuk, hogy a projekteket hogyan kell végigvinni, tehát van módszertanunk, hiába tudjuk, hogy egy adott projekt esetében melyek a felmerült gondok, amelyeket nem tudunk megoldani, elméletileg felkészültek vagyunk, tapasztalt gyakorlati embereink vannak, a (fejlesztési)projektek jelentős része mégis elhúzódik, késésben van, vagy 60%-a meg is hiúsul.

A projektmenedzsment másik paradoxona, amint a projekt a legkisebb mértékben is meginog, megcsúszik, felmerül a kérdés, mit tudunk tenni. A legtöbb esetben ilyenkor további erőforrásokat, pl. fejlesztési projektnél még további három fejlesztőt helyezünk ide, de ilyenkor általában a projekt tovább csúszik.

A fő mozgatóerők a piacon:

A szoftverszállítás és üzemeltetés az alkalmazásokhoz szorosan kapcsolódóan jelenik meg, mivel ma olyan alkalmazásokat fejlesztenek, amelyek nagyon komoly interaktivitást, nagyon gyors változásokat tartalmaznak és nagyon dinamikus infrastruktúrában helyezkednek el. A dinamikus, webes környezet a meghatározó, ezért a szállítás és üzemeltetés túlmegy azokon az alapfeladatokon, amelyekre pl. az üzemeltetési csapatok fel vannak készülve.

Az agilis módszertanok megtorpanásáról számol be a piackutató cég. Ez a módszertan nagyon divatos volt, mindenki megpróbálta mindenre alkalmazni, de nem mindig sikerrel. Számos olyan nagy fejlesztési projekt van,

elsősorban az államigazgatás, a szigorúan kontrollált fejlesztések terén, ahol az alkalmazásokba kerülő hibák életet veszélyeztethetnek, ilyen helyeken a hagyományos módszertant alkalmazzák továbbra is. Visszarendeződések is megfigyelhetők. A piac olyan szintre fog beállni, amelyben az agilis és a hagyományos módszertannak is megvan a maga helye.

A (szoftver)kiadás-kezelésre eddig külön eszközök szolgáltak, ma már ez a teljes életciklus menedzsment eszközök részeként jelenik meg. Az elsősorban az üzemeltetésről szóló ITIL-ben is nagyobb hangsúlyt kap. Az ITIL a „best practice" címen jegyzett legjobb gyakorlatok gyűjteménye. Nagyon elterjedt, a nagy cégek jelentős része ITIL alapon próbálja az üzemeltetését, a szolgáltatás menedzsmentet megszervezni. A szolgáltatások miatt kap nagyobb hangsúlyt az ITIL manapság. Az ALM területen kezd megjelenni az ITIL, s vele összefolyni. Ennek oka; sok esetben ma már nem csak alkalmazásokat fejlesztünk, hanem olyan szolgáltatás-elemeket, amelyekből majd alkalmazások állhatnak össze, egyre komolyabb az átfedés.

A fejlesztői együttműködés szintén mozgatórugóként hat, a piac jelzi idevágó igényét. Az alkalmazás-fejlesztés kompetenciává válik. Voltak olyan nézetek, hogy a polcról levehető, egyre kifinomultabb szoftvercsomagokkal minden feladat megoldható. A sztenderd funkciókra ez igaznak is bizonyul, de itt is van egy paradoxon, az un. 80/20-as szabály; azaz, a fenti gondolat igaz az alkalmazások 80%-ára, de a maradék 20% elkészítése a teljes munka 80%-át jelenti… A piaci verseny felgyorsult, a cégek nagyon csekély margókkal, résekkel tevékenykednek, ezért megkülönböztető kompetenciát jelent, ha valakinek sajátos fejlesztése van, ez az utóbbi öt évben vált hangsúlyossá. Az egyedi fejlesztések aránya nő. Ugyanakkor mélyül a szakadék az üzlet és a fejlesztők, valamint a fejlesztők és üzemeltetők között. Más-más nyelvet beszélnek. Gyakran előfordul, hogy az életciklus során a követelmények nincsenek jól megfogalmazva, a fejlesztők nem tudják pontosan, hogy az üzletnek mire van igénye, s amikor elkészül a produktum, akkor már nehéz változtatni rajta. Az un. szerelősor-modell, a lépésenkénti fejlesztés, majd a rákövetkező tesztelés módszere összeomlik. Ma már vissza-vissza záródó hurkok vannak, ezért ez nem működik.

Az egyetlen út a megoldásra az együttműködéses fejlesztés. Az egyedi eszközök már olyan szintre álltak be, hogy ott már további termelékenység növekedést már nem lehet elérni, viszont csapatmunkával hatékonyabb lehet a teljes szinergia, a csapatmunka hatékonyabb, mint az egyedi.

Költségcsökkentési és egyéb meggondolásokból a fejlesztést sok cég kirakta külső partnerekhez, ezen partnerek kezelése újabb kihívást jelent, az együttműködéses fejlesztés körébe viszont minden külső partnert besorolunk.

A szoftverszállítás bekerül az életciklusba, itt kerül elő az alkalmazás szimuláció. Ez arról szól, hogy webes alkalmazás esetében az alkalmazás milyen teljesítménnyel és funkcióval működik. Ezt úgy lehet ellenőrizni, ha

több szerveren, infrastruktúrán átfut a szóbanforgó alkalmazás, s ezek az infrastrukturális elemek dinamikusan változhatnak. Egy összteljesítmény mutató pl. úgy áll elő, hogy a különböző szerverek rendelkezésre állásától, vagy terhelésétől függ, hogy a végén a „tranzakció" milyen teljesítményt tud nyújtani. Ennek előzetes becslése az alkalmazás szimulációjával történhet. Összetett kérdés ez, s elsősorban a webes alkalmazások miatt van rá szükség. Ebből következik a tranzakció monitorozás, a rendszermenedzsment izgalmas, aktív területe.

A Forester jelentésből kitűnik, az ALM fejlesztő cégek palettájáról a platformok közül a mobil támogatás szinte teljesen hiányzik. El kell döntenünk, hogy a tranzakció monitorozást a fejlesztés részének tekintjük-e.

A szoftverfejlesztést minden platformra vonatkoztatnunk kell, beleértve a jelenleg hiányos mobil-platform támogatást is.

Magyarországon a szoftver-export a válság éveiben is folyamatosan nőtt, miközben a gazdaság minden további szektora csökkent. Szoftverekben Magyarország erős, ezen termékek kulcsszerepet játszhatnak a magyar gazdaságban, öt éven belül ez az export akár kétszeresre is nőhet, óriási lehetőségeket kínálva: http://hirlevel.egov.hu/2013/03/08/ot-even-belul-duplazodhatna-a-hazai-szoftver-export/

A Forester szerint az ALM újra-definiálódik, és újabb innovációk jelennek meg:

DevOps: fejlesztők+működtetők összeolvadása

Beágyazott szoftverek: egyre gyakrabban jelennek meg, nem csak az autóiparban,

Követelmény definíció: egyes elemek már szabványos formát is ölthetnek

Eszközök integrálása: kiforrott fejlesztések és felhő-fejlesztések összeillesztése nagy fontossággal bír, nincsenek rá szabványok

Jelentések és műszerfalak

Agilis támogatás

Felhőfejlesztés

A hatékony szoftverszállítás gátló tényezőit a különböző érdekcsoportok között kialakult „silók" jelentik, ezeket kell feloldani csapatmunkával, alkalmazás életciklus menedzsmenttel. Olyan környezetet kell biztosítani, amiben mindannyian részt tudnak venni különböző feladatokkal, szerepkörökkel, különböző engedélyekkel, s meghatározott módon információkat tudnak cserélni.

Az ALM öt legfontosabb szempontja:

Az együttműködés teszi lehetővé az egyedi fejlesztők működésének hatékonyságát, ennek megfelelően a termék-érték maximalizálását.

Az előállítás idejének felgyorsítása valósidejű tervezéssel (Real-Time Planning), Magyarországon problémát jelent a fejlesztési projektek csúszása, sem ezeknél, sem az üzemeltetésnél nem tudjuk mérni az informatikai rendszerek hatékonyságát, teljesítményét, ezen a téren komoly fejlesztésekre van szükség, a vonatkozó hagyományos és modern eszközök egyaránt régóta léteznek. Mérni kell, mert csak így tudunk rövidebb átfutású projekteket csinálni.

Minőségjavítás életciklus nyomonkövetéssel (Lifecycle Traceability-vel), álljanak rendelkezésre olyan eszközök, amelyekkel jelentéseket tudunk készíteni és meg tudjuk mutatni pl. a projekt késés okát.

Az előírásoknak való megfeleltetés fejlett intelligenciával.

Költségcsökkentés folyamatos fejlesztéssel (Continuous Improvement); a követelmények meghatározásánál keletkezett hiba azonnali kijavításának költsége egyszeres költségtényezővel számolható, de ha csak a kiadás után tudjuk elkezdeni a hibajavítást, az már százszoros tényezővel jelenik meg. Olyan eszközöket kell keresni alkalmazni, amelyek ezt a korai felderítést támogatják.

Az IBM Rational piacvezető az ALM piacon, az utána következők erősen le vannak maradva. Az IBM-nél az elmúlt év októberétől is olyan fejlesztések történtek, amelyek a piac igényét kielégítik.

Preisinger Balázs, az IBM Rational termékcsoport Central-régióért felelős értékesítője a Rational termékcsoportról

adott áttekintést. A Rational több mint 30 éve támogatja a szoftverkészítést, annak irányítását eszközökkel és folyamatokkal, módszertanokkal. A Rational céget 2003-ban vásárolta meg az IBM, azóta is teljes erővel fejleszt, jelenleg kb. 200 terméket tartalmaz a brand, így a legszélesebb és legmélyebb lefedettséget biztosítja a szoftverkészítéshez a piacon. A Fortune Top 100 cége közül 93 használ kisebb-nagyobb mértékben Rational terméket. Magyarországon is szinte minden iparágban vannak ügyfeleik; pénzügyi szektor, biztosító, távközlési cégek, energetikai cégek, autóipari beszállítók, államigazgatás, stb.

Az ipari forradalom óta több hulláma volt az innovációnak, jelenleg a legfontosabb mozgató rugó a szoftverkészítés.

Jelenleg éppen az okos telefonok forgatják fel az üzleti és fejlesztői életet. Egy mai autó pedig több kódsort tartalmaz, mint egy vadászgép. Az autó fejlesztések több mint 80%-át a szoftverek teszik ki. A bankoknál minden új szolgáltatás bevezetése szoftveren múlik. Ennek az innovációnak vannak lassító tényezői is, pl. komplex és multiplatform alapú rendszerek és alkalmazások. Míg a legtöbb cég igyekszik a mobil eszközök felé nyitni, a legtöbb mobil alkalmazásnak kapcsolódnia kell valamilyen nagyon régi rendszerhez, core-rendszerhez, mainframe rendszerhez, AS400-on futó rendszerhez, vagy csak egyszerűen valamilyen régebbi alkalmazáshoz.

A földrajzi távolságok, akár csak az elosztott telephelyek is, bonyolítják a képet, ma már az egy projekten dolgozó emberek nem ülnek egy szobában, sok a kiszervezett fejlesztés is. A világon Közép-Kelet-Európában van a legtöbb kiszervezés szoftver készítésben, ezen belül pedig Magyarországon.

A CIO-k, vagy IT igazgatók egyre nagyobb mértékben felelnek a kockázat-menedzsmentért, az üzlet alakulásáért.

A költségcsökkentés mindenhol jelentős tényező, az IT büdzsé 70-80%-a a meglévő vagyon fenntartására megy el, ezért az innovációra nagyon kevés marad. A projektek 37%-a túlnövi az eredetileg tervezett költségeket. Korábbi felmérés már kimutatta, hogy a projektek több mint 40%-a a nem megfelelő követelménykezelés miatt késik, csúszik, vagy meg is hiusul, a legújabb felmérés szerint ma már ez 85%-nál tart. Itt lehetne a legtöbbet megtakarítani, de ez kényelmetlenségekkel jár… A követelményeket kidolgozni nem egyszerű, de szükséges.

A szoftveren keresztüli innováció azért már soknak sikerült. Jó példa a GM Chevrolet elektromos autója, teljes tervezése Rational eszközökkel történt, a szokásos 120 hónapos fejlesztési idő helyett 29 hónap alatt. Másik példa az az életbiztosító cég, amely 50%-ot tudott megtakarítani átalakított fejlesztésével.

Az innovációra törekvők három fő célkitűzése:

Integrálni a különböző szoftver-készleteit, ill. a szoftver vagyonát, adatait, eszközeit, folyamatait, az információt, hogy mindenki abból dolgozzon, amiből kell.

Próbáljanak a csapattagok együttműködni. Nem csak a fejlesztők, mindenki aki a projektben részt vesz, szervező,

tervező, tesztelő. Az optimalizáció a tervezésen és mérhetőségen keresztül érvényesül. A szoftverkészítésben a mérhetőség nagyon nehéz feladat, mihez képest legyünk hatékonyak? Magunk jelen legi teljesítményéhez, vagy az ipar átlagához képest mérjünk? Amíg nem tudom számszerűsíteni, mérni, hogy jelenleg a csapatom mennyire hatékony, addig a cél a levegőben lebeg. Mérni kell trendadatokat, a csapattal adott időegység alatt megoldott feladatok számát. Ehhez képest szeretnék fejlődést elérni. Ennek megoldásával lehet növelni a minőséget, lehet gyorsabban piacra kerülni, csökkenteni a kockázatot, a költségeket és jobban megfelelni az üzlet és a megrendelő elvárásainak.

Az előállítást egyre gyorsabban és egyre jobb minőségben kéne végezni, miközben a szoftver-termékek összetettsége csúcsokat dönt. Ennyire nehéz dolga a szakmának még sohasem volt, miközben egy PC-s alkalmazásra a felhasználó hajlandó várni egy-két percet is, amíg visszakapja az alkalmazásban a továbblépés lehetőségét, addig egy mobil eszközön már néhány másodperc várakozás után is a felhasználó elveszti türelmét, s nem fogja használni a szoftver-terméket. Ez komoly kihívást jelent.

A Rational portfólió rétegei; követelmény-kezelés, architektúra menedzsment és tervezés, változás és konfiguráció kezelés, fejlesztő eszközök, tesztelő eszközök, terítést-kibocsájtást segítő eszközök, működést támogató eszközök.

A módszertanokat tekintve, a nagy cégek gyakorlatában a hosszabb lefolyású projekteknél a hibrid módszertanok sokkal jobban alkalmazhatók, mint a tisztán agilis módszertanok.

Az integrációról szólva, az IBM 2005, a Rational felvásárlása óta nekilátott egy új integrációs platform, a Jazz kifejlesztéséhez. Az IBM ezen stratégiai platformja nyílt szabványokra épül, ill. lehetővé teszi harmadik fél által gyártott eszközök integrációját is az életciklusban. Jelenleg az életciklus menedzsmentben a követelmény kezelés, a core részlet, a projekt tervezés, projekt végrehajtás, feladatkezelés, konfiguráció menedzsment és build menedzsment, valamint a teszt menedzsment helyezkedik el ezen a platformon, ill. a modellező eszköznek egy már meglévő változata. Várható, hogy a teljes integráció hamarosan létrejön a másik három termékkel (a Collaborative Lifecycle Management-tel) is.

Az IBM friss akvizíciója az elmúlt év januárjában fejeződött be a Green Hat cég megvásárlásával. A szakma ennek a teszt-virtualizáció nevet adta, (nem keverendő össze a VMware-es virtualizációval), bár inkább szimulációról lehet itt beszélni. A legtöbb nagy cégnél komplex, heterogén alkalmazások futnak, komplex, bonyolult, drága teszt-környezetekkel, amely nem mindig feleltethető meg az éles működésnek. A Green Hat termékcsalád itt tud segíteni,

képes komplett alkalmazásokat, vagy rétegeket szimulálni. Ezzel le lehet csökkenteni a hardver igényt, a teszt-környezetekben levő licenc költségeket. Minden fejlesztőnek saját teszt-környezete lehet. Ezek a környezetek nagyon könnyen előállíthatók, az integrációs tesztelést a fejlesztési életciklus elejére ki lehet tolni. Ugyanis, lehet, hogy a fejlesztőnek olyat kell fejlesztenie, vagy olyan egyéb szoftverrel kellene integrálódnia, amely még nem is készült el, de az integrálandó szolgáltatás leírója már megvan, ilyenkor ezt a működést lehet szimulálni, tesztelni.

Így a tényleges integrációs teszthez eljutva, már jóval kevesebb hibával kell számolni.

Az eszköz maga számos protokollt, üzenet-formátumot, middleware eszközt támogat.

A megtérülést tekintve, a tesztkörnyezet infrastruktúrán elérhető költség-csökkenés akár 90%-os, a befektetett munkakörnyezetek támogatásával akár 80%-os lehet. Magyarországon ezek a megtakarítások 100 milliós nagyságrendet is elérhetnek. Lecsökkenthető a szoftverkészítés időtartama.

A Rational az elmúlt években számos elismerést kapott, pl. az Ovum elemző cég tanulmányaiban és díjakkal ismerték el. A Rational Applicational Developer az elmúlt 7 évben hatszor lett a világ legjobbnak ítélt fejlesztő eszköze, életciklus menedzsmentben pedig a legnevesebb fejlesztő felmérők díjait kapta.

http://ibm.com/rational

https://jazz.net

Kaszás Orsolya, a Ker-Soft Kft. tanácsadója a Team Concert-ről és a kapcsolódó igénykezelési szoftverről szólt.

Sándor Gábor, és Moizes Gábor (Thyssenkrupp Presta) a Rational DOORS felhasználói tapasztalatokról számolt be.

www.kersoft.hu

http://en.wikipedia.org/wiki/Application_lifecycle_management

http://www.forrester.com/home

http://www.pmhut.com/project-failure-cobbs-paradox

http://www.valodi.hu/agile

http://matyigabor.hu/fejlesztesi-modszertan/agilis-vs-klasszikus-modszertan

http://hu.wikipedia.org/wiki/Scrum

http://users.iit.uni-miskolc.hu/ficsor/inftervseg/agilis.pdf