Fyi 18 web

Fyi 18 web
tehnologijeitrendovi:g*rich•Dajmo djecidaprogramirajuprojektnepriče: Implementacijadisasterrecoveryrješenja uFini•IntranetuSKBbanciintervju: PeterEeles:Svrhasoftverskearhitekture predstavljamopartnere:CSILtd.
IZDVAJAMO IZ AKTUALNIH TEČCAJEVA: TEČAJEVI PO MJERI LEARN@CROZ kontaktirajte nas na learn@croz.net IBM BUSINESS PROCESS MANAGER (BPM) UVOD U AGILNI PRISTUP RAZVOJU SOFTVERA RAzvoj mobilnih aplikacija (ios i android) spring framework RAzvoj rješenja nad alfresco ECm sustavima Mentoring i coaching essentials of IBM rational performance tester certified SCRUM PRODUCT OWNER (agile42) management 3.0 (jurgen appelo)
FYI by CROZ / broj 18 /svibanj 2015. | 3 nadnaslov | rubrikafyi by croz | uvodnik FYIbyCROZ|Časopiszainformatiku|Urednik:GoranKelečić|Izdavač:CROZd.o.o.,Lastovska23,10000Zagreb,RepublikaHrvatska|Tel.:0038516184831|Faks:0038516184833 E-mail: fyi@croz.net | Internet: www.croz.net | Grafički dizajn časopisa i naslovnice: SBD Shift Brand Design, www.sbd.ba | Tisak: Tiskara Grafing d.o.o., Zagreb Piše: Krešimir Mudrovčić Urednik: Goran Kelečić T ema ovog broja je testiranje, odnosno upravljanje kvalite- tom softvera. Testiranje, kao i sigurnost u prošlom broju, su teme kojih nikada nije previše. Sigurnost je nekako atraktivnija tema, često čitamo u medijima o najnovijim sigurnosnim propustima i gledamo holivudske filmove o hakerima. A testiranje je ostalo ružno pače softverske industrije. Pa hajʼmo to ispraviti! U ovom broju čitajte o automatiziranju testiranja, performansnom testiranju, testiranju mobilnih aplikacija… Posebno smo ponosni što se možemo pohvaliti da nas je Erste&Steiermärkische banka u jakoj međunarodnoj konkurenciji odabrala za strateškog outsourcing partnera u području testiranja. Priča se savršeno uklapa u temu broja. Kada ste sve to proučili, spremni ste za ispit zrelosti! Oslanjajući se na TMMi Foundation, naši stručnjaci su osmislili učinkovit i jednostavan model za provjeru zrelosti organizacije u području testiranja. Dakle, ako želite provjeriti kako stojite s testiranjem i pripremiti strategiju unapređenja testiranja, ovo je idealan prvi korak. Topla preporuka od strane vašeg uvodničara! Kažu da svaki programer (a pogotovo javaš) želi razvijati svoj vlastiti framework. Ipak, to nije jednostavan zadatak, a zahtijeva i jako puno znanja i iskustva. Naš tim predvođen Damirom Muratom razvio je g*rich, framework koji predstavljamo u ovom broju. Rezultati su vrlo dojmljivi; ubrzali smo i pojednostavnili razvoj, korisničko sučelje je ergonomično i funkcionalno (i seksi), ugrađena je i integracija s ECM i BPM sustavima. Standardizacija i sigurnost manje su vidljivi, ali podjednako važni dobitci. I što je najljepše, stvar dokazano radi u praksi. Iako je početna ideja bio interni razvoj, g*rich je zamišljen tako da ga mogu koristiti i naši korisnici! Još jedna topla preporuka! Ovaj uvodnik pišem u slatkom pred- QED iščekivanju. Naša mala konferencija (Dalmatinci bi rekli “smišna”) se ove godine preselila u Rovinj. Sve ono zbog čega volimo QED, a to je prije svega pozitivna atmosfera i kvalitetan sadržaj, ostaje nepromijenjeno. Puno je i novosti, dolaze svjetske face; Andreu Tomasinija vjerojatno ne treba više predstavljati, Grady Booch je računalni znanstvenik i filozof, a pomalo i umjetnik. Pričat ćemo o kreativnosti i inovativnosti, bit će baš super! Naša ekipa bila je u Americi i vratila se puna dojmova. S jedne strane velika preobrazba IBM-a, veterana informatičke industrije, u koju se moglo uvjeriti dvadeset tisuća sudionika InterConnect konferencije. S druge je strane nepodnošljiva lakoća Silicijske doline, Google, Facebook i novi poslovni modeli. Ostaje nam promatrati i doživjeti koji će smjer prevladati. Ja bih se kladio na dijalektiku. Za kraj ovog uvodnika jedna jako bitna tema: treba li djecu učiti programiranju? Mi mislimo da treba, ali program po kojem se radi u našim školama nepopravljivo je zastario, a praksa još i više. Iskustva s radionica za djecu koje organizira udruga Programerko pokazuje da se programiranje može učiti drugačije. Naprednije i zabavnije. Pozivamo i vas da nam se pridružite u mijenjanju sadašnjeg stanja.
4 | FYI by CROZ / broj 18 / svibanj 2015. sadržaj | fyi by croz 6 17 9 23 12 31 40 29 15 35 19 42 37 21 27 33 tema broja: Provjera zrelosti testnog okruženja Automatizacijom testiranja do kvalitete Performansno testiranje Testiranje mobilnih aplikacija tehnologije i trendovi: IBM Security Identity Governance g*rich – rješenje za svakodnevne razvojne probleme IBM API Management Upravljanje softverskim licencama u svijetu IBM-a Tehnološki radar Dajmo djeci da programiraju projektne priče: Implementacija disaster recovery rješenja u Fini Internet ili intranet? Što je važnije? Upravljanje znanjem u APIS IT-u intervju: Peter Eeles Svrha softverske arhitekture predstavljamo partnere: CSI Ltd., United Kingdom REPORTAŽE: Mijenjam, mijenjam se
FYI by CROZ / broj 18 /svibanj 2015. | 5 nadnaslov | rubrikafyi by croz | vijestifyi by croz | vijesti Održanodogađanje Prediktivnaanalitikai FraudManagement Događanje posvećeno primjeni tehnika i alata za naprednu analizu podataka s ciljem poboljšanja poslovanja s jedne, ali i sprečavanja zloporaba i neželjenih ponašanja s druge strane, održano je 19. ožujka u edukacijskom centru Learn@CROZ. U nizu predavanja stručnjaci iz CROZ-a i IBM-a kroz mnoge su primjere i savjete, s naglaskom na bankarsku i osiguravateljsku industriju te marketing i državne ustanove, pokazali kako uloga prediktivne analize i ranog otkrivanja prevara može biti ključna za uspjeh poslovnog pothvata. CROZ zlatnisponzor konferencijeAgile Adria Udruga Agile Hrvatska, čiji su članovi i mnogi naši CROZ-ovci, organizirala je i ove godine od 13. do 15. travnja u Termama Tuhelj konferenciju Agile Adria. Konferencija je okupila više od 170 ljudi iz 16 zemalja te tim brojem, ali i predavačima svjetskog ugleda poput Mary Poppendieck, Toma Gilba i Stephena Parryja, potvrdila status najveće i najbolje agilne konferencije u ovom dijelu Europe. CROZ je sudjelovao kao zlatni sponzor konferencije. Održanfinancijski RoadshowEvent U četvrtak 16. listopada 2014. u edukacijskom centru Learn@CROZ održan je financijski Roadshow Event u organizaciji tvrtki CROZ i Liferay. Demonstracijom uživo i predstavljanjem najzanimljivijih značajki približili smo sudionicima događanja način korištenja Liferay portala u financijskim ustanovama. CROZ sponzor drugog izdanja konferencije JavanturaoJavii srodnim jezicima CROZ je bio ponosni srebrni sponzor konferencije Javantura v2 koja je održana 15. studenoga 2014. u Zagrebu. Oko 200 razvojnih inženjera, voditelja projekata i studenata tako su dobili priliku, tijekom čak 16 predavanja, upoznati se s najnovijim trendovima u tom programskom jeziku. Jedno od predavanja, Dockyourapp, održali su CROZ-ovi stručnjaci Matija Folnović i TomislavKlišanić.U sklopu predavanja demonstrirali su kako se u tvrtki CROZ koristi platforma Docker za izradu posebno prilagođenih poslovnih aplikacija. Riječ je o platformi koju koriste razvojni inženjeri i sistemski administratori za izradu, distribuciju i pokretanje aplikacija, koje su onda potpuno portabilne i mogu se bilo gdje pokretati. Uspješnoodržanpeti SmartDay Peto izdanje serije događanja Smart Day održano je 20. siječnja u dvorani Müller kina Europe, u organizaciji časopisa “Mreža” i tvrtke CROZ. Naziv petog izdanja ovog događanja bio je Sveti gral inovativnosti, a u toj se tematici Vedrana Miholić, direktorica prodaje CROZ-a, savršeno pronašla. U svom uvodnom predavanju obradila je temu kreativnosti i inovativnosti kao ključnim faktorima za opstanak i napredak svake organizacije. Ujedno je prezentirala i glavne karakteristike CROZ-ove platforme Like My Idea, rješenja koje olakšava organizacijama prikupljanje, filtriranje i nagrađivanje ideja zaposlenika. LMIpredstavljen slovenskim start- up tvrtkama na događanjuImplico CROZ je 26. siječnja predstavio svoje rješenje Like My Idea (LMI) u sklopu prvog dana događanja Implico u Ljubljani. Riječ je o seriji događanja koju organizira odjel slovenske Udruge za ljudske resurse MEKS (Mladi stručnjaci kadrovske struke). Cilj je Implica da podigne svijest o važnosti struke ljudskih resursa kao strateški važne funkcije svake tvrtke, bez obzira na njezinu veličinu ili tip. Mirela Držaić iz CROZ-a upoznala je predstavnike malih i start-up tvrtki iz Slovenije s LMI-om kao rješenjem koje omogućava tvrtkama da prepoznaju istaknute talente među svojim zaposlenicima i kao mehanizam motivacije zaposlenika u smislu aktiviranja pri kontinuiranom poboljšavanju internih procesa.
6 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Provjera zrelosti testnog okruženja Zagonetka na početku: • svi se hvale da ga upražnjavaju • svi se hvale da ga imaju dovoljno • svi se hvale da su odlični u tome • svi se hvale da ne trebaju pomoćne alate • svi se hvale da je “primajuća” strana sretna i zadovoljna. O čemu se radi? O testiranju, naravno. Rijetko koja disciplina u razvoju softvera je toliko bitna a da se tako olako ignorira i preskače. Uzmimo, recimo, analizu poslovnih zahtjeva. Čisto sumnjam da će naručitelj posla samo reći: “E, cure i dečki, treba nam internet bankarstvo, dajte napravite nešto. Hvala.” S druge strane, prečesto čujem riječi: “E, cure i dečki, dajte malo stisnite i dovršite implementaciju pa da idemo dalje, testiranje ćemo napraviti kasnije. Hvala.” Zašto je tome tako? Nažalost, vrijednost koju testiranje isporučuje nije vidljiva na prvi pogled. Ako nešto radi ono što treba, radi zato što je dobro isprogramirano, a ne zato što je napisan test. Čisto mehanički gledano, da poznajemo poslovnu domenu do najsitnijih detalja, da su zahtjevi potpuno jasni, da je razvojno okruženje idealno, da je izvedbena strana savršena i bez ijednog buga, testiranje ne bi ni bilo potrebno: sve bi radilo iz prve i baš ono što treba, za jednog ili deset tisuća korisnika istovremeno, 24/7/365. Ali svijet razvoja softvera nije takav. Niti je poslovna domena poznata, niti je infrastruktura bezgrešna. Fantastične stvari koje aplikacije rade kad su pod povećanim opterećenjem ne trebamo ni spominjati. I baš zato nam je potrebno testiranje, da u takav nepredvidljiv svijet uvedemo određenu količinu sigurnosti i predvidljivosti, da se ne čudimo kasnije kad se 2 (slovima: dva) korisnika istovremeno prijave u aplikaciju i time uzrokuju zaglavljivanje cijelog sustava jer se odjednom potrošila sva memorija. Priznajem da malo dramatiziram, iako je ova priča o dva korisnika, vjerovali ili ne, istinita (vidio svojim očima, op. a.). Provjera zrelosti testnog okruženja Pet razina zrelosti testiranja, kako ih postavlja TMMi Foundation Svijest o potrebi za kvalitetnim i strukturiranim testiranjem raste iz godine u godinu, čemu smo i mi iz CROZ-a dijelom zaslužni, što kroz objavljivanje ovakvih članaka, što kroz pokrivanje testiranja na QED-u, a naravno i kroz prakticiranje testiranja na svojim projektima. Zar nam stvarno treba testiranje? Testiranje je, baš svi će se složiti, kompleksna disciplina koju možemo promatrati iz više kutova i koju možemo početi primjenjivati na različite načine. Ponekad nam je dovoljno odraditi završno korisničko testiranje i spremni smo za produkciju, no ponekad je nužno proći kroz Piše: Davor Čengija Kako napraviti brzi pogled u stanje testnog okruženja u organizaciji?
FYI by CROZ / broj 18 /svibanj 2015. | 7 Provjera zrelosti testnog okruženja | tema broja sve razine, od unit testova na izvornom kodu do testiranja ponašanja cjelokupnog sustava u slučaju ispada dijela infrastrukture. Koji ćemo pristup imati jako ovisi o samom sustavu koji testiramo. Ako se radi o internoj aplikaciji za prijavu godišnjeg odmora, onda je možda dovoljno isprobati radi li sve na testnoj okolini i spremni smo za produkciju. Uostalom, ako nešto pođe krivo i zapis o mom godišnjem se izgubi, pa dobro, nema veze, prijavit ću ga ponovo. Ako se s druge strane radi o famoznom internet bankarstvu, onda vjerojatno želimo testirati i izvorni kod (razne izračune, provođenje transakcija i tako dalje) i sigurnost (recimo na OWASP Top 10 – za više detalja vidi okvir u članku o g*richu), ali i ponašanje sustava u slučaju nedostupnosti nekog ključnog dijela infrastrukture. Tu je, naravno, i regresijsko testiranje – nakon puštanja u rad novih funkcionalnosti želimo znati rade li one stare kao i prije. Nije svako testiranje prikladno, ili bolje rečeno isplativo u svakoj situaciji, no prepoznavanje pravog trenutka je vještina koja se uči i brusi kroz vrijeme. Kako testiranje često predstavlja pa čak i 30–40% ukupnog troška projekta, dobrom organizacijom i planiranjem aktivnosti ne samo da podižemo kvalitetu isporučenog softvera i sustava u cjelini nego i smanjujemo cijenu projekta. Koliko je neka organizacija zrela u pogledu testiranja se može relativno brzo i jednostavno izmjeriti. Naime, softverska zajednica se kontinuirano trudi podići razinu kvalitete cjelokupnog proizvodnog procesa, tako da su de facto standardi za razvoj postavljeni u vodiču pod imenom CMMI, Capability Maturity Model Integration. Pandan CMMI-u u domeni testiranja definira TMMi Foundation, strukovna organizacija koja objedinjuje aktivnosti vezane uz testiranje, uključujući i standarde, referentni model i model zrelosti. Snimka stanja i ocjena zrelosti testnog okruženja Na temelju TMMi-a, ali i vlastitih iskustava smo razvili i svoju uslugu snimke stanja i ocjene zrelosti testnog okruženja (Testing Environment Maturity Assessment), kao jednodnevne radionice na kojoj se vrlo fokusirano i precizno određuje kvaliteta testiranja u proizvodnom procesu, i istovremeno prepoznaje prostor za napredak i usavršavanje. Radionica se sastoji od pet dijelova, od kojih prva tri uključuju odabrane djelatnike organizacije u kojoj radimo analizu. Naime, kako bi se čim efikasnije iskoristilo vrijeme i čim prije došlo do rezultata, nužno je na jedno mjesto okupiti Zrelost procesa testiranja se može jednostavno pozicionirati na prikazanoj piramidi Testiranje se, kao uostalom i svaki drugi proces, sastoji od metodologije, od ljudi koji provode tu metodologiju i infrastrukture na kojoj se sve odvija Rezultat drugog dijela radionice. Žute naljepnice predstavljaju pozitivne segmente, dok ljubičaste ukazuju na prostor za unapređenje. Usluga snimke stanja i ocjene zrelosti testnog okruženja je drugačija od uobičajenog i, po našem mišljenju, pogrešnog pristupa ovakvim zadacima. Ako želimo dobiti presjek stvarnog stanja nekog procesa unutar organizacije, onda tradicionalni način jednostavno nije dovoljno dobar.Višednevno prikupljanje dokumentacije koja obično ne odražava stvarno stanje stvari, pojedinačni razgovori s preopterećenim ljudima koji se razvuku na dane, da ne kažem tjedne, i subjektivne i nepotpune informacije ne mogu garantirati kvalitetnu analizu okruženja. Dobar referentni model i bogato iskustvo naših stručnjaka omogućava brzu usporedbu trenutačnog stanja s idealnim i prepoznavanje koraka za unapređenje u roku od samo dan ili dva.
8 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Provjera zrelosti testnog okruženja kompetentnu ekipu koja ima potrebna znanja o internim procesima definiranja i analiziranja poslovnih zahtjeva, razvoja, puštanja u rad i, naravno, testiranja i prihvaćanja isporuka. U prvom dijelu se u tridesetak minuta postavlja zajednička “referentna točka” i pogled na idealni svijet testiranja. Koliko god bio nedostižan, idealni svijet predstavlja zajednički cilj koji mora biti jasan svima, bez obzira na razinu uključenosti u sami proces. Bitno je definirati što za odabranu organizaciju znači testiranje, prepoznati koji se rječnik koristi i kako je posloženo cjelokupno okruženje koje omogućava odvijanje povezanih aktivnosti. Zatim je važno osvijestiti potrebu za metodološkim pristupom testiranju, za strategijom i praksama, i na samom kraju jasno postaviti temelje za nastavak radionice. Drugi dio je najduži i predstavlja pravu radionicu, u tradicionalnom SWOT analiza će ukazati na potrebne akcije s ciljem poboljšanja okruženja smislu. Ovdje je ključno vrlo aktivno sudjelovanje stručnjaka iz organizacije koju analiziramo. U svojoj osnovi, ideja je jasno i nedvosmisleno prepoznati kako izgleda cjelokupno testno okruženje, što je prema mišljenju “radne skupine” dobro i što treba zadržati, a što nije baš najbolje i treba popraviti. Bitno je razumjeti da nema točnih i netočnih odgovora već da želimo iskreno i pošteno sami sebi razjasniti kakvo nam je okruženje. Detaljno se ulazi u analizu primijenjene metodologije, u sami proces testiranja, organizaciju i okruženje. Na primjer, najčešće se pokaže da su ljudi vješti u testiranju svojih aplikacija, ali da nedostaje formalne naobrazbe, što kasnije negativno utječe na komunikaciju između timova, ili da se nedovoljno pažnje posvećuje automatizaciji, čime se izravno gubi vrijeme koje se moglo bolje iskoristiti na nekom drugom mjestu. Treći dio je možda i najrazličitiji od uobičajenog pristupa, no jako je dobro prihvaćen gdje god smo ga isprobali. Radi se, naime, o kratkim i vrlo ciljanim, direktnim intervjuima sa svakim od polaznika radionice pojedinačno. Iznenađuje koliko se novih informacije može saznati u tih deset ili petnaest Na jednom mjestu se vidi trenutačno stanje okruženja, preporuke za quick win i buduće, poboljšano stanje Stvarno je zanimljivo vidjeti koliko se korisnih informacija može dobiti u razgovoru jedan-na- jedan. Čim nema šefa ili kolega, ljudi se otvore i progovore o stvarnim problemima. Osnovna je pretpostavka da svi imaju želju unaprijediti svoje radno okruženje pa tako ovakvi intervjui daju ključne informacije što stvarno škripi i gdje treba uložiti napore koji će voditi k poboljšanju procesa. minuta razgovora, a pogotovo je zanimljivo da tijekom intervjua uglavnom isplivaju detalji kojima ljudi nisu zadovoljni, ali im je bilo teško ili neugodno reći u grupi. To je zapravo odlično, jer tek tako možemo steći potpunu sliku o procesu. Tokom četvrtog dijela radionice analiziramo prikupljene podatke i pripremamo izvještaj, kao i završnu prezentaciju koju predstavljamo dan poslije, na petom i posljednjem dijelu. Sve prikupljene informacije se vrednuju i slažu u matricu ovisnih vrijednosti, kako bi se na jednom mjestu moglo vidjeti trenutačno stanje okoline. Što dalje? Provjera zrelosti testnog okruženja će dati uvid u proces i organizaciju testiranja, ukazat će na kritične detalje koje treba popraviti kao i na one segmente koje treba zadržati i osnažiti. Rezultati snimke stanja, takozvani “nalazi”, doslovce se mogu iskoristiti kao popis zadataka koje treba ispuniti kako bi se unaprijedilo testiranje, kako u kratkom roku, recimo odmah za sljedeći projekt, tako i dugoročno, za sve buduće aktivnosti. Trenutna procjena Prvi koraci Konačnapreporuka Savršeno testiranje Praksa Strategija Proces Kompentencije Organizacija Edukacija Environment Incident management tool Test management tool Security testing tool Test automation tool Performance testing tool Analiza napretka
FYI by CROZ / broj 18 /svibanj 2015. | 9 Automatizacijom testiranja do kvalitete | tema broja O snovna definicija testiranja softvera kaže – testiranje softvera je proces kojem je cilj pronaći pogreške u programskom kodu. Važno je naglasiti kako testiranje nije nešto što će se jednom izvršiti i nakon toga zaboraviti. Testiranje je proces koji kontinuirano traje tijekom čitavog razvoja programskog rješenja. Zašto je testiranje toliko bitno? Ključno je za pronalazak pogrešaka nastalih u fazama razvoja, povećava kvalitetu isporučenog programskog rješenja, što korisniku donosi manje troškove održavanja i pouzdani proizvod, smanjuje mogućnost nastanka skupih programskih pogrešaka, osiguranjem kvalitete raste zadovoljstvo korisnika i njihovo povjerenje u razvojni tim, a sve navedeno osigurava isporučitelju jaku i sigurnu poziciju na tržištu. Testiranje u praksi Praksa je pokazala da tvrtke, a i zaposlenici koji su zaduženi za testiranje, često gledaju na testiranje kao na nužno zlo. Testiranje se najčešće obavlja ručno, oduzima puno vremena i testeri imaju dojam da gube vrijeme i da bi mogli raditi nešto “pametnije”. Problem je posebno izražen kada je potrebno testirati cijeli sustav nakon svake nove izmjene, a to najčešće rezultira time da se testiranje obavlja brzo i površno, što dovodi do pojave grešaka koje su se mogle izbjeći kvalitetnijim i sistematičnijim testiranjem. Naravno, to iziskuje i znatno odvajanje dodatnih resursa kako bi se taj postupak mogao provesti. Potrebni su veći testni timovi, što znači zapošljavanje novih testera ili dodjela testerskih poslova zaposlenicima kojima to nije primarno zanimanje, što je u praksi najčešći slučaj i često dovodi do nezadovoljstva. Kako bi se troškovi smanjili, a cijeli proces ubrzao i unaprijedio, uvodi se automatizacija testiranja. Kada se govori o automatizaciji testiranja softvera uglavnom je riječ o funkcijskom i regresijskom testiranju. Funkcijskim testiranjem odgovara se na pitanje: “Radi li implementirana funkcionalnost onako kako se očekuje?”, testira se ponašanje aplikacije u realnom okruženju, onako kako bi je krajnji korisnik koristio. Regresijsko se testiranje koristi kako bi se provjerio utjecaj neke izmjene na ostatak aplikacije. To znači da se neće testirati samo funkcionalnost na kojoj se radila izmjena, nego će se testirati cijela aplikacija kako bismo se uvjerili da tom izmjenom nije došlo do neočekivanog rada u nekom drugom dijelu aplikacije. Ovdje je već jasno izražena potreba za automatizacijom, ručno testiranje cijelog sustava ispočetka kod svake izmjene prilično je naporan posao i praksa pokazuje da ga ljudi nerado obavljaju. Što je zapravo automatizacija testiranja? Automatizacija testiranja softvera podrazumijeva korištenje specijaliziranih alata koji omogućuju izradu testnih skripti, njihovo izvršavanje i obradu rezultata. U svom sam dosadašnjem radu koristio razna programska rješenja kao što su IBM Rational Functional Tester, Selenium, HP Unified Functional Testing, SmartBear TestComplete, TOSCA Testsuite, BugBuster, a o nekima sam detaljnije pisao u našem tehnološkom blogu (http://goo.gl/fxlqAc). Cijelo se vrijeme govori o automatizaciji testiranja, ali kako zapravo automatizirati neki testni scenarij? Kod ručnog testiranja obično postoje testni slučajevi (test cases) koji sadrže testne korake. Tester će ručno proći svaki korak, upisivati razne ulazne podatke, prolaziti kroz aplikaciju, pratiti rezultate, provjeravati validacije, otvarati i zatvarati prozore, uspoređivati dobivene rezultate s očekivanima. Taj je proces vrlo spor. Automatizirati taj proces znači jednostavno pretvoriti testni slučaj u testnu skriptu, pretvoriti testne korake iz tekstualnog oblika u programski kod. Nakon što je testna skripta dovršena, ona se može izvršiti brzo, kada i koliko god puta želimo. To znači da se sav zamoran posao koji je tester ručno obavljao može obaviti jednostavnim pokretanjem skripte. Velika je prednost automatizacije testnih skripti i u neograničenom skupu ulaznih testnih podataka. Ista se skripta može izvršiti više puta s različitim podacima, a to omogućava kvalitetno i detaljno testiranje. Testna skripta može dinamički učitavati razne tablice koje se pojavljuju na ekranima, provjeravati veliku količinu Praksa pokazuje da se testiranje softvera najčešće provodi ručno. Ipak, za kvalitetnije i sistematičnije testiranje preporuča se automatizacija tog procesa. Piše: Ante Cikojević Automatizacijom testiranja do kvalitete
10 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Automatizacijom testiranja do kvalitete Jedna ste od vodećih banaka na tržištu u Hrvatskoj i regiji, gdje leži tajna vašeg uspjeha i održavanjakonkurentnosti? Odgovor je lako pronaći u našoj viziji – biti najbolja banka u Hrvatskoj koja brine o sigurnosti svojih klijenata i pruža najkvalitetnije proizvode i usluge. Kad smo kod toga – upravo u domeni sigurnosti te u kvalitetnim proizvodima i uslugama IT igra ključnu ulogu u banci te tu vidimo vaš doprinos u području testiranja sofvera. Zašto ste nakon toliko godina odlučili krenuti u potragu za strateškim outsourcing partnerima u domeni razvoja i testiranja softvera? Smanjenje troškova vezanih uz non-core business prva je pomisao koja se javlja na spomen outsourcinga, međutim fleksibilnost se pokazala kao jedna od ključnih prednosti outsourcinga. Izazovi s kojima se susrećemo na ključnim projektima unutar banke zahtijevaju prije svega izrazitu fleksibilnost – upravo je ta fleksibilnost i bila jedan od glavnih razloga za pokretanje strateškog outsourcinga unutar Erste banke. Nadalje, u partnerskom odnosu možemo učitanih podataka, provjeravati numeričke izračune i slične zadatke koji bi ručnim testiranjem trajali jako dugo. Ako se taj proces automatizira, izvršavanjem testne skripte svi navedeni zadaci obave se u samo nekoliko sekundi. Osim što se automatizirati može sve što korisnik/ tester radi u samoj aplikaciji, testna skripta može prolaziti kroz korake testnog slučaja i istovremeno provjeravati ispravnost spremljenih podataka direktno u bazi. Dubina i kompleksnost posla koji obavlja testna skripta ovisi o samom testeru koji je implementira, bitno je dobro procijeniti koji je posao potrebno automatizirati, a koji bi posao bio suvišan. Ponekad je za potrebe testa dovoljno samo automatski popuniti formu privremenim podacima, bez da skripta brine o formatu i vrijednostima koje su unesene i spremljene u bazu. Tko ili što je dobar tester? Većina alata za automatizaciju traži od testera određenu razinu programerskog znanja. Kolika je razina potrebna ovisi o samom alatu, vrsti programskog sustava koji se testira i opsegu testiranja. Najbolji tester je analitičar s dovoljno programerskog znanja ili programer koji je dovoljno analitičan. A Mnogi alati za automatizaciju omogućuju snimanje testnih skripti gdje tester započne snimanje, ručno odradi testni slučaj, a alat snimi sve njegove korake i pretvori ih u programski kod. Nakon toga svakim će se pokretanjem testne skripte automatski izvršiti svi koraci koje je tester snimio, uvijek na isti način kako su i snimljeni. Drugi način izrade skripti je pisanje programskog koda “od nule”, ali tu je već potrebno dobro znanje programiranja i poznavanje arhitekture U 2014. godini Erste & Steiermärkische banka bila je u potrazi za outsourcing partnerima u uslugama razvoja i testiranja softvera. Kao jedan od najozbiljnijih kandidata CROZ je dobio priliku da kroz PoC (ProofofConcept) dokaže da je vodeći partner na tržištu u uslugama testiranja softvera, i ispit je položen s odličnim! NakonuspješnorealiziranogPoC-ausklopukojegsmodokazalinašuekspertizuurazličitimvrstamatestiranja, izmeđuostalogutvorničkomtestiranjutekućegrazvoja,izradiautomatiziranihregresijskihtestovateizraditestova zaobradne(batch)programe,stručnjaciCROZ-aiErsteauskosuiuspješnosurađivaliuspostavljanjemvisokog stupnjarazumijevanja,konkretnihunaprjeđenjausvakodnevnomtestiranjubanketeujednačenemetodologije. SamompočetkuangažmanajeprethodiloicertificiranjevećegbrojanašihstručnjakazaradstestnimalatomTOSCA, kojije“kućni”alatubanci.Nakontogasmozajedničkikrenuliustrateškopartnerstvo.Većjegodinakvalitetne suradnjeizanas,tesmotimpovodomrazgovaraliodojmovimaoveuspješnepričeskoordinatorimaprojektasErstei CROZ-ovestrane:TomislavomKirincemiDarkomMarijančićem. Automatizacija testiranja u Erste&Steiermärkische banci naučiti nešto od drugih i tu dodatnu vrijednost pretočiti i u naša rješenja. U natječaju je osim domaćih tvrtki bila prisutna renomirana internacionalna konkurencija. Nije baš svakidašnja situacija da se tvrtke iz Indije pojavljuju kao konkurencija na domaćem tržištu. Kad ih uspoređujete s domaćim tvrtkama, kako biste ocijenili njihov pristup i ostale karakteristike u odnosu na domaće tvrtke? Pristup naših strateških partnera iz Indije izrazito je profesionalan i strukturiran, te možemo reći da smo i mi neke stvari naučili od njih glede izvještavanja i strukturiranog pristupa u domeni outsourcinga. Razlike u odnosu na domaće tvrtke itekako postoje, Tomislav Kirinec, koordinator projekta s Erste strane s Lukom Gautom, CROZ-ovim voditeljem ključnih kupaca Tomislav Kirinec sITSolutions (Managerfor ExternalITService Providers)
FYI by CROZ / broj 18 /svibanj 2015. | 11 Automatizacijom testiranja do kvalitete | tema broja U Hrvatskim se prilikama i velike organizacije podržane brojnim informacijskim sustavima teško odlučuju na automatizaciju testiranja. Glavni su izgovori visoki inicijalni troškovi alata i obuke ljudi. No, to nije slučaj u Erste & Steiermärkische banci, koja već niz godina strateški ulaže i provodi automatizaciju regresijskih testova za velik broj svojih informacijskih sustava. Počeci suradnje ponudili su nam nekoliko izazova. U postojeće Ersteove planove, procese, infrastrukturu i timove potrebno je bilo uklopiti veći broj CROZ-ovih testera različitih profila. Ersteovi stručnjaci organizirali su i održali s nama niz radionica i telekonferencija s ciljem prijenosa znanja te lakše i brže prilagodbe CROZ-ovih testera. Bilo je potrebno da i CROZ interno obuči više od 10 testera za korištenje alataTOSCA, koji do sada u CROZ-u nije bio primaran testni alat. Bitno je reći da alatTOSCA korišten u Ersteu uvelike pridonosi kvaliteti poslovnih rješenja omogućavanjem automatiziranih testova. Održan je i niz sastanaka i radionica s članovima Ersteova tima s ciljem prenošenja iskustava CROZ-ovih stručnjaka. U svakom slučaju, možemo se pohvaliti da smo dosta toga naučili od kolega iz Erstea, ali i uspjeli podijeliti naše znanje i iskustvo s njima – što je i bit strateškog partnerstva. Danas, s preko 2 000 automatiziranih testova“u nogama”, CROZ ima uhodani testni tim koji sve kvalitetnije i efikasnije odgovara specifičnim potrebama Banke, a Erste kvalitetnog i pouzdanog partnera s kojim je bitno osnažio svoje vlastite kapacitete testiranja. Ovo iskustvo pokazuje da kvalitetna strategija testiranja, te prije svega sustavna i dobro osmišljena obuka ljudi, u relativno kratkom roku može opravdati sva ulaganja u automatizaciju testiranja. programskog rješenja koje se testira. Ipak, praksa je pokazala da se najčešće koristi kombinacija tih dviju metoda, tako da opcijom snimanja prvo dobijemo “kostur”, a nakon toga manipulacijom i dodavanjem koda do kraja izradimo testnu skriptu. Human vs. machine Vjerujem da je već jasnije koliko se automatizacijom dobije na brzini testiranja s obzirom na to da jednom snimljenu skriptu možemo koristiti zauvijek. Što se više testnih slučajeva automatizira, to je proces testiranja kvalitetniji i pouzdaniji. Ručni proces regresijskog testiranja troši puno vremena, a problem je posebno izražen kod agilnog razvoja, gdje su česte isporuke nove verzije programskog rješenja. Automatizacijom tog procesa postižu se goleme uštede na vremenu, a posebnu snagu daju i unaprijed definirani rasporedi izvršavanja testova (test schedule). Na taj se način kod agilnog razvoja na kraju svake iteracije mogu automatski izvršavati regresijski testovi (npr. preko noći), a tester rezultate može pregledati sutra ujutro ili ih čak dobiti e-mailom. Budući da automatizacija testiranja donosi značajnu uštedu vremena potrebnog za testiranje, kvalitetniji proces testiranja, poboljšanje kvalitete proizvoda koji se isporučuje i u konačnici veće zadovoljstvo korisnika/naručitelja samim proizvodom, ne čudi što današnji trendovi idu u smjeru razvoja automatizacije testiranja. Omjer troškova ručnog i automatiziranog testiranja posebice u kulturološkom dijelu, ali smo jako zadovoljni što možemo istaknuti da smo puno toga naučili na tom području od indijskih partnera, a i neke smo naše tradicije i običaje podijelili s njima – na veliko obostrano zadovoljstvo. Jeste li znali što je to Festival svjetla – Divali, Festival boja – Holi festival, tko je pripadnik koje kaste – kako se to lako uoči iz prezimena, da ima pojedinaca koji imaju samo jedno ime (nemaju prezimena) itd. – sve se to može naučiti preko weba, međutim puno je to ugodnije i zanimljivije čuti uživo Iza vas je već gotovo godina dana suradnje s CROZ-om, kako biste ocijenili dosadašnji zajednički rad i kako vidite budućnost? Prilikom procesa nabave gdje smo birali nove strateške partnere uzeli smo u obzir potencijalne partnere u regiji, a tako i šire. Nakon što je odrađen uži izbor, krenuli smo i s ProofofConceptom, gdje smo potencijalnim partnerima dali manje projekte kako bismo osim financijske odradili i tehničku evaluaciju. Smatram da CROZ može biti ponosan što je nakon takvog detaljnog procesa izabran za našeg strateškog partnera – posebice što se osim financijskog dijela uvelike gledala tehnička evaluacija s naglaskom na kvalitetu isporuke. U svakom početku, pa tako i u našem strateškom partnerstvu, bilo je dosta dječjih bolesti.Tu činjenicu ne treba skrivati, čak štoviše, to je samo pokazatelj da smo ozbiljno pristupili ovoj dugoročnoj suradnji – bilo bi čudno da je sve išlo glatko. Međutim, izrazito dobrom međusobnom komunikacijom i koordinacijom rješavali smo sva otvorena pitanja u hodu te sa zadovoljstvom mogu reći da danas imamo suradnju na zadovoljavajućem nivou.Tome uvelike pridonosi postavljen governance model s naše strane, koji uključuje standardizirano izvještavanje, redovitu komunikaciju i eskalacijski model – gdje vas moram pohvaliti na ozbiljnom i profesionalnom pristupu. Istraživajući ovaj dio IT industrije, došao sam do spoznaje da je zadovoljstvo internih korisnika sa strateškim outsourcing partnerima tim veće što je bolji governance model i relationship management. S obzirom na to da ste vi tu pokazali izrazitu profesionalnost, a uz to i dokazali da možete pružiti kvalitetnu isporuku, budućnost vidim kao zaista dugoročnu suradnju i partnerstvo. RUČNOTESTIRANJE AUTOMATIZIRANOTESTIRANJE Vrijeme Ljudi Infrastruktura Alati Obučavanje Darko Marijančić CROZd.o.o. (koordinator CROZ-ova testnogtima)
12 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Performansno testiranje P erformansno testiranje je razina testiranja web aplikacija ili serverski orijentiranih aplikacija kojoj je svrha utvrditi kako se aplikacija ponaša pod definiranim opterećenjem i ispunjava li očekivanja. Izvršavanje performansnog testa je procedura koja imitira konkurentne korisnike i opterećuje sustav, prati ponašanje sustava te prikuplja podatke i metrike o opterećenom sustavu, koje ćemo poslije koristiti za analizu ponašanja i donošenje zaključaka o performansama aplikacije ili sustava. Fokus performansnog testiranja je: • brzina rada aplikacije – izmjeriti odzivna vremena aplikacija • skalabilnost – odrediti maksimalan broj konkurentnih korisnika koje aplikacija može uspješno poslužiti • stabilnost – provjeriti koliko je aplikacija stabilna pod velikim opterećenjem Performansno testiranje • propusnost – izmjeriti može li aplikacija obraditi zahtijevanu količinu podataka i transakcija u planiranom vremenu • definirati minimalnu i optimalnu konfiguraciju sustava na kojem aplikacija radi. Cilj performansnog testiranja nije otkriti funkcionalne greške, jer aplikacija namijenjena performansnom testu mora biti funkcionalno ispravna, nego ukloniti performansna uska grla aplikacije i podesiti sustav na kojem aplikacija radi. Zašto radimo performansne testove? Poslije isporuke nove aplikacije ili nove funkcionalnosti mnogi su timovi iskusili probleme s performansama aplikacije. Postavlja se pitanje zašto performansni testovi nisu pripremljeni i izvršeni na vrijeme. Često je razlog nedostatak vremena, no ponekad je razlog i nedostatak znanja i iskustva u izvođenju performansnih testova. Tipoviperformansnogtestiranja • Load testing – provjerava odzivna vremena kritičnih poslovnih scenarija i transakcija te provjerava jesu li u okvirima očekivanja • Stress testing – provjerava maksimalno opterećenje i broj istovremenih korisnika za koje se aplikacija još uvijek uspješno odziva • Volume testing – provjerava propusnost i kapacitet sustava, može li aplikacija obraditi zadanu količinu podataka i transakcija u definiranom vremenu • Longevity ili Endurance – provjerava ponašanje aplikacije i identificira probleme koji će se pojaviti ako je aplikacija duže vrijeme izložena konstantnom vršnom opterećenju Piše: Miroslav Zaninović Hoće li nova funkcionalnost utjecati na brzinu rada aplikacije? Može li aplikacija izvršiti 5 000 transakcija u jednom satu? Hoće li se aplikacija odzivati unutar 5 sekundi ukoliko je opteretimo s 500 istovremenih korisnika? Hoće li 5 000 konkurentnih sesija srušiti sustav? Mnogo je pitanja na koje ne možete odgovoriti bez performansnog testiranja.
FYI by CROZ / broj 18 /svibanj 2015. | 13 Performansno testiranje | tema broja Performansne testove radimo da bismo osigurali zahtijevanu brzinu, skalabilnost, stabilnost i propusnost. Važno je da performansni test otkrije performansne probleme i uska grla u radu aplikacije na vrijeme, kako bi programeri i sistemski inženjeri što prije uklonili ili unaprijedili performanse aplikacije i infrastrukture koje aplikacija koristi. Provođenje performansnih testova se laiku na prvu može učiniti presloženim, no u konačnici to je jedini način za brzo identificiranje performansnih problema i uskih grla, te je znatno jeftinije od njihova uklanjanja ako takvo testiranje izostane. Proces performansnog testiranja Planiranje i dizajn testova predstavlja definiranje ciljeva koje moramo postići performansnim testom. Prvenstveno definiranje propusnosti sustava i maksimalno očekivanih vremena odziva aplikacije. Te će nam informacije pomoći da odredimo broj konkurentnih sesija ili korisnika, kapacitet infrastrukture potrebne za generiranje workloada i kreiranje scenarija izvršavanja testova. Workload je scenarij koji će se izvršavati nad sustavom (transakcije i frekvencija izvršavanja transakcija, testni podaci i kriteriji prikupljanja podataka) i mora biti što sličniji stvarnim korisničkim scenarijima, koji će ispitati i potvrditi rizike. Kreiranje i provjera testova predstavljaju snimanje i pripremu kritičnih transakcija i scenarija koje performansni test treba izvršiti. To je ujedno i najzahtjevniji dio procesa jer u toj fazi moramo osigurati pouzdanost, ispravnost i repetitivnost svakog testa, te osigurati upravljanje zavisnim podacima kroz cijeli scenarij testa. Workload mora biti pripremljen tako da zadovoljava zahtijevanu propusnost, ali ujedno mora imitirati realnu interakciju sa sustavom i optimalno koristiti infrastrukturu predodređenu za performansno testiranje. Priprema testnog okruženja predstavlja pripremu odgovarajuće verzije aplikacije za test, konfiguraciju infrastrukture potrebne za performansni test, pripremu testnih podataka, pripremu alata za praćenje testiranog sustava i instaliranje potrebnih licenci. Kako vam CROZ može pomoći u performansnom testiranju? CROZ-ov je testni tim kroz godine razvoja aplikacija stekao zavidna znanja u pripremi i izvršavanju performansnih testova u različitim okruženjima i na različitim tehnologijama. Spremni smo vam pomoći prilikom planiranja i određivanja kapaciteta performansnih testova, odabira optimalne infrastrukture za izvršavanje testova, pripreme i dizajna testova te izvršavanja i tumačenja rezultata testiranja. Svojim vam znanjem i iskustvom stojimo na raspolaganju i pri odabiru adekvatnih alata za performansno testiranje. Proces performansnog testiranja Infrastruktura za performansno testiranje obično se sastoji od konzole koja služi za upravljanje testom i opterećenjem te agenata koji simuliraju krajnje korisnike aplikacije. Izrada i priprema workloada uvelike ovisi i o dostupnoj infrastrukturi i broju dostupnih agenata. Izvršavanje performansnih testova i prikupljanje metrika odvija se uvijek u nekoliko iteracija, svaka iteracija otkriva nove performansne rizike koji se postupno uklanjanju dok u konačnici aplikacija ne ispuni zahtjeve i postigne željenu propusnost. Rezultati performansnog testa moraju omogućiti donošenje odluka i zaključaka o performansama. Minimum koji rezultati moraju pružiti jesu prosječno, minimalno i maksimalno vrijeme odziva, devijacija podataka te postotci uspješno i neuspješno obrađenih zahtjeva. IBM Rational Performance Tester Kako bismo vam približili proces performansnog testiranja, objasnit ćemo ga kroz praktičan primjer upotrebe alata koji najčešće koristimo. IBM Rational Performance Tester (RPT) alat je za kreiranje, izvršavanje i analizu rezultata performansnih testova koji pokriva velik raspon protokola i tehnologija, stvoren za provjeru skalabilnosti i pouzdanosti web i enterprise aplikacija. Alat uključuje funkcionalnosti za snimanje i uređivanje testova, izradu scenarija i workloada za izvršavanje testova, izvještavanje i mehanizam za izvršavanje testova. IBM Rational SaaS (Software as a Service) Ukoliko imate projekt na kojem postoji potreba za performansnim testiranjem, a ne namjeravate investirati u uvođenje alata, CROZ vam može ponuditi usluge najma licenci kroz program IBM Rational SaaS (Software as a Service). Putem SaaS programa pružena vam je mogućnost najma licenci na ograničeno vrijeme, čime ćete imati osjetno niže troškove licenci, nećete morati investirati u infrastrukturu, a bit ćete u mogućnosti postići zadane ciljeve. SaaS program omogućuje vam najam licenci za Rational PerformanceTester, IBM AppScan i Rational Quality Manager (IBM rješenje za upravljanje testiranjem). Usluge pripreme testiranja možete, naravno, s punim povjerenjem povjeriti CROZ-ovim stručnjacima.
14 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Performansno testiranje Za vašu smo instituciju samo ove godine radili nekoliko performansnih testova. Bilo je tu aplikacija koje razvija CROZ, ali i aplikacija drugih dobavljača. Možete li nam reći koji su vam motivi pri odlučivanju što ćete i kada performansno testirati? Sve aplikacije se performansno testiraju prije produkcije. Kad neka aplikacija počinje svoj produkcijski život, onda želite biti sigurni da će izdržati nalet svih korisnika i sve njihove zahtjeve, upite i transakcije. U slučaju da aplikacija ima prekide ili Performansno testiranje u Raiffeisen banci Alan-Mirko Poldrugač Raiffeisenbank Austriad.d. (direktorSD organizacije, procesaiprojekata) ispade u svom radu, to nas može koštati znatno više od onog što uložimo u testiranje prije produkcije. Drugo je pitanje kada pristupiti performansnom testiranju?Tu treba biti praktičan i pogoditi pravo vrijeme. Ukoliko to bude previše rano, dok aplikacija još nije spremna za integralni test, onda ćete vjerojatno morati ponoviti test nešto kasnije, neposredno prije produkcije. Opet, kad je to previše kasno, odmah prije produkcije, onda nećete imati vremena popraviti stvari ukoliko aplikacija padne na testu. Kao što je to s većinom stvari u životu, morat ćete pogoditi pravu mjeru stvari, niti prerano niti prekasno. Po našem iskustvu, najbolja mjera je na početku integralnog testa. Kakva je bila aplikacija koju smo zadnju testirali i kakvi su bili rezultati testiranja? Zadnje testirana aplikacija je bio novi sustav za naplatu potraživanja. Uredno je prošao na performansnom testu, odnosno nismo ga uspjeli srušiti iako smo pokušavali s nekoliko trikova. Kasnije, u produkciji, opravdao je očekivanja i uredno radi bez zastoja, sukladno rezultatima koje smo imali na testiranju. Ipak, moram naglasiti da se ovdje radi o drugoj verziji tog sustava i da smo očekivali da neće biti problema s performansama. Kad smo radili test prve verzije istog sustava, prije godinu i pol, tada smo uspjeli srušiti sustav i morali smo raditi ozbiljne preinake kako bi isti zadovoljio performansne uvjete za produkcijski rad. Koristili ste Software as a Service (SaaS) model licenciranja alata, kakva su iskustva? Iskustva su pozitivna. U slučajevima kad povremeno imate potrebu za korištenjem određenog alata i odgovarajućih znanja, onda je bolje“unajmiti” komplet tog alata i podrške na određeno vremensko razdoblje.Takva usluga uključuje zadnju verziju alata i podršku osobe koja ima iskustvo s traženim područjem. Na taj način izbjegavate probleme s održavanjem verzija, odnosno taj dio prebacujete na pružatelja usluge. Opet, ukoliko redovito koristite takav alat u svakodnevnim aktivnostima, onda je dobro razmisliti i izračunati isplativost kupnje i održavanja istog u vlastitim redovima. RPT pomoću snimalice prometa omogućuje brzu pripremu testova neovisno o tehničkim i poslovnim kompetencijama testera. Za pripremu i snimanje testova potreban je samo web preglednik ili desktop klijent koji komunicira sa serverom, za ostalo će se pobrinuti RPT. Snimljeni će se test prikazati u editoru kao stablo zavisnih requesta i responsa, spreman za uređivanje i izvršavanje. Snimljeni test se također može prikazati u web pregledniku kako bismo mogli vizualno provjeriti izgled stranica i podataka korištenih za vrijeme snimanja testova. Workload Schedule vam kroz svoje opcije omogućava kombiniranje različitih testova u jedinstveni workload scenarij, koji je u mogućnosti generirati realno korisničko opterećenje te promjenu i ugađanje vršnog opterećenja za cijelo vrijeme trajanje testa. Veliko opterećenje zahtijeva i infrastrukturu koja će moći generirati takvo opterećenje, a RPT vam korištenjem agenata omogućava optimalno iskorištavanje vaše infrastrukture. RPT podržava data-driven testove, čime omogućava realne testove s realnim podacima. Svaki korisnik ili sesija koji RPT koristi u tom slučaju koristi jedinstvene testove. Alat također prilikom snimanja sam otkriva potencijalne kandidate za zamjenu s realnim podacima. Na kraju treba spomenuti izvještavanje koje nam omogućava da provjerimo jesmo li zadovoljili željene zahtjeve i postigli traženu skalabilnost. Prikupljajući maksimalne, minimalne i prosječne vrijednosti, računajući prosjeke i devijacije, RPT nam daje uvid u zdravlje servera, aplikacije i transakcija. Dobiveni se izvještaji mogu uspoređivati kako bismo saznali koliko su konfiguracije utjecale na performanse sustava te eksportirati i kao takvi priložiti kao završni izvještaj o testiranju. Zaključak Performansni testovi su neophodni prilikom objavljivanja novih softverskih produkata, osobito servisa koji su javno dostupni. Troškovi performansnog testiranja ponekad nisu mali, no neusporedivo su manji od troškova izgubljenog povjere- nja ili propalih infrastrukturnih investicija. Ne dopustite da se to i vama dogodi. Pregled Rational Performance Tester infrastrukture Rational Performance Tester Performance Tester Agents System UnderTest
Prema zadnjem istraživanju tvrtke Aumcore, godišnji je rast tržišta mobilnih aplikacija u posljednjih nekoliko godina otprilike 30%, uz očekivanu vrijednost u 2015. godini od 25 milijardi dolara. (Izvor: www.aumcore.com) FYI by CROZ / broj 18 /svibanj 2015. | 15 Testiranje mobilnih aplikacija | tema broja U današnje vrijeme kada tržište mobilnih aplikacija eksponen- cijalno raste, konkurentnost je iznimno bitna. Kako bismo ostali konkurentni na tržištu, potrebno je u što kraćem roku izbaciti kvalitetan proizvod na tržište. Da bi se osigurala kvaliteta proizvoda, potrebno je razraditi pametnu strategiju provođenja testiranja. S obzirom na iznimno veliku ponudu mobilnih uređaja, testiranje mobilnih aplikacija predstavlja pravu avanturu u kojoj je potrebno suočiti se s brojnim izazovima, od kojih su najveći: • različiti OS-ovi i pripadajuće verzije • hardverske razlike uređaja • brze i učestale nadogradnje aplikacija. Testni tim nije u mogućnosti garantirati da će neka funkcionalnost koja radi na jednom uređaju raditi i na nekom drugom, čak i u slučajevima kada je riječ o sličnim mobitelima s recimo istim operacijskim sustavom. Razlog tomu može biti postojanje razlika u rezoluciji ekrana, CPU-u, memoriji, kao i drugačiji hardver. Strategija testiranja U cilju lakšeg svladavanja svih izazova potrebno je definirati kvalitetnu strategiju testiranja, koja uključuje: • odabir ciljanih uređaja (iOS/Android, tablet/smartphone, različite veličine ekrana, CPU, memorije...) • automatizaciju testiranja radi neminovne nadogradnje aplikacija novim funkcionalnostima i OS-a u cilju održavanja konkurentnosti te u konačnici i samog smanjenja troška regresijskog testa kojim potvrđujemo da prije implementirane funkcionalnosti s novom nadogradnjom i dalje rade kako je očekivano • odabir različitih tipova testiranja za funkcijsko i nefunkcijsko testiranje, kao što su npr.: • testiranje korisničkog iskustva (usability testing), što uključuje vidljivost na odabranom jeziku, navigaciju između ekrana, verifikaciju implementiranih funkcionalnosti online i offline, feedback kod interakcije s aplikacijom – npr. ako je korisnik preuzeo aplikaciju, na mobitelu bi se trebala javiti poruka ili bi se aplikacija trebala početi instalirati na uređaj • funkcijsko testiranje (functional testing) predstavlja testiranje ispravnosti pojedinih funkcionalnosti aplikacije i odgovara li implementacija korisničkim zahtjevima • testiranje kompatibilnosti (compatibility testing) podrazumijeva validaciju aplikacije na različitim uređajima s različitim operacijskim sustavima, veličinama ekrana i različitim rezolucijama. Također provjerava kako aplikacija radi s ostalim aplikacijama • operativno testiranje (operational testing) podrazumijeva testiranje aplikacije u slučaju da se baterija isprazni, mogućnosti gubitka podataka u slučaju upgradea, dostupnost aplikacije u slučaju da korisniku počne zvoniti alarm, primi poziv, poruku • mrežno testiranje (network testing) – testiranje ponašanja aplikacije u različitim mrežnim uvjetima koje generiraju specijalizirani alati. Pišu: Martina Bajza i Ivana Skorupan Testiranje mobilnih aplikacijaU ovom tekstu govorimo o osnovnim smjernicama za testiranje kvalitetnih mobilnih aplikacija kako bismo pojačali konkurentnost na jednom od najbrže rastućih tržišta današnjice. Opis strategije testiranja STRATEGIJA TESTIRANJA Provođenje različitih tipova testiranja Automatizacijatestiranja Definiranje ciljane skupine uređaja
16 | FYI by CROZ / broj 18 / svibanj 2015. tema broja | Testiranje mobilnih aplikacija Uređaji Nakon definiranja strategije testiranja mobilne aplikacije potrebno je odrediti način testiranja, odnosno uređaje na kojima će se provoditi testiranje. Fizički uređaji Testiranje je aplikacije na ciljanoj skupini uređaja najpouzdanije i najtočnije, a posebice za testiranje korisničkog iskustva (user experience). Naravno, s obzirom na broj uređaja koji se nalaze na tržištu, od kojih je samo Androida otprilike 20 000, investicija u uređaje je iznimno visoka. Kako je korisničko iskustvo presudno za uspjeh mobilne aplikacije na tržištu, nužna je određena investicija u fizičke uređaje. Emulatori Emulator predstavlja softver koji se pokreće na računalu i oponaša fizički uređaj (vidi sliku Android emulatora). Prije samog pokretanja emulatora potrebno je instalirati Android SDK (Software Development Kit) i definirati AVD (Android Virtual Device), kojim se definira hardver kao što je RAM, ima li uređaj zaslon osjetljiv na dodir, fizičku tipkovnicu, kameru... Moguće je kreirati više AVD-ova za potrebe testiranja na više uređaja. Emulatori su uglavnom besplatni i na njima je moguće raditi performansno testiranje, funkcijsko testiranje i stres- test. Emulatori mogu poslužiti i za automatizaciju testiranja jer se na njima mogu pokretati i automatske skripte. S obzirom na to da je za potpuno testiranje potrebno testirati aplikaciju na fizičkom uređaju, umjesto kupnje uređaja, korištenje uređaja od treće strane (vanjski servis) može biti korisno za provjeru rada aplikacije u uvjetima stvarnog svijeta. Cloud servisi za testiranje Cloud servisi za testiranje predstavljaju vanjski servis koji nudi uslugu najma uređaja, čime se testiranje mobilnih aplikacija znatno unaprijedilo. Uređajima na kojima će se raditi testiranje može se pristupiti na jednostavan način kroz web preglednik. Nakon prijave u servis tester odabire željeni fizički uređaj koji je trenutačno dostupan te započinje s procesom testiranja. Testiranje se može provoditi ručno, a određeni servisi nude mogućnost automatizacije testova kao i integraciju s testnim alatima. Također, moguće je paralelno vršiti testiranje na više uređaja. Cloud servisi, osim samog testiranja, pružaju i podršku za različite vrste izvještaja vezanih uz rezultate testa. Kompanije koje koriste cloud servise za testiranje mogu znatno smanjiti troškove testiranja zato što se takvi servisi mogu unajmiti po satu korištenja te je moguće mijenjati uređaje na kojima se radi test. Učinkovit odgovor na izazove testiranja mobilnih aplikacije nalazi se u optimalnom izboru ciljanih uređaja. Nadalje, kombinacijom testiranja na emulatorima i na fizičkim uređajima ili unajmljivanjem cloud servisa može se postići zadovoljavajuća pokrivenost testovima bez potrebe testiranja svih značajki na svakom uređaju. Maksimiziranje automatizacije testiranja učinkovit je način za ubrzanje procesa testiranja koji dugoročno omogućava smanjenje troškova. Testiranje mobilnih aplikacija u CROZ-u U duhu agilne metodologije, proces testiranja u CROZ-u prisutan je u svim fazama razvoja. Prije nego što započnemo rad na projektu, u suradnji s naručiteljima provodimo istraživanje o tome koji su ciljani korisnici sustava, kakvo je realno opterećenje sustava u stvarnom svijetu i slično. Na temelju tih informacija, vezano za testiranje, donosimo odluku o tome koje ćemo vrste testiranja provoditi, na kojim je fizičkim uređajima potrebno napraviti testiranje da bi se zadovoljile korisničke potrebe te koji je alat(i) najprikladniji za pisanje skripti za regresijsko i performansno testiranje. Testiranje počinje u najranijoj mogućoj fazi, a to znači već nakon implementacije prvog planiranog seta funkcionalnosti. Iskustvo je pokazalo da testiranje na emulatoru tijekom samog razvoja koje provodi razvojni tim koji razvija funkcionalnosti daje odlične rezultate. Na taj smo način postigli najranije moguće uočavanje nedostataka i potencijalnih defekata čija bi cijena ispravljanja u kasnijoj fazi razvoja bila puno viša, a ispravljanje kompleksnije. Nakon što razvojni tim testira funkcionalnosti, testiranje započinje testni tim. On provodi funkcijsko, istraživačko i operativno testiranje na emulatorima i na ciljanim fizičkim uređajima. Testiranja provodi na vlastitim fizičkim uređajima te prema potrebi na uređajima kolega koji su voljni sudjelovati u testiranju. Testiranjem na fizičkim uređajima postižemo rano uočavanje nedostataka u korisničkom iskustvu koje je presudno za krajnji uspjeh razvijenih aplikacija na mobilnom tržištu, koje je svakim danom sve veće i zahtjevnije. Na temelju rezultata dobivenih testiranjem donosi se odluka o spremnosti funkcionalnosti za isporuku korisniku. Razvojni i testni tim prilikom prvog testiranja nove funkcionalnosti koriste kriterije prihvaćanja koji su definirani za svaku funkcionalnost prije samog početka implementacije, ali i svoju kreativnost i maštu, te na taj način simuliraju velik broj realnih korisničkih scenarija. Nakon svake iteracije inicijalno raspisane kriterije prihvaćanja pretvaramo u detaljniju dokumentaciju za testiranje, koja stalnim nadopunjavanjem nakon svake nadogradnje zapravo postaje i službena dokumentacija za testiranje. Tako opisan proces testiranja ponavljamo sa svakom novom iteracijom kako bismo bili sigurni u ispravnost i stabilnost aplikacije, što osigurava kvalitetniju isporuku korisnicima. Android emulator
FYI by CROZ / broj 18 /svibanj 2015. | 17 ŠtojesustavzaIdentityGovernance? Dok se “klasični” sustavi za upravljanje identitetima i pristupom bave uglavnom upravljanjem životnim ciklusom identite- ta i pravima pristupa na tehničkoj razini, sustavi za Identity Governance nadgrad- nja su koja omogućuje organizacijama definiranje, pregled i izvještavanje (npr. za potrebe revizije) politika za upravljanje identitetima i pristupom te omogućuje mapiranje funkcija sustava za upravljanje identitetima i pristupom na zahtjeve koje postavljaju standardi s kojima organizacija treba biti usklađena. Prilikom utvrđivanja usklađenosti u nekoj organizaciji lanac događaja često izgleda kako je prikazano na slici. Najčešće je rezultat svega mukotrpno ručno prikupljanje podataka i višestruki sa- stanci na kojima će se “otkriti” koje ovlasti zapravo neka osoba ima. Osim toga, vrlo je teško otkriti opasne kombinacije ovlasti koje bi zaposlenik s početka priče mogao imati (npr. izradu i odobrenje ponude u jednoj osobi), kao i kada je tko za što bio ovlašten i trebaju li mu još te ovlasti. IBMSecurityIdentityGovernance Na scenu stupa IBM Security Identity Governance (ISIG), novo IBM-ovo rješenje za upravljanje (governance) identitetima i pristupom. IBM Security Identity Governance ima za cilj pomoći organizacijama da učinkovito upravljaju identitetima i pristupom aplikacijama i premoste jaz između potreba za usklađenošću, poslovnih aktivnosti i IT aktivnosti. Rezultat toga je smanjenje rizika od prijevara, konflikata uloga i ljudskih pogrešaka u provođenju poslovnih procesa. ISIG na upravljanje identitetima i pristupom gleda iz poslovne perspektive, čime se olakšava revizija i certifikacija korisničkih prava pristupa. Također, moguća je detaljna analiza uloga i prava i njihove usklađenosti s poslovnim procesima i pravilima. To je moguće zbog načina na koji ISIG upravlja ovlastima korisnika – sve ovlasti (permis- sions) koje korisnici na raznim sustavima imaju, pohranjuju se u ISIG-ov centralni re- pozitorij. Na temelju tih podataka mogu se identificirati uloge koje su poslovno bitne, rizici koji su povezani s njima i veza između ovlasti koje neki korisnik ima i njegove poslovne uloge (role). Te se informacije prika- zuju na pregledan način u sučelju kroz koje je jednostavnije ocijeniti rizike koji proizlaze iz prava pristupa korisnika, kao i rizike koji proizlaze iz pravila o razdvajanju dužnosti (Separation of Duties – SoD). Uključene su i funkcionalnosti, tzv. rudarenja uloga (role-mining), čime se mogu optimizirati poslovne uloge kako se poslovni procesi mijenjaju i unapređuju. ISIG promatra SoD kontrole iz perspektive poslovnog svijeta (i revizora) i temelji se na predefiniranim aktivnostima koje pripadaju poslovnim procesima, a ne, kako je to do sada često bilo, iz perspektive IBM Security Identity Governance Zamislite situaciju da u vašoj tvrtki postoji zaposlenik koji je radio u odjelu IT podrške, nakon toga je radio kao sistemski inženjer, da bi naposljetku završio u odjelu prodaje i marketinga. Nagradno pitanje: znate li koja pristupna prava ta osoba treba imati prema važećim politikama, a koje ovlasti na vašem IT sustavu ta osoba zaista ima?Piše: Igor Sokač Lanac događaja prilikom utvrđivanja usklađenosti IBM Security Identity Governance | tehnologije i trendovi
Consulting@CROZ Agile Team Bootcamp 18 | FYI by CROZ / broj 18 / svibanj 2015. pojedinih ovlasti na aplikacijama koje su više tehničke prirode. Poseban je naglasak pritom stavljen na ERP sustave – primarno SAP, za koje postoji podrška za upravljanje ulogama s predefiniranim pravilima koja sežu do razine SAP transakcija i autorizacij- skih objekata. Konflikti se mogu jednostavno otkriti i opisati u poslovnom kontekstu koristeći pristup temeljen na modeliranju aktivnosti. Ocjenjivanje rizika može biti dio workflowa za zahtjev pristupa, gdje specifični konflikti mogu biti eskalirani ili odobreni, čime se pozornost usmjerava na područja s najvećim rizikom. Prava pristupa vrlo su često privremena (npr. samo tijekom projekta) i potrebno ih je periodički provjeriti i recertificirati ukoliko su još uvijek potrebna. ISIG pruža funkcionalnosti organiziranja recertifikacijskih kampanja koje će automatski pokrenuti procese revizije i upravljati workflowom za koordinaciju odobrenja prava pristupa i recertifikacije. Na jednom preglednom ekranu menadžeri mogu odobriti ili opo- zvati prava pristupa, provjeriti prekršaje u razdvajanju odgovornosti i pratiti recertifi- kacijske kampanje u cijeloj organizaciji. ISIG pruža mogućnost da zaposlenici sami, iz online kataloga, zahtijevaju nove ovlasti. Njihovi se zahtjevi unose u automatski mehanizam za odobravanje, koji se, ovisno o riziku, na različit način odnosi prema zahtjevima ovisno o procijenjenom riziku. S tehničke strane, rješenje se temelji na bazi podataka kao centralnom repozitoriju Integracija s Identity Management alatima ISIG se može dobro integrirati s IBM Security Identity Managerom (ISIM) putem integracijskog adaptera (ISIGADI) temeljenog na IBM Security Directory Integratoru.Taj adapter omogućuje sinkronizaciju podataka o entitetima (ljudi, korisnički računi, servisi, role, grupe i organizacije) između IBM Security Identity Governancea i IBM Security Identity Managera. Pritom ISIM preuzima ulogu izvršitelja promjena na servisima, a ISIG ulogu mozga cijele priče upravljanja identitetima. Postoji i posebni paket (IBM Security Identity Governance and Administration) koji objedinjuje oba produkta pod jednim partnumberom. i web aplikacijskom serveru uz nekoliko glavnih funkcionalnih modula: • Accessrequestmodul, koji pruža na- predne mogućnosti upravljanja tijekom zahtjeva za pristupom te samoposluž- nim mogućnostima (kada korisnik sam zahtijeva neki oblik pristupa za sebe) • Accessgovernancemodul, koji pruža funkcionalnosti razdvajanja ovlasti, usklađenosti sa SAP sustavima te revizije prava pristupa • Accessinteligencemodul, koji pruža mogućnosti analize uloga (role analysis) i “rudarenja” uloga (role mining). Zaključak ISIG predstavlja korisnu nadogradnju na postojeće IBM-ove (i ne samo IBM-ove) produkte za upravljanje identitetima i pristupom koja omogućuje da se upravljanje identitetima vrši na višoj razini od Ugrađene kontrole rizika i pravila za razdvajanje dužnosti one koja je sada uobičajena (tipično razina sistemskih administratora ili operate- ra), čime je olakšano praćenje stvarnog stanja korisničkih uloga i ovlasti, olakšano postizanje usklađenosti sa standardima i postavljena osnova za lakšu detekciju i upravljanje rizicima. Početni ekran za IBM ISIG administraciju tehnologije i trendovi | IBM Security Identity Governance Agile Team Bootcamp objedinjuje dva različita pogleda na izgradnju agilnog razvojnog tima – tehnološki i meto- dološki pogled. Kroz vlastito iskustvo naučili smo da efikasni timovi ne samo da koriste prave alate za svoj posao nego se i ugodno osjećaju u korištenju tehničkih i metodoloških agilnih praksi. Vjerujemo da uspješni timovi razumiju vlasnike poslovnih zahtjeva i kvalitetno komuniciraju s njima, kao i da kvalitetno planiraju uvažavajući vlastite mo- gućnosti u danim uvjetima, efikasno i transparentno isporučuju vrijednost korisnikuikritičkiseosvrćunarezultate vlastitog rada. Da bi sve to postigli potrebna im je kombinacija najboljih praksi koje će upoznati kroz Agile Team Bootcamp. Ova je usluga skrojena za razvojne timove koji žele unaprijediti svoj način rada kroz primjenu tehničkih i metodo- loških agilnih (najboljih) praksi. Više informacija na www.croz.net/consulting
P oslovni zahtjevi u okviru postoje- ćih servisa i usluga koje Fina pru- ža, osim uobičajenih razina visoke raspoloživosti koja se ostvaruje s redundantnim komponentama u IT infrastrukturi, podrazumijevaju visoku ras- položivost servisa i u slučaju ispada iz rada cijele IT infrastrukture na lokaciji u Zagrebu. Stoga je u Fini pokrenut niz aktivnosti koji je za cilj imao izgradnju IT infrastrukture na pričuvnoj lokaciji radi preuzimanja poslovnih servisa ukoliko dođe do težeg ispada i prekida rada servisa na lokaciji u Zagrebu. Prije svega pristupilo se podizanju pričuvne infrastrukture za kritične poslovne servise koji su od najvećeg značenja za cjelokupno poslovanje Fine. Budući da se kod većine kritičnih servisa u osnovi infrastrukture nalazi IBM-ov mainframe sustav, traženo je odgovarajuće kvalitetno i provjereno rješenje koje može zadovoljiti definirane zahtjeve upravo na toj platformi. Kvalitetno i provjereno rješenje pronašli smo u IBM-ovoj tehnologiji pod nazivom Geographically Dispersed Parallel Sysplex (GDPS). GDPS je najraširenije i najkvalitetnije rješenje za kontinuiranu raspoloživost u području IBM-ove mainframe tehnologije. Na tržištu je već oko 17 godina i kontinuirano se razvija kako se mijenjaju i okolnosti u kojima je potrebno svakodnevno ostvariti kontinuitet poslovanja. Diljem svijeta GDPS je implementiran na preko 500 mainframe instalacija. Fina je prvi korisnik GDPS rješenja u Hrvatskoj. Zapravo je riječ o skupnom nazivu za nekoliko rješenja koja pojedinačno rješavaju različite zahtjeve za visokom raspoloživosti koji se mogu opisati s RTO-om (koliko je vremena potrebno da se nakon ispada sustav vrati u prvobitno stanje) i RPO-om (koliko je maksimalno dopušteno vrijeme u prošlosti u koje se vraćaju podaci). Stanje prije projekta Slika 1 prikazuje mainframe infrastrukturu Fine prije projekta implementacije GDPS rješenja. Na primarnoj se lokaciji nalaze dva z9-109 poslužitelja starije generacije koji rade povezani u parallel sysplex konfiguraciji. Parallel sysplex je ukratko konfiguracija koja omogućuje da se dva ili više mainframe poslužitelja sa z/OS operativnim sustavima povežu u cluster kombinaciju i djeluju kao jedan poslužitelj. Na taj se način s jedne strane ostvaruje veća procesorska snaga i obradna moć, dok se s druge strane ostvaruje visoka raspoloživost. Poslužitelji su spojeni na enterprise diskovne podsustave između kojih je uspostavljena replikacija podataka. Budući da je poslužitelj na DR lokaciji dosta slabiji od poslužitelja na primarnoj lokaciji, u slučaju ispada ne može preuzeti sve servise, nego samo one najnužnije. Stanje nakonprojekta Slika 2 prikazuje stanje nakon projekta. Na primarnoj i DR lokaciji nalazi se po jedan mainframe poslužitelj spojen na enterprise diskovni podsustav, a između kojih je uspostavljena sinkrona replikacija. Svi se poslovni servisi izvode na poslužitelju na primarnoj lokaciji. Poslužitelj na DR lokaciji je manjeg kapaciteta, ali u slučaju ispada primarne lokacije automatski se aktiviraju dodatni kapaciteti računala i on je sposoban preuzeti sve servise s primarne lokacije. Izvedba projekta Projekt je izveden u suradnji s tvrtkama SV Group i IBM Hrvatska. Implementacija je realizirana u dvije faze. U prvoj je Slika1– Fininamainframe infrastruktura prije implementacije GDPS rješenja FYI by CROZ / broj 18 /svibanj 2015. | 19 GDPS u Fini | projektne priče Implementacija disaster recovery rješenja u Fini Piše: Dejan Cepetić Projekt iz naslova jedan je od većih IT projekata koji se u posljednjih nekoliko godina realizirao u Financijskoj agenciji (Fina) i vrlo je važan za tamošnju buduću IT infrastrukturu kao i za kvalitetu IT usluga koje Fina može ponuditi na tržištu. Ponosni smo što smo i kao nositelji projekta i kao izvođači dijela usluga pridonijeli uspješnoj realizaciji implementacije i time još jednom pokazali sposobnost odrađivanja velikih enterprise projekata u domeni sistemske integracije. Fina - primarna lokacija Fina - DR lokacija ParallelSysplex z9-109 z9-109 z900 Tape Unit ESCON, FICONTape Library enterprise storage enterprise storage enterprise storage sinkrona replikacija asinkrona replikacija
20 | FYI by CROZ / broj 18 / svibanj 2015. rubrika | nadnaslovprojektne priče | GDPS u Fini ZbogčegajeFinaodlučilaimplementiratiGDPS rješenje?Kojisuglavniciljeviprojekta? Finajeprijedvijegodinenapravilapričuvnulokacijuu Zabokujersmohtjeliimplementiratiovakvorješenjekako bismododatnoosiguralikontinuitetposlovanja.Htjelismo bitisigurnidanikakvenepredviđenesituacijenećedovestido ispadasustava,odnosnodausvakomtrenutkusvimnašim korisnicimajamčimokvalitetnuiod0do24satadostupnu uslugu.NakonimplementacijerješenjauZabokunapravljeni sutestovi,prviputnakondugogodinasvisusustavi kompletnougašenitesuseponovnopodizali.Istotakosu napravljenitestoviprelaskasvihsustavanapričuvnulokaciju inakontoganjihovpovrataknasustaveuFinuuVukovarskoj. Testiranjasuuspješnoprovedena. Ciljnamjebiodanavisokoraspoloživimsustavimaimamo našeservisekojisunaraspolaganjukorisnicimaidastvarno osiguramodasuimdostupniod0do24. Finajejedanodvodećihpružateljauslugaujavnom ifinancijskomsektoru,štozakorisnikevašihusluga predstavljaovounaprjeđenjeinfrastrukture? Samisukorisnicinašihuslugadobilivećusigurnost, međutimvažnojenaglasitiidajeFinadobilavećusigurnost daćesvimsvojimkorisnicimamoćipružitisveštooniočekuju. KorisnicimajeFinaidosadapružalakvalitetnuidobruuslugu, asadajesvezajednopodignutonajednuvišurazinu. PrvistekorisnikGDPSrješenjauHrvatskoj.Jeliono ispunilovašaočekivanja?Kakvisudaljnjiplanovi? Svanašaočekivanjasuispunjena.Mislimdasusviuvidjeli kojejepromjenedonijelaimplementacijaGDPSrješenjau odnosunadosadašnjirad.Vidimodamožemoinekenaše internestandardepremainformaticijošpoboljšati,dićinaviši nivo,štojeupravoovorješenjeomogućilo.Uplanuimamojoš nekesustaveprebacitiuZabok.Tamovećsadimamoisustave kojinisuvezanizamainframeimožemorećidasveskuparadi jakodobro. Štosetičedaljnjihplanova,namjeranamjejedandio našihresursaiznajmljivatiidrugimkorisnicima.Nadamoseda ćekorisnicitunašuprednostiprepoznatisobziromnatoda smojedniodrijetkihkojiimajupravupričuvnulokaciju. Kakostezadovoljnisamimprojektom?Jesteli zadovoljniposlomkojisuobaviliCROZipartneri? Prilikomrealizacijeprojektanijebilonikakvihproblema. Zapravo,dosadasCROZ-omnismoimaliproblemanina kojemprojektu,patakoninaovom.Svisuposloviitestiranja odrađeniprofesionalnoinavrijeme.Onoštosmoočekivaliod CROZ-aipartnera,tosmoidobili. ŽeljkoPavić Financijska agencija (članUprave) fazi napravljena priprema okoline za implementaciju GDPS rješenja, dok je u drugoj fazi izvršena sama implementacija i testiranje rješenja. U sklopu pripreme i hardverske i softverske okoline su prilagođene za implementaciju GDPS rješenja. Budući da su prije implementacije z/ OS i z/VM okoline bile raspoređene na dva stara poslužitelja, potrebno je bilo napraviti konsolidaciju postojećih okolina na jedan novi poslužitelj, što je zahtijevalo opširno planiranje hardverskih definicija. Nakon definiranja i implementacije novih hardverskih definicija na novim posluži- teljima, sve su okoline preseljene na novi zEC12 poslužitelj. Diskovni su podsustavi obnovljeni te je time omogućeno korištenje većeg diskovnog kapaciteta i ostvareni su preduvjeti za konfiguraciju podatkovne replikacije između diskova kao jedne od osnova GDPS rješenja. Priprema softverske okoline obuhvatila je podizanje z/OS i z/VM operativnih sustava na zadnje dostupne verzije softvera. U osnovi GDPS rješenja je GDPS control code. Dobra je praksa da se prilikom implementacije rješenja instalira zadnja dostupna verzija control codea. Kao preduvjet za instalaciju zadnje verzije GDPS koda potrebno je bilo podići z/OS operativni sustav na verziju 1.13, a z/VM operativni sustav na verziju 6.2. Kako bi se s novom verzijom z/OS operativnog sustava uskladile i verzije ostalih glavnih produkata, verzija DB2 baze podataka podignuta je na v10, a verzija WebSphere Application Servera podignuta je na 8.5.5. Time je i za Finine aplikativne okoline omogućen razvoj aplikacija s aktualnim verzijama softvera kako bi se iskoristile nove funkcionalnosti koje nove verzije donose. Implementacija GDPS rješenja odvijala se u nekoliko koraka. U prvom koraku odrađene su radionice na kojima su prikupljene neophodne informacije vezane uz poslovne ciljeve, servisne zahtjeve, zacrtane tehnološke smjerove te procese oporavka poslovnih servisa. U drugom je koraku detaljno definirana implementacija rješenja, testna okolina, scenariji testiranja kao i kriteriji prihvaćanja. Nakon toga je pokrenuta instalacija potrebnog softvera zajedno s potrebnim predradnjama: • pripremljeni su kontrolni z/OS operativni sustavi • instalirani su i konfigurirani Tivoli NetView i Tivoli System Automation produkti • instaliran je i konfiguriran GDPS softver. U sljedećem koraku u testnoj okolini implementirane su potrebne GDPS funkcije te definirane veze između trenutačnih procedura upravljanja sistemima i GDPS automatiziranim aktivnostima. Nakon čega je izvršeno testiranje automatiziranog gašenja i startanja sistema te zavisnih servisa kao i ostalih GDPS funkcionalnosti. Nakon zadovoljavajućih testova pristupilo se implementaciji rješenja u produkcijskoj okolini. To je rješenje za Finu od velike važnosti jer je mainframe označen kao strateška IT platforma za razvoj novih i konsolidaciju postojećih Fininih servisa. S implementacijom tog rješenja omogućen je brzi oporavak svih postojećih kritičnih servisa te budućih servisa koji će se konsolidirati na mainframe platformi. Slika2–Finina mainframe infrastruktura poslije implementacije GDPS rješenja Fina - primarna lokacija Fina - DR lokacija ParallelSysplex zEC12 zEC12 Tape Library Tape Library sinkrona replikacija Enterprise disk Enterprise disk
FYI by CROZ / broj 18 /svibanj 2015. | 21 nadnaslov | rubrikaPeter Eeles | intervju K oliko je dizajna u području softverske arhitekture potrebno između definiranih zahtjeva i fizičke implementacije rješenja? Dizajn softverske arhitekture rezultira modelom informacijskog sustava prikazanim kroz perspektive na različitim razinama apstrakcije. Isto pitanje možemo postaviti i ovako: koliko detaljan model i koliko različitih perspektiva informacijskog sustava treba kreirati prije same implementacije rješenja? Do odgovora treba doći postavljanjem potpitanja: koja je svrha spomenutog modela i perspektiva? Informacijski je sustav složeni sustav u čijoj implementaciji sudjeluje velik broj ljudi zaduženih za pojedine aspekte sustava. Prikaz modela kroz određenu perspektivu razumljiv je skupini osoba odgovornim za implementaciju aspekata prikazanih kroz tu perspektivu. Prije same implementacije sustava bitno je postići razumijevanje između svih osoba odgovornih za implementaciju. Svrha softverske arhitektureCROZ-ovo dugogodišnje iskustvo u implementaciji složenih informacijskih sustava osiguralo nam je i pojedine bitne uloge u velikim projektima na zapadnom tržištu. Od studenoga 2014. godine imam priliku raditi kao dio tima u velikoj financijskoj kući u Velikoj Britaniji koji je zadužen za transformaciju cjelokupnog procesa dizajna informacijskih sustava i uvođenje novih alata. Na projektu radim s Peterom Eelesom, svjetskim autoritetom u području softverske arhitekture, jednim od dvojice autora knjige “The Process of Software Architecting”. Iskoristio sam tu priliku kako bih napravio ovaj intervju i podijelio s vama Peterova razmišljanja o softverskoj arhitekturi. Iz toga slijedi da je najkraći odgovor na postavljeno pitanje: potrebno je razraditi model i kreirati različite perspektive informacijskog sustava do razine koja će osigurati konsenzus među svim osobama odgovornim za implementaciju sustava. Možeš li nam reći koja je tvoja trenutačna uloga u IBM-u i nešto o svojoj karijeri? Trenutačno sam Executive IT Architect u IBM Cloud Worldwide Tiger Teamu. Pomažem klijentima da shvate relevantnost clouda u njihovu poslovanju te načine na koje im cloud arhitektura može pomoći da budu uspješniji. Prije toga bio sam u sličnoj ulozi u Rational brendu IBM-a, gdje sam pomagao organizacijama da nađu bolje načine razvoja i isporuke softvera. A još prije toga, vodio sam nekoliko inicijativa s klijentima, pomažući im da transformiraju svoj softverski razvoj. Uvijek sam bio i uvijek ću biti arhitekt! Kako to da je slika nebodera u izgradnji izabrana za naslovnicu knjige “The Process of Software Architecting”, koju si napisao u suradnji s Peterom Crippsom? Uz jasnu analogiju softverske i građevinske arhitekture, simbolika je u tome da je arhitekt odgovoran za važne odluke u dizajnu. Arhitekt se obično ne uključuje u razinu predubokih detalja (iako će i to učiniti ako je potrebno), ali osigurava da su svi osnovni elementi arhitekture na pravom mjestu. Također bih trebao reći da je analogija s građevinom prejednostavna, zato što ta slika prikazuje samo jednu perspektivu, onu fizičku, i ne prikazuje osnovne elemente sustava kao što su električne, vodo- vodne i mnoge druge nužne instalacije. Možeš li izdvojiti najvažnije koncepte u procesu stvaranja arhitekture softvera? Mislim da je najvažniji koncept to što sam već spomenuo – da se arhitekt fokusira samo na važne elemente. Većina ljudi ima problema s razumijevanjem toga jer je važnost vrlo subjektivna; na što da se arhitekt fokusira, a na što ne? Zbog toga je vrlo bitno složiti se s time što “važno” zaista znači. Važne elemente možemo gledati kao one s dugotrajnim učinkom, kao što su strukturalni elementi, oni povezani s ključnim ponašanjem i oni koji se bave bitnim kvalitetama poput pouzdanosti i skalabilnosti. Grady Booch dao je odličnu sliku toga: “Arhitektura u svojoj biti predstavlja važne odluke u dizajnu koje formiraju sustav, pri čemu se ‘važnostʼ mjeri troškom promjene”. Naravno, postoji puno više koncepata koje je bitno upamtiti: arhitektura osim struktura definira i ponašanje, balansira potrebe svih zainteresiranih strana, utjelovljuje odluke bazirane na promišljenim principima i ima određeni opseg. Zadnja je točka bitna jer mnoge Piše: Krunoslav Funtak Peter Eeles
22 | FYI by CROZ / broj 18 / svibanj 2015. intervju | Peter Eeles IT-ovce buni razlika između enterprise, sistemske i softverske arhitekture. Čak i unutar jednog sustava postoje razni dijelovi sistemske arhitekture kojima se moramo pozabaviti, kao što su aplikacijska arhitektura, arhitektura podataka, infrastrukturna i sigurnosna arhitektura i još neke druge. Još jedan važan koncept jest da svaki sustav ima arhitekturu, čak iako ona nije formalno dokumentirana ili ako je sustav iznimno jednostavan. Možemo li govoriti o industrijskim standardima za proces stvaranja arhitektura softvera ili samo o najboljim praksama? Postoji li neki univerzalni proces koji se može primijeniti na svaku organizaciju ili se proces mora prilagoditi kako bi organizacija dobila iz njega što je više moguće? Postoje standardi za neke tipove arhitektura. TOGAF (The Open Group Architecture Framework) se, na primjer, može primijeniti na nivou enterprise arhitekture. Postoje i “standardi” koji ulaze u određene aspekte procesa, uključujući ISO 42010 standard za dokumentiranje arhitekture i pristupe kao što su Attribute-Driven Design (ADD) i Architecture Tradeoff Analysis Method (ATAM) koji dolaze od SEI-a (Software Engineering Institute). Jedan je od ciljeva knjige bio staviti sve te pristupe u kontekst end-to-end procesa koji je fokusiran na disciplinu arhitekture. Ipak mislim da ideja “standardnog” procesa koji je primjenjiv u svim situacijama nije realistična. Sve bi procese trebalo prilagoditi organizaciji, projektu, timu i rješenju na kojem se radi. To je jedan od razloga zbog kojeg je bitno fokusirati se na paletu praksi koju možemo birati i primijeniti prema situaciji. S druge strane, postoji osnovni framework koji je potrebno primijeniti – onaj koji osigurava da su odluke dokumentirane, da je vođena briga o ponovnoj upotrebi bilo kakvih postojećih asseta, da su napravljeni različiti pogledi na arhitekturu i tako dalje. To je ono što smo probali opisati u knjizi. Kako možemo mjeriti učinkovitost procesa i kako ga možemo regulirati? Najvažniji test učinkovitosti jest poboljšana produktivnost (brže isporuke), smanjeni trošak i povećana kvaliteta isporučenog rješenja (mjereno kroz broj defekata). Često je vrlo teško atribuirati neko poboljšanje uvođenju neke prakse ili promjeni određenog aspekta procesa. Na primjer, mnogi projekti na kojima sam radio a gdje su organizacije željele poboljšati način na koji razvijaju i isporučuju softver, trebali su kombinaciju poboljšanja procesa, uvođenja integriranog skupa alata, ponešto reorganizacije, edukacije ljudi i sličnih akcija. Nemoguće je izdvojiti relativni doprinos svake od tih akcija. Velik sam zagovornik ciklusa “mijenjaj- mjeri-mijenjaj-mjeri”, gdje se rade i procjenjuju inkrementalne promjene prije uvođenja novih promjena. Na neki je način to uzimanje principa iterativnog i inkrementalnog razvoja softvera i njihova primjena na inicijative za promjenu. To je u biti područje na koje se fokusiram više od desetljeća – vjerujem da primjena arhitekturnih principa na delivery okruženje koje trebaju timovi za razvoj softvera može dati puno vrijednosti. Konkretan je primjer toga definicija kvalitetnog i integriranog skupa alata koji ne dolaze nužno od istog proizvođača. Kako novi i napredni kolaborativni alati, poput alata iz IBM-ove Collaborative Lifecycle Management (CLM) ponude, utječu na proces stvaranja arhitekture softvera? IBM-ovo CLM rješenje u velikoj je mjeri fokusirano na integraciju rada svih koji rade u timu i podršku njihovoj međusobnoj kolaboraciji. Konkretno, dani kada su poslovni analitičari definirali zahtjeve prije nego što su ih bacili “preko zida” dizajnerima i testerima, završili su. To se može vidjeti u širokom prihvaćanju agilnih i DevOps praksi koje su u velikoj mjeri fokusirane na rad timova, vidljivost i end-to-end razmišljanje. Iz perspektive arhitekture, velike organizacije često imaju silose unutar svoje arhitekturne prakse. Na primjer, mogu postojati timovi za aplikacijsku arhitekturu, infrastrukturnu arhitekturu i arhitekturu podataka. To je bio slučaj u velikoj banci za koju radim ovdje. Čak je i ovdje iznimno bitno stvoriti okruženje u kojem arhitekti iz različitih disciplina mogu surađivati. U ovom je slučaju rješenje bilo stvaranje jedinstvenog okruženja za modeliranje koje služi svim arhitekturnim disciplinama. Organizacija je od toga imala jako puno koristi. Glavni zadaci arhitekta Naslovnica Eelesove knjige “The Process of Software Architecting”
FYI by CROZ / broj 18 /svibanj 2015. | 23 g*rich | tehnologije i trendovi T ko god se primio iole ozbiljnijeg programiranja u Javi, bar je jednom u životu živčano odgurnuo tipkovnicu od sebe i rekao: “Tri- sta mu gromova i sto exceptiona... pa zar opet?! Zar ne bi ovo moglo biti u nekom frejmvorku pa da ne moram sve pisati od nule? Idem ga napraviti, da olakšam život i sebi i svima oko sebe!” Takvi su javaši, pokušavaju riješiti samu srž problema. Čak sam i sam svojedobno započeo pisanje bar dva frameworka (programska, odnosno aplikativna okvira). O uspješnosti mojih napora govori činjenica da se ne mogu sjetiti ni imena tih okvira niti detalja koje sam pokušao riješiti. Sjećam se samo frustracije, i osjećaja zadovoljstva kad sam shvatio da nisam jedini s tim problemima i da ih je netko već riješio, tj. napisao odgovarajući okvir – Spring Framework je nekako najočitiji primjer. Ruku pod ruku s nezadovoljstvom ide i osnovna premisa knjige “Innovation Happens Elsewhere” (Richard P. Gabriel, MORGAN KAUFMAN PUBL Incorporated, Piše: Davor Čengija 2005, ISBN 9781558608894), koja kaže: “Jasno je kao dan: bez obzira koliko pametna, kreativna i inovativna bila vaša organizacija, uvijek postoje pametniji, kreativniji i inovativniji ljudi van vaše organizacije od ovih unutra.” Jednostavno uzmimo što nam se nudi i idemo dalje. Sve navedeno stoji do određene mjere: možemo koristiti gotove komponente, bilo komercijalne bilo open source i biti zadovoljni poboljšanjima u brzini razvoja, kvaliteti isporuka ili dostupnim funkcionalnostima. I onda se u jednom trenutku opet javi onaj frustrirani i neurotični programer koji sebi u bradu kaže: “Okej, čak i ovo može – ne, čak i ovo mora bolje!” I eto nas na početku, no sada je situacija puno bolja. Naime, količina komponenti koje koristi tipičan programer na tipičnom projektu broji se u desecima. Komponentizacija je toliko raširena da imamo cijele segmente u IT industriji koji se bave samo njihovom proizvodnjom. Na pamet padaju Apache Foundation i njihov (među ostalima) Apache Commons, koji su na neki način i začetnici ovog trenda, ili već spomenuti Spring. Nije samo Java kao okruženje doživjela procvat u ovom smislu. Napraviti dobar i moderan web GUI danas uopće nije teško, potrebno je samo uzeti odgovarajuće – da čujem, što? – komponente, naravno. Raspored elemenata na ekranu, tablice, izbornici, zatim forme, validacije, podrška za višejezičnost, integracije s vanjskim ure- đajima, najrazličitija čuda; sve je tu negdje, samo uzmeš i radiš. Točnije, uzmeš, počneš raditi pa vidiš da se neke komponente međusobno baš i ne podnose, pa počneš popravljati njihove interne probleme, pa brinuti o različitim verzijama ovog i onog… Uzmeš, počneš raditi pa vidiš da se neke komponente međusobno baš i ne podnose, pa počneš popravljati njihove interne probleme, pa brinuti o različitim verzijama ovog i onog... I kad se podvuče crta, odjednom svaki programer treba znati puno više nego što bi htio. Kvalitetnom programeru je potrebno i dovoljno znati implementirati poslovne funkcionalnosti, sve okolo mu treba riješiti okruženje – framework. Sve okolo je čisto gubljenje vremena. Dobro, kako dalje? Java je odlično izvedbeno okruženje i de facto standard za razvoj enterprise aplikacija. Kao platforma, Java i JVM (Java virtual machine) nude sve što biznise čini sretnima: stabilno okruženje, odlične aplikacijske servere i razvojne alate, podršku stvarno velikih igrača. Može se dobar posao zavrtiti i na drugim g*rich – rješenje za svakodnevne razvojne probleme Kad je cjelina više od pukog zbroja dijelova…
24 | FYI by CROZ / broj 18 / svibanj 2015. okruženjima, ali “to jednostavno nije to”, “samo čekaš da se sve raspadne”, “proširivanje funkcionalnosti je noćna mora” itd. Za ozbiljan posao trebaš i ozbiljnu platformu. Svi su, dakle, sretni. Osim programera, jer Java kao platforma je odlična, Java kao programski jezik baš i nije. Java kao platforma je odlična, Java kao programski jezik baš i nije. Ustvari, nije baš da Java kao programski jezik ne valja, već JVM nudi mogućnost upotrebe različitih sintaksi, odnosno na neki način različitih programskih jezika, a da se sve izvršava na jednoj te istoj platformi, u istom aplikacijskom serveru. Od već postojećih jezika i njihovih “jVarijanti” (jRuby, Jython – da, Python u Javi) preko posve novih (Scala, Clojure ili Groovy), nove sintakse donose moderne programerske trikove, dinamičko prevođenje i sve što Javi kao programskom jeziku nedostaje. Brže, lakše, elegantnije, a sve u poznatom, stabilnom i nebrojeno puta dokazanom okruženju. Spomenuti Groovy je upravo takav jezik. Ako uspijemo zanemariti ne baš simpatično ime, taj jezik rješava sve što nas muči s Javom kao sintaksom: brzo se uči, izvršava se dinamički – ili statički, ako tako želimo, koncizan je i elegantan, a povrh svega, integrira se s Javom bez ikakvih problema. Čovjek se pita zašto sve to već inicijalno nije u Javi, ali eto, bar imamo Groovy. Manje linija koda, jednostavniji izrazi, čitljivije petlje tehnologije i trendovi | g*rich i već smo u prednosti, što zbog bržeg kodiranja, što zbog činjenice da manje linija koda znači i manje bugova. Groovy se automatski prevodi u Javu, tako da razlike u kompatibilnosti nema. Štoviše, Groovy je od svih alternativnih jezika na JVM-u najbolje integriran s Javom: bez ikakvih dodatnih koraka Java zove Groovy, Groovy zove Javu, Java i Groovy se mogu miješati u hijerarhiji nasljeđivanja itd. Sve u svemu, pravi izbor za početak. Istraživanje Groovyja kao alternativnog programskog jezika za JVM otvorilo je vrata onome što danas zovemo g*rich framework. g*rich = JVM + Groovy + Grails + Ext JS + sve između g*rich, “frejmvork nad frejmvorcima” (u smislu, frejmvork koji je izgrađen nad drugim frejmvorcima, ne baš frejmvork koji je bolji od svih ostalih, iako bi se i o tome dalo razgovarati), je tipičan produkt frustracija opisanih na početku priče, s tim da je danas u jednu ruku lakše jer je izbor kvalitetnih komponenti odličan, no istovremeno i kompliciranije jer sve to treba staviti pod isti šešir, da radi dobro i stabilno. Everything great in the world comes from neurotics. Marcel Proust g*rich je nastao kad se moj kolega Damir Murat, inače smiren i staložen gospodin u najboljim godinama, zapitao gore spomenuta pitanja. Kakve su to tipične poslovne aplikacije i što ne valja u današnjem razvoju takvih aplikacija? Gdje se gubi najviše vremena? Što ponavljamo svaki put, a stvarno ne bismo trebali? Krenimo od samog početka. g*rich je integrirano razvojno okruženje koje uključuje Grails kao web application framework, Sencha Ext JS kao klijentski JavaScript framework te, što je najbitnije, niz posebno razvijenih plug-inova za Grails i ekstenzija za Ext JS koji, između ostalog, od tih tehnologija stvaraju međusobno povezanu, skladnu razvojnu okolinu. Grails je nevjerojatno moćan framework za izradu web aplikacija. Napisan je u Javi i Groovyju i kao takav omogućava sve što nude ti jezici: radi na JVM-u, vrlo se brzo nauči koristiti, aplikacije se strahovito brzo razvijaju i testiraju. Uz sve to, skupa s Grailsom dolazi i ORM (object-relational mapper), izvrsna integracija s razvojnim alatima (Intellij IDEA, Eclipse, NetBeans itd.), plug-inovi za sve i svašta, razumne početne postavke okruženja, njeguje se princip convention-over-configuration i tako dalje. Odabrati bilo što drugo osim Grailsa bilo bi na neki način čak i neodgovorno. Slično se može reći i za Ext JS. Radi se o skupu JavaScript, HTML i CSS tehnologija koje omogućavaju jednostavnu izradu aplikacija za web i mobilne uređaje. Ext JS uključuje niz gotovih i u svakoj poslovnoj aplikaciji očekivanih komponenti pomoću kojih se razvoj web aplikacija ne razlikuje od razvoja desktop ekvivalenata. Sam rad u Ext JS-u je konceptualno puno sličniji Javi nego JavaScriptu, što je vrlo poželjna osobina. Pored navedenih ključnih komponenti, g*rich objedinjuje i cijeli niz de facto standardnih biblioteka u svakom modernom projektu u Javi, ali najzad usklađeno i bez međusobnih sudaranja. 3, 2, 1 – g*rich! Da bismo započeli novi projekt, u g*richu nam je dovoljna jedna naredba i četrde- setak sekundi vremena. Naredba pokreće jedan od plug-inova iz g*richa koji na temelju unaprijed postavljenog predloška generira inicijalnu verziju aplikacije. Sve je na svom mjestu: ispravno postavljena struktura direktorija, osnovne datoteke već na svom mjestu, testovi gdje trebaju biti; zatim razvojna baza podataka s već upisanim testnim podacima, Za svakog programera u Javi, Groovy je gotovo pa trivijalan za naučiti. Koliko se kodiranje u ta dva jezika razlikuje najbolje pokazuje sljedeći primjer. Java: String postalCode = null; if (user != null) { Address address = user.getAddress(); if (address != null) { postalCode = address.getPostalCode(); if (postalCode != null) { postalCode = postalCode.toUpperCase(); } } } Groovy: String postalCode = user?.address?.postalCode?.toUpperCase() Nevjerojatno, zar ne?
FYI by CROZ / broj 18 /svibanj 2015. | 25 g*rich | tehnologije i trendovi Zapisi se uređuju na istom ekranu. Forme mogu sadržavati vrlo kompleksne elemente koji, naravno, imaju sve funkcionalnosti kao i tablice za pregled. Programiranje ovakvih ekrana nije ništa kompleksnije od standardnih pregleda, a korisnički doživljaj je značajno poboljšan. Čemu trošiti riječi kad slike sve pokazuju? Koliko kompleksne klasične poslovne aplikacije mogu postati pokazuje i ova slika. Bez dobrog okruženja razvoj ovakvog prikaza je prava noćna mora. U g*richu to nije nikakav poseban problem. Nova tema je razvijena prema specifičnim zahtjevima korisnika. Praćenje životnog ciklusa zapisa u bazi je jedna od onih funkcionalnosti koje ili završe na “nice to have” listi i nikad se ne implementiraju ili dovedu projekt na rub propasti. g*rich jednostavno ne može dopustiti da se tako bitna stavka zanemari i donosi praćenje povijesti zapisa spremno za korištenje od samog početka. osnovna korisnička sučelja za “običnog” korisnika i administratora (koja su toliko dobra da se gotovo pa mogu odmah početi koristiti, samo se upišu stvarni podaci u bazu), skripte za pokretanje testnog servera... Predlošci se, naravno, mogu dodavati ili mijenjati, čak se i bilo koja radeća aplikacija može pretvoriti u predložak. Demo aplikacija koju g*rich automatski generira uključuje niz upotrebljivih primjera, od kojih je najzanimljiviji famozni “šifarnik”, u ovoj ili onoj formi najčešći oblik poslovnih aplikacija, i to ne bilo kakav šifarnik! Sve je tu: pametno pretraživanje podataka, “master-detail view”, uređivanje podataka... Šifarnik bez ili šifrarnik s prvim r? Ovisi koga pitate, tj. o njegovoj ili njenoj godini rođenja – prije ili poslije pojave prvog PC-a. A Ispod generirane aplikacije se nalazi jezgra g*richa, koja ustvari predstavlja srce cijelog aplikativnog okvira u tehničkom smislu. Tu su sažeti sati i sati programiranja i peglanja različitih dijelova frameworka. Bez ove jezgre, g*rich bi bio samo nakupina odličnih, ali ipak nepovezanih komponenti. Spomenimo neke: Validatori podataka na formama se najzad implementiraju samo na jednom mjestu (na serverskoj strani) i automatski se propagiraju do klijenta. Ponašaju se onako kako bi i trebali: pokazuju smislene poruke za pogrešno upisanu vrijednost pojedinačnog polja, povezanih polja ili cijele forme. Podrška za višejezičnost, teme ili kontrolu pristupa podacima se, naravno, podrazumijeva. Za neke mogućnosti koje g*rich donosi ni ne znamo da su potrebne sve dok nas surova stvarnost ne opali po prstima i ne natjera na trošenje sati i dana na krpanje aplikacije. Spomenimo samo podršku za OWASP
26 | FYI by CROZ / broj 18 / svibanj 2015. Top 10 Security ili heartbeat call koji ne produžuje session (!). Jesu li šusterova djeca baš uvijek bosa? I jedna zanimljivost za kraj: prezentacije g*richa potencijalnim partnerima su gotovo uvijek završavale reakcijama poput: “A gdje ste bili do sada?!” ili “Kad možemo početi?”. Međutim, na jednom projektu sam čuo primjedbu: “Dobro, i što je tu toliko posebno? Pa to je samo brdo nekakvih biblioteka i tu i tamo poneki plug-in.” Takva rečenica ne može biti više u krivu nego što jest. Istina, g*rich neće od poluzainteresiranih programera koji su do jučer “čukljali” COBOL stvoriti gurue razvoja modernih web aplikacija, ali će zato svakom iole upućenom javašu omogućiti rad kakvog je htio od prvog dana, a to znači fokus na poslovni aspekt projekta, bez petljanja po utrobi frameworka, i sve to bez gubitka fleksibilnosti i bogatstva različitih opcija koje razvoj u Javi donosi. U slučaju g*richa ne vrijedi ona izreka o šusteru i njegovoj bosoj djeci. Naime, i sami ga koristimo na desetak vrlo ozbiljnihprojekata Demo aplikacija “izgleda ko prava i radi ko prava”, samo što nije prava. A Ali zato ima sve elemente koje prava aplikacija treba imati: kompleksne tablične preglede, mogućnosti direktnog uređivanja zapisa, prilagodljivo korisničko sučelje. Spojite je na svoju razvojnu bazu i počnite programirati. Formu nije moguće spremiti sve dok svi podaci nisu ispravno upisani OWASP (OpenWeb Application Security Project) je organizacija koja za cilj ima osvijestiti internetsku javnost o nužnosti implementacije sigurnosnih elemenata u web aplikacijama. OWASPTop 10 Security List je popis deset najčešćih sigurnosnih propusta u web aplikacijama, poput XSS-a (Cross-site scripting) ili ubrizgavanja SQL-a (SQL injection). g*rich implementira zaštitu od svih nabrojanih sigurnosnih propusta, odnosno napada koji iskorištavaju te propuste. Porijeklo imena g*rich i dan danas ostaje nepoznanica. Znači li onaj“g”ustvari Groovy, možda Grails, ili čak“GUI”? Za“rich”je jasno, bogatstvo komponenti koje stvarno olakšavaju posao, ali g? Navodno Grički top sa svojim pucnjem točno u podne označava kraj radnog dana za korisnike g*richa, jer su toliko produktivniji da već u podne mogu na kavu i lagano doma. I što ona zvjezdica predstavlja u imenu? Za vas smo razvili dvije aplikacije u našem g*rich frameworku. Kakva su iskustva korisnika aplikacija u dosadašnjem radu? Korisničko iskustvo rada u aplikacijama napravljenima u g*rich frameworku je jako dobro. Naime, s aplikacijom Šifrarnici u naše je korisničko okruženje neprimjetno ušao potpuno novi, praktičniji sustav za primjenu kontrola međuovisnosti na administracijski jako važno mjesto, bazu šifrarnika koju koristi više sustava Banke. Broj vrsta podataka koji se administriraju kroz aplikaciju je velik, kao i broj različitih kontrola koje su primijenjene po poljima i pojedinim tablicama šifrarnika. Iako je u našoj struci nemoguće govoriti o maštovitosti korisnika bez prigodne grimase, implementacijom ove aplikacije gotovo smo potpuno onemogućili pogrešne unose, a korisnici su paljenje kontrola prilikom pogrešnog unosa proglasili čak i lijepim. A Kakvi su dojmovi završenih implementacija u smislu brzine i pouzdanosti? Smatrate li da je za vas poželjan daljnji razvoj u istom smjeru? Vezano uz navedenu implementaciju uistinu nemam primjedbi, te mogu konstatirati da je implementacija bilo kojeg novog šifrarnika brza i bezbolna te da se novi šifrarnici, funkcionalnosti i kontrole postavljaju i mijenjaju odgovarajućom brzinom. MirkoGrbavac Sberbankd.d. (Specijalistza analizu poslovnih aplikacija) tehnologije i trendovi | g*rich i rezultati su više nego pozitivni, a korisnici zadovoljniiisporučenimfunkcionalnostima i vidljivim ubrzanjem isporuka.

Fyi 18 web

Recommandé

Contenu connexe

Similaire à Fyi 18 web(20)

Dernier(12)

Fyi 18 web