FYI by CROZ - broj 18

tehnologije i trendovi: g*rich • Dajmo djeci da programiraju projektne
priče: Implementacija disaster recovery rješenja u Fini • Intranet u SKB banci intervju: Peter Eeles: Svrha softverske arhitekture predstavljamo partnere: CSI Ltd.

IZDVAJAMO IZ AKTUALNIH TEČCAJEVA: TEČAJEVI PO MJERI LEARN@CROZ kontaktirajte nas
na [email protected] 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 | rubrika fyi by croz | uvodnik FYI by CROZ | Časopis za informatiku | Urednik: Goran Kelečić | Izdavač: CROZ d.o.o., Lastovska 23, 10000 Zagreb, Republika Hrvatska | Tel.: 00385 1 6184 831 | Faks: 00385 1 6184 833 E-mail: [email protected] | 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 kvalitetom 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

nadnaslov | rubrika fyi by croz | vijesti fyi by croz | vijesti Održano događanje Prediktivna analitika i Fraud Management 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 zlatni sponzor konferencije Agile 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žan financijski Roadshow Event 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 Javantura o Javi i 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, Dock your app, održali su CROZ-ovi stručnjaci Matija Folnović i Tomislav Kliš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šno održan peti Smart Day 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. LMI predstavljen slovenskim startup tvrtkama na događanju Implico 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.

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?

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.

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čna preporuka 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

Automatizacijom testiranja do kvalitete | tema broja Osnovna 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

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žavanja konkurentnosti? 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 (Proof of Concept) dokaže da je vodeći partner na tržištu u uslugama testiranja softvera, i ispit je položen s odličnim! Nakon uspješno realiziranog PoC-a u sklopu kojeg smo dokazali našu ekspertizu u različitim vrstama testiranja, između ostalog u tvorničkom testiranju tekućeg razvoja, izradi automatiziranih regresijskih testova te izradi testova za obradne (batch) programe, stručnjaci CROZ-a i Erstea usko su i uspješno surađivali uspostavljanjem visokog stupnja razumijevanja, konkretnih unaprjeđenja u svakodnevnom testiranju banke te ujednačene metodologije. Samom početku angažmana je prethodilo i certificiranje većeg broja naših stručnjaka za rad s testnim alatom TOSCA, koji je “kućni” alat u banci. Nakon toga smo zajednički krenuli u strateško partnerstvo. Već je godina kvalitetne suradnje iza nas, te smo tim povodom razgovarali o dojmovima ove uspješne priče s koordinatorima projekta s Erste i CROZ-ove strane: Tomislavom Kirincem i Darkom Marijanč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 sIT Solutions (Manager for External IT Service Providers)

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 alata TOSCA, koji do sada u CROZ-u nije bio primaran testni alat. Bitno je reći da alat TOSCA 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 Proof of Conceptom, 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ČNO TESTIRANJE AUTOMATIZIRANO TESTIRANJE Vrijeme Ljudi Infrastruktura Alati Obučavanje Darko Marijančić CROZ d.o.o. (koordinator CROZ-ova testnog tima)

2015. tema broja | Performansno testiranje Performansno 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. Tipovi performansnog testiranja • 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.

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 Performance Tester, 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.

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 Austria d.d. (direktor SD organizacije, procesa i projekata) 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 Under Test

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 aplikacija U 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 Automatizacija testiranja Definiranje ciljane skupine uređaja

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

Što je sustav za Identity Governance? 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 sastanci 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. IBM Security Identity Governance 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 part numberom. i web aplikacijskom serveru uz nekoliko glavnih funkcionalnih modula: • Access request modul, 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) • Access governance modul, koji pruža funkcionalnosti razdvajanja ovlasti, usklađenosti sa SAP sustavima te revizije prava pristupa • Access inteligence modul, 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 korisniku i kritički se osvrću na rezultate 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

Poslovni 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 nakon projekta 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 Slika 1 – Finina mainframe 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 Parallel Sysplex z9-109 z9-109 z900 Tape Unit ESCON, FICON Tape Library enterprise storage enterprise storage enterprise storage sinkrona replikacija asinkrona replikacija

2015. rubrika | nadnaslov projektne priče | GDPS u Fini Zbog čega je Fina odlučila implementirati GDPS rješenje? Koji su glavni ciljevi projekta? Fina je prije dvije godine napravila pričuvnu lokaciju u Zaboku jer smo htjeli implementirati ovakvo rješenje kako bismo dodatno osigurali kontinuitet poslovanja. Htjeli smo biti sigurni da nikakve nepredviđene situacije neće dovesti do ispada sustava, odnosno da u svakom trenutku svim našim korisnicima jamčimo kvalitetnu i od 0 do 24 sata dostupnu uslugu. Nakon implementacije rješenja u Zaboku napravljeni su testovi, prvi put nakon dugo godina svi su sustavi kompletno ugašeni te su se ponovno podizali. Isto tako su napravljeni testovi prelaska svih sustava na pričuvnu lokaciju i nakon toga njihov povratak na sustave u Finu u Vukovarskoj. Testiranja su uspješno provedena. Cilj nam je bio da na visoko raspoloživim sustavima imamo naše servise koji su na raspolaganju korisnicima i da stvarno osiguramo da su im dostupni od 0 do 24. Fina je jedan od vodećih pružatelja usluga u javnom i financijskom sektoru, što za korisnike vaših usluga predstavlja ovo unaprjeđenje infrastrukture? Sami su korisnici naših usluga dobili veću sigurnost, međutim važno je naglasiti i da je Fina dobila veću sigurnost da će svim svojim korisnicima moći pružiti sve što oni očekuju. Korisnicima je Fina i dosada pružala kvalitetnu i dobru uslugu, a sada je sve zajedno podignuto na jednu višu razinu. Prvi ste korisnik GDPS rješenja u Hrvatskoj. Je li ono ispunilo vaša očekivanja ? Kakvi su daljnji planovi? Sva naša očekivanja su ispunjena. Mislim da su svi uvidjeli koje je promjene donijela implementacija GDPS rješenja u odnosu na dosadašnji rad. Vidimo da možemo i neke naše interne standarde prema informatici još poboljšati, dići na viši nivo, što je upravo ovo rješenje omogućilo. U planu imamo još neke sustave prebaciti u Zabok. Tamo već sad imamo i sustave koji nisu vezani za mainframe i možemo reći da sve skupa radi jako dobro. Što se tiče daljnjih planova, namjera nam je jedan dio naših resursa iznajmljivati i drugim korisnicima. Nadamo se da će korisnici tu našu prednost i prepoznati s obzirom na to da smo jedni od rijetkih koji imaju pravu pričuvnu lokaciju. Kako ste zadovoljni samim projektom? Jeste li zadovoljni poslom koji su obavili CROZ i partneri? Prilikom realizacije projekta nije bilo nikakvih problema. Zapravo, dosada s CROZ-om nismo imali problema ni na kojem projektu, pa tako ni na ovom. Svi su poslovi i testiranja odrađeni profesionalno i na vrijeme. Ono što smo očekivali od CROZ-a i partnera, to smo i dobili. Željko Pavić Financijska agencija (član Uprave) 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. Slika 2 – Finina mainframe infrastruktura poslije implementacije GDPS rješenja Fina - primarna lokacija Fina - DR lokacija Parallel Sysplex zEC12 zEC12 Tape Library Tape Library sinkrona replikacija Enterprise disk Enterprise disk

nadnaslov | rubrika Peter Eeles | intervju Koliko 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 arhitekture CROZ-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

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”

g*rich | tehnologije i trendovi Tko 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…

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?

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

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 ozbiljnih projekata 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 (Open Web Application Security Project) je organizacija koja za cilj ima osvijestiti internetsku javnost o nužnosti implementacije sigurnosnih elemenata u web aplikacijama. OWASP Top 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. Mirko Grbavac Sberbank d.d. (Specijalist za analizu poslovnih aplikacija) tehnologije i trendovi | g*rich i rezultati su više nego pozitivni, a korisnici zadovoljni i isporučenim funkcionalnostima i vidljivim ubrzanjem isporuka.

CSI | predstavljamo partnere Pet godina na Otoku A Malo-pomalo i evo nas u trećem nastavku serijala posvećenog našim međunarodnim partnerima s kojima uspješno surađujemo. Iz trenutačne perspektive već sada imamo materijala za idućih 5-6 brojeva, u kojima ćemo zasigurno otići i izvan Starog kontinenta A, pa to samo shvatite kao teaser za buduća izdanja FYI-a. U svakom slučaju, sretni smo što ova sekcija FYI-a, a tako i naše projektne avanture izvan granica RH imaju vrlo izvjesnu budućnost! Piše: Ivan Đeri CROZ-ova peta sezona u UK-u U prošlom izdanju FYI-a kolegica Mirela pisala je o njemačkom partneru ARS-u, a sada se ponovno vraćamo na Otok. U nastavku pročitajte tko je i čime se bavi tvrtka CSI Ltd. te kako smo započeli vrlo uspješnu suradnju. Pišući ovaj članak sjetio sam se naših prvih bojažljivih izleta u veeeeliku Veliku Britaniju, a onda sam shvatio da je to bilo prije više od pet godina! Super je što smo u tih 5 godina napravili sjajne stvari na koje smo jako ponosni, jer ipak se radi o gostujućem terenu jedne od najjačih liga svijeta. Nije bilo nimalo jednostavno, a uspjeli smo najviše zahvaljujući sjajnoj ekipi, koja je osim neupitne stručnosti morala imati i puno odvažnosti potrebne za boravak u stranoj zemlji, gdje su i po nekoliko mjeseci “u komadu” branili boje CROZ-a, ali i kreirali ugled hrvatskog IT stručnjaka općenito. CSI Ltd., United Kingdom Naravno, nismo se preko noći počeli baviti kriminalistikom, forenzikom, a još manje snimanjem nastavaka popularnih televizijskih serija na tu temu. Upravo suprotno – dobili smo priliku geografski proširiti područje za naš core business i početi raditi ono u čemu smo najbolji na jednom od najvećih europskih tržišta. Još jednom se pokazalo da je preporuka najbolji put do stjecanja novih poslovnih prilika. Ovdje naravno nije riječ o kumstvima i rodbini, nego gotovo isključivo o kvaliteti i pouzdanosti. Govorimo o jednom od najrazvijenijih tržišta uopće, pa je i konkurencija brojna, ali i kvaliteta jako oscilira. Zato je reputacija kvalitetnog i pouzdanog near shore partnera neprocjenjiva. U toj smo se zoni našli i mi. Naš put do suradnje s tvrtkom CSI Ltd. vodio je preko tvrtke Orbital Integrated Solutions Ltd., koja je bila specijalizirana za isporuku usluga vezanih uz integracijske IBM tehnologije i middleware poput Message Brokera (danas Integration Bus), MQ, DataPower, API Management, Cast Iron... Ukratko, uska specijalizacija za usluge implementacije i konzaltinga vezanog uz IBM WebSphere brand. Oni su odlično prepoznali stalnu potrebu za tom vrstom usluga bez obzira na nove trendove i paradigme poput Clouda, BigData, Sociala itd. Integracije su zapravo u samoj jezgri svakog enterprise IT sustava i potreba za povezivanjem i integracijom ustvari je u stalnom porastu. Počeli smo surađivati na manjim, ali vrlo zahtjevnim konzultantskim angažmanima (primarno vezano uz WebSphere MQ i Integration Bus) i nastavili kroz suradnju na Managed Pregled portfelja tvrtke CSI Pitoreskna okolina CSI-evog ureda u okolici Birminghama

2015. Services projektima kao pouzdan, stručan i near shore partner koji po potrebi vrlo brzo može biti on-site. Ono što je za nas relativno novo jest mogućnost rada u remote modelu, što nam bitno povećava efikasnost, štedi logistiku i čini nas fleksibilnijima. Naravno čak i off-site projekti mogu prema potrebi postati on-site, UK je ipak samo dva sata leta od Zagreba. Managed Services – što je to? Iz marketinško-prodajnog kuta bilo nam je zanimljivo promatrati kako su (CSI i Orbital Integrated Solutions) vrlo pametno brandirali uslugu koja se u UK sve više traži, a zove se Managed Services. Ukratko, radi se o “pametnom upravljanju IT sustavom”, tj. outsourcingu koji obuhvaća tradicionalni Incident i Operations Management uz definirani SLA, ali uz dodane vrijednosti poput konzaltinga, konstantnog predlaganja unapređenja i modernizacije, vođenja brige da je SW ažuran i sl. Zbog izrazito heterogenih okolina, korisnicima je komercijalno neisplativo ulagati u vlastite zaposlenike i educirati ih, te gotovo kompletnu brigu o svom IT okruženju prepuštaju tvrtkama koje su specijalizirane za pojedina područja. Ja to nekako vidim kao Cloud u vlastitoj sistemskoj sali, tj. infrastruktura je i dalje na lokaciji korisnika, ali su sve “pripadajuće” usluge ugovarane izvana. Što o Managed Services kaže CSI-ov Tim Streather, pročitajte u intervjuu. Akvizicija Orbital Integrated Solutions Ltd. je u srpnju 2014. kupila tvrtka CSI Ltd., te smo Jedan od ključnih ljudi tadašnjeg Orbital Integrated Solutions Ltd., a danas CSI Ltd. je i Tim Streather. Tima smo upoznali kao voditelja prodaje Orbital Integrated Solutions zaduženog za poslovne rezultate i strategiju, a mnoga priznanja (IBM’s Software Business Partner of the Year 2013, IBM’s UK Technical Excellence Award 2014), kao uostalom i akvizicija Orbitala, potvrđuju da radi sjajan posao. Danas je Tim u okviru CSI-a glavni i odgovorni za inovacije i rješenja za IBM-ov dio poslovanja. Tim, možeš li nam ukratko objasniti zašto je tadašnji Orbital Integrated Solutions odabrao integraciju i connectivity kao svoj core business i strateški smjer? Primarno je uvjerenje Orbitala bilo da je IT katalizator pozitivnih poslovnih promjena. Fokusirali smo se na integraciju i connectvity jer smo strastveno vjerovali da je to temelj takve promjene. Integracija je osnova svih poslovanja – tako se i rodila naša mantra “povezivanje bitnih sustava s bitnim ljudima”. Koji je po tvom mišljenu bio ključni razlog akvizicije Orbitala? Drugim riječima, što je Orbital donio ekosustavu CSI-a? Morat ćeš to pitati našeg direktora. A Ozbiljno, dva su razloga. U prvom redu, kako bi se bolje podržalo CSI-ove odjele SAP i Analytics and Commerce, dajući im mogućnosti enterprise integracije. Drugi je razlog uspješan odnos Orbitala i IBM-a – CSI je ovom akvizicijom postao IBM-ov softverski partner, partner s najvećim prihodom u zemlji. Svjedoci smo velikih promjena u IT industriji. Svi pričaju o pojmovima kao što su Cloud, Analytics, Internet of Things, Mobile, Big Data... IBM nije iznimka. I mi, kao dio IBM- ova ekosustava pozorno pratimo, analiziramo predstavljamo partnere | CSI Tim Streather CSI Ltd. (Head of Solutions and Innovation – IBM Software) i prognoziramo kako će se to odraziti na naše klijente i na nas kao poslovne partnere. Kako ti se čini, što je next big thing i može li se sve promijeniti preko noći? Promjena je jedina konstanta IT-a – inovacije stvaraju nove poslovne modele i prilike, ali također znače da se moramo prilagoditi ili postati zastarjelima. Ipak, tempo promjena koje se sada zbivaju nikada nije bio toliko brz. Trošak uvođenja novih tehnologija spojen s novim modelima potrošnje (npr. Software as a Service) znači da su klijenti na upravljačkoj poziciji – čak se i ogromne tvrtke poput IBM-a i SAP-a moraju prilagoditi. To znači da se mi kao poslovni partneri također moramo prilagoditi kako bismo ostali relevantni. Moramo zaista nuditi vrijednost – mislim da će jaki pružatelji usluga postati još jači. Ako ovo čitate i ne znate jasno izreći koji je vaš unique selling proposition, budite zabrinuti. Kako objašnjavaš potrebu enterprise korisnika za Managed Services? Možeš li nam objasniti taj pojam? To je zapravo marketinški termin, to nije novi koncept, ali je sve važniji u modernom IT svijetu. Uključuje servise podrške kroz hosting, Software as a Service (SaaS) i outsorcing. U najjednostavnijoj varijanti možemo ga definirati kao ponudu kompletnog end-to-end rješenja klijentima, s fleksibilnim opcijama plaćanja i skaliranja, koja im omogućuje da se fokusiraju na svoj core business. Mogućnost brzog postavljanja novih IT servisa podržava rast s klijentske strane. Pružatelji usluga vole mogućnost prelaska s poslovnog modela produkta na model pretplate, što pridonosi stabilnosti i povećava vrijednost tvrtke. Kako bi opisao suradnju CROZ-a i CSI-a? Jeste li zadovoljni s kvalitetom naših usluga i kako vidite našu suradnju u budućnosti? CROZ nam omogućuje fleksibilnost u ponudi naših usluga, osobito tijekom perioda velike potražnje, čak i u tehnološkim područjima koja nisu u našoj osnovnoj ponudi. Imamo ogromno povjerenje u ljude koji dolaze kod nas, a stvorili smo ga kroz mnogo uspješnih projekata. To nam je iznimno vrijedno kada radimo s vanjskim klijentima koji od nas očekuju visoku razinu usluga. Nikada do sada nismo bili razočarani – hvala vam! tako dobili priliku raditi s kompanijom koja već dugo posluje na UK tržištu i prepoznati su kao stručnjaci za SAP, eCommerce, Analytics i Mobile, a kroz ovu su akviziciju postali nezaobilazan partner na projektima vezanima uz svaku vrstu integracije i povezivanja raznorodnih sustava i, naravno, IBM- ovih softvera. Prema godišnjem je prihodu, CSI 2014. godine proglašen najuspješnijim IBM-ovim poslovnim partnerom. Managed Services u jednoj slici

Intranet u SKB banci | projektne priče U SKB banci su prepoznali tu potrebu, intranet koji će djelatnicima dati jasnu sliku svih produkata koje banka nudi krajnjim korisnicima, te istovremeno služiti kao kanal i centralno mjesto za in- formiranje o obavijestima i aktualnosti- ma. Osim potrebe za sustavom kojim će se moći upravljati web sadržajem nužna je bila i integracija s postojećim Alfresco sustavom za upravljanje dokumentima, odnosno način da se korisnicima omo- gući pristup bitnim dokumentima kao i njihovo pretraživanje. Liferay kao odabrana portalska platforma Kao portalsko rješenje koje ispunjava te i mnoge druge zahtjeve odabran je Liferay portal, open source portalsko rješenje koje osim osnovnih funkcionalnosti objave sadržaja omogućava i puno drugih funkcionalnosti. Liferay portal u ovakvom scenariju služi kao centralna Piše: Luka Podobnik Internet ili intranet? Što je važnije? Mnogi će pomisliti “javni web, naravno”, jer je prezentiran krajnjim korisnicima. Ali nije li omogućavanje brzog, strukturiranog i jednostavnog pristupa informacijama djelatnicima vaše tvrtke jednako važno? Slijedi primjer uspostave intraneta u SKB banci. točka integracije različitih postojećih servisa, ali nudi i mogućnost integracije s eventualnim budućim servisima. Liferay portal dolazi s više od 60 ugrađenih portleta koji podržavaju različite funkcionalnosti upravljanja sadržajem, kolaboracije i društvenih aktivnosti. Osim ugrađenih portleta Liferay podržava i vrlo jednostavan razvoj portleta u JAVA programskom jeziku, što omogućuje njegovo nadograđivanje prema najzahtjevnijim potrebama korisnika. Liferay portal dolazi u dvije verzije, Community i Enterprise, od kojih je Community verzija besplatna. No Enterprise verzija je u pravilu stabilnija, te sa sobom donosi prednost službene Liferay podrške. U obje verzije dostupan je izvorni kod. Ready, set, go Kao tvrtka koja ima mnogo intranet utakmica “u nogama” oformili smo tim i za ovaj susret i krenuli. Liferayove Liferay Marketplace Liferay portal dolazi s ugrađenim skupom portleta, aplikacija koje su spremne na ugradnju u stranice portala i rješavaju potrebe korisnika prepoznate kao najčešće. No, ukoliko vam je potreban specifičan portlet za vaš portal, a među ugrađenim Liferay portletima niste pronašli ono što tražite, možda se odgovor krije na Liferay Marketplaceu. Među trenutačno više od 300 portleta, od kojih je većina besplatna, mogu se naći gotova rješenja iz područja komunikacije, produktivnosti, sigurnosti i općih utility rješenja. Neki od zanimljivijih primjera jesu portlet koji omogućava chat među korisnicima te portlet za integraciju s Google Mapsom. Portlet koji vam je interesantan moguće je jednostavno uklopiti u postojeću Liferay instalaciju, većinom je dovoljno svega par klikova. Više informacija možete naći na https://www.liferay.com/marketplace.

2015. projektne priče | Intranet u SKB banci ugrađene funkcionalnosti omogućile su implementaciju velikog dijela zahtjeva, ali kroz razgovore s poslovnim korisnicima prepoznata je potreba za nekoliko korisnih i zanimljivih funkcionalnosti koje portalska rješenja ne podržavaju out of the box. Kalendar aktivnosti i specijalizirani rječnik pojmova samo su neki od primjera. Za te potrebe nadogradili smo sustav s našim kodom, a konačni rezultat se estetski uklopio u temu portala i donio korisnicima dodatnu pomoć u radu s portalom. Posao oko izrade dizajna odradili su profesionalni web dizajneri, prema smjernicama i idejama iz SKB-a, a rezultat je atraktivan i pregledan dizajn koji je u skladu sa standardima Société Générale grupe. Kako smo spomenuli, SKB koristi Alfresco sustav za pohranu dokumenata, u kojem se nalaze podaci važni krajnjim korisnicima portala, kao što su dokumenti koji opisuju usluge banke, pravilnici i formulari. Kako bi se korisnicima omogućio jednostavan pristup navedenim informacijama kroz intranet portal, razvijena je integracija portleta za pretraživanje web sadržaja i Alfresco sustava, kao i integracija Liferayova repozitorija dokumenata s Alfrescom. Na taj način Liferay postaje “prozor” u Alfresco, na način transparentan korisnicima. Osim tog, najizazovnijeg dijela projekta, implementirane su druge funkcionalnosti: prikaz obavijesti i aktualnosti u obliku RSS feeda, konfiguracija workflowa odobravanja sadržaja te proširivanje ugrađenog WYSIWYG editora s mogućnostima koje urednicima portala olakšavaju svakodnevni rad. Ne smijemo zanemariti ni jednostavniji, ali nezaobilazan dio projekta, migraciju postojećih informacija u portal. Informacije o produktima, sadržane u Word dokumentima, prebačene su u portalsku strukturu stranica. Zbog specifičnog oblika sadržaja, postupak nije mogao biti odrađen automatskim skriptama, tako da je tim junior programera ručno kreirao više od 300 intranet stranica sa statičkim sadržajem. Također, više od 1 500 CROZ i Liferay CROZ je već uigran u implementacijama Liferay portala, među korisnicima kod kojih smo implementirali Liferay izdvajamo: • VIPnet d.o.o. – implementacija javnog weba i intranet portala • Croatia osiguranje d.d. – implementacija intranet portala • Raiffeisenbank Austria d.d. Zagreb – implementacija javnog weba Tomaž Pevc SKB banka d.d. Ljubljana (IT-infrastruktura i arhitektura) Reprezentativna stranica portala, usmjerena na strukturu i preglednost sadržaja Naslovnica portala, kombinacija klasičnih portalnih elemenata Liferay platforme za prikaz sadržaja i dijelova portala razvijenih za potrebe banke U SKB banci odlučili smo se za izvedbu programa RED (Retail Efficiency Development), projekta s kojim smo poboljšali postojeće procese prodajnih aktivnosti u poslovnoj mreži SKB-a. U sklopu projekta smo izmijenili zastarjela rješenja (javne foldere, mrežne diskove) s novijom, učinkovitijom i prilagodljivijom platformom. Nova platforma omogućuje jasnu i jednostavnu strukturu prikazivanja informacija, ugodnu navigaciju te učinkovitu funkcionalnost pretraživanja koja omogućuje brzu dostupnost kvalitetnih informacija. Dodatni zahtjevi za novi sustav bili su: da sadržaj oblikuje i održava pododjel u jedinici Komercijalno upravljanje, da omogućuje upravljanje verzijama dokumenata, da ima mogućnost uređivanja intranetskih i internetskih stranica. Zahtjevi odjela Informacijska tehnologija bili su: platforma mora biti usklađena sa smjernicama Société Générale grupe, troškovi implementacije i održavanja moraju biti primjereni, mora omogućavati skalabilnost, nuditi mogućnost integracije s DMS platformom koja je već bila implementirana u banci. Tražili smo kompetentnog poslovnog partnera koji bi mogao kvalitetno odraditi usluge razvoja i održavanja. Nakon obavljene analize zaključili smo da je za izvedbu intranetskog portala prikladna platforma Liferay Portal CMS s Alfresco DMS platformom za upravljanje dokumentima. U postupku izbora kao najbolji se ponuditelj pokazala tvrtka CROZ d.o.o. iz Zagreba, koja je radovima pristupila brzo i profesionalno te u pola godine uspješno implementirala predstavljeno rješenje na infrastrukturi SKB banke. Od uvođenja intraneta na platformi Liferay tvrtka CROZ nudi SKB banci stručno održavanje i razvoj na open source platformama, a također se često iskaže s učinkovitim prijedlozima za daljnji razvoj poslovnih rješenja. dokumenata migrirano je u Alfresco DMS sustav. Zaključak? Portal je uspješno pušten u produkcijsko okruženje, vrlo je brzo prihvaćen od svih zaposlenika, ali tu suradnja između SKB-a i CROZ-a nije završila. Kako dolaze nove ideje i nove potrebe, portal se mijenja i evoluira i raste. Tko zna, možda nas u budućnosti čeka i SKB Intranet 2.0. A

IBM API Management | tehnologije i trendovi Teško je započeti temu o upravljanju API-ima a da ukratko ne razjasnimo značenje skraćenice API. Application Programming Interface, skraćeno API, programerima je itekako poznat. U dokumentaciji API-a nekog softverskog rješenja očekujemo pronaći opise dostupnih sučelja, struktura podataka (klasa), a ponekad i kod s primjerima uporabe. Unazad par godina definicija se API-a donekle promijenila. Danas se pojam API-a primarno veže uz uporabu na webu. U ovom ćemo članku govoriti upravo o tom kontekstu. Da bismo objasnili što API jest, praktično je objasniti što API nije. API nije: • aplikacija – softverska aplikacija može izložiti funkcionalnosti kao API, ali ona sama nije API • korisničko sučelje (UI) – klijentska aplikacija s korisničkim sučeljem nije API, iako su funkcionalnosti UI-a često implementirane korištenjem API-a • server – web ili aplikacijski server nisu API; na tim serverima mogu biti softverska rješenja s izloženim API- em, ali sami serveri nisu API. Kada smo razjasnili što API nije, možemo probati definirati moderno značenje API-a. API je zaokružena funkcionalna cjelina osmišljena i izložena tako da bude što atraktivnija. Tu funkcionalnu cjelinu možemo nazvati i proizvodom. Kada dizajniramo proizvod i stavljamo ga na tržište (može biti i besplatan), razmišljamo o: • pakiranju – koliko je ono atraktivno za potrošača (želimo da odabere baš naš proizvod) • korisničkim uputama – ako potrošač odabere naš proizvod, želimo da u što kraćem vremenu ovlada korištenjem proizvoda • konzistentnosti proizvoda – ne želimo da naš proizvod bude manjkav što neophodnim funkcionalnostima, što lošijom kvalitetom nekih sastavnih dijelova • korisnička podrška – nakon što je proizvod kupljen, nudimo pristupačnu korisničku podršku kako bismo opravdali povjerenje. Ove četiri točke mogu se primijeniti na bilo koji proizvod, pa tako i na API. Naravno, trebamo malo promijeniti terminologiju pa umjesto o pakiranju pričamo o portalu za programere, korisničke su upute dokumentacija, konzistentnost je proizvoda kvaliteta i kompletnost API-a, a korisnička je podrška kanal prema programerima kroz koji se mogu obratiti kada imaju problem. To su samo neke od karakteristika koje želimo ispuniti kao davatelji usluge API-a. Da bi implementacija API-a bila uspješna, trebamo sve te karakteristike implementirati brzo i kvalitetno. Upravo to i još mnogo više pruža IBM-ov API Management, koji nam kroz koncept gatewaya omogućava da konfiguracijom izložimo servise kao funkcionalne API cjeline. IBM API Management Jedan od proizvoda koji olakšava implementaciju API-a jest IBM-ov API Management, skraćeno APIM. IBM API Management Jedan od trendova u arhitekturi sustava je implementacija API-a. Može se pročitati da je danas imati svoj API isto kao i imati internetsku stranicu 90-ih godina. To je sasvim primjerena analogija koja govori o sve većoj važnosti API-a kao arhitekture budućnosti. Piše: Miroslav Rešetar IBM API Management potiče brz razvojni ciklus

2015. tehnologije i trendovi | IBM API Management Komponente APIM-a jesu: Developer Portal, API Manager i Cloud Console. Developer Portal Jedan je od ključnih koraka za uspješnu implementaciju API Managementa upravljanje korisnicima API-a. Potencijalni korisnici moraju imati mogućnost pretraživanja postojećih API-a kao i mogućnost da bez prevelike zavrzlame mogu početi s korištenjem određenog API-a. Uloga Developer Portala je da pruži upravo te funkcionalnosti. Kroz koncept aplikacija, koji je dobro poznat korisnicima poznatih API-a kao što su Twitter ili Facebook, korisnik kreira svoju aplikaciju te je prijavi kao konzumenta željenih API-a. Uz popis API-a ovdje se nalazi i sva potrebna dokumentacija koju je vlasnik API-a učinio dostupnom. API Manager Da bi API bio dostupan korisnicima on mora biti definiran kroz API Manager. Ključna je riječ definiran, a ne programi- ran. API Manager omogućava nam da brzo posredujemo prema postojećim servisima, kreiramo nove API-e koristeći jedan ili više servisa kroz web konzolu. Takav način kreiranja API-a omogućava nam veliku agilnost. Brzo možemo krenuti, testirati, vidjeti što funkcionira, a što ne. Utrošak vremena je minimalan, a krivulja učenja je veoma blaga, s obzirom na to da nije potrebno znanje ni jednog programskog jezika ili platforme. Naravno, sve je dobre prakse definiranja API-a uputno poštova- ti. Kompletnost API Managera očituje se u činjenici da je API moguće odmah i testirati. Nakon definiranja pridjeljuje ga se planu uporabe kroz koji možemo definirati limite uporabe API-a. Limit se definira kao dopušteni broj poziva u definiranom intervalu. Kroz API Manager moguće je pratiti uporabu definiranih API-a koristeći ugrađene analitičke sposobnosti. Podatke o korištenju moguće je izvesti u CVS datoteku. Ako smo uveli naplatu uporabe, ti podaci mogu biti upotrijebljeni i u tu svrhu. Cloud Console Kao što treba pratiti stanje uporabe API-a, tako je potrebno nadgledati i stanje sistemskog okruženja API Managera. Cloud Console nudi upravo te funkcionalnosti. Alat je prvenstveno namijenjen administratorima i nudi mogućnost kreiranja novog API Management clouda sa svim potrebnim komponentama. Tako je iz web konzole moguće kreirati Management i Gateway clustere. Nakon što je sustav definiran možemo pratiti sistemske parametre kao što su dostupnost, potrošnja procesora, memorije i diska. Jednom kad uporaba API-a nadmaši kapacitete sustava, kroz istu konzolu možemo skalirati sustav dodajući nove nodeove. Otključajte potencijale inovacija kroz API Management Postoji više razloga zašto krenuti s razvojem API-a. Najčešći su razlozi: potreba monetizacije podataka, omogućavanje hibridnog okruženja (cloud), Internet-of-things (IoT), a vrlo često i omogućavanje brzog razvoja mobilnih aplikacija i inovacija. Pri razvoju mobilnih aplikacija programeri očekuju brzu reakciju na potrebu za nekim servisom ili podatkom. Da bi to omogućili, često je potrebno instalirati i konfigurirati serverski softver. IBM API Management skraćuje potrebno vrijeme na minimum. Mobilni timovi imaju slobodu mijenjati zahtjeve prema izloženim servisima, a kako se IBM API Management ne programira nego konfigurira, novi se servisi ili promjene postojećih jako brzo implementiraju. To je presudno u omogućavanju ostvarivanja inovativnih ideja u vrlo kratkom roku. Primjeri iz prakse dokazuju te tvrdnje. Jedna od većih svjetskih inovativnih direct banking banaka (Tangerine) koristi upravo IBM API Management za svoju mobilnu uslugu. Drugi je primjer iz sektora zrakoplovnog prijevoza. Avioprijevoznik WestJet ponudio je partnerima API s informacijama o letovima. Zamjena je to za web scraping koji se je donedavno koristio. Prednosti integracije kroz API jesu jednostavnija i sigurnija integracija uz praćenje korištenja. Trend je da će se sve više integracija izvoditi integracijom kroz API, pa razmislite kako da vaša tvrtka ostane u trendu. API Management SOA Governance Prvenstveno REST/JSON servisi Prvenstveno SOAP/XML servisi Niska razina stabilnosti sučelja Visoka razina stabilnosti sučelja Fokus na uporabu API-a Fokus na funkcionalnosti vlasnika servisa API-ima se upravlja kroz praćenje uporabe i pretplate Servisima se upravlja kroz model upravljanja (SOA Governance) Manja količina API-a Desetci ili stotine servisa Sitno granulirani Veće granulacije Najčešće eksterna uporaba (internet) Najčešće interna ili B2B Pokretač su inovacije u poslovanju, mobilne aplikacije, marketing Pokretač su potrebe enterprise arhitekture Pravo pristupa se implementira uporabom Gatewaya Pravo pristupa se implementira kroz ESB i Gatewaye API i SOA Poznavatelji SOA arhitekture zapitat će se: pa mi imamo ESB, imamo servise, znači li to da već imamo API arhitekturu? Ne znači. Implementirati SOA-u ne znači i implementirati API. Suštinska je razlika u tome da SOA u prvi plan stavlja ponuditelja servisa, a API korisnika. U API arhitekturi korisnik je često i pokretač promjena i očekuje da se te promjene implementiraju veoma brzo. Upravo je u brzini, možemo reći i agilnosti, razlika između SOA-e i API-a. Upravo je brzina, koja omogućava inovativnost kroz brzo isprobavanje (prototipove), to što je jako privlačno. API ne podrazumijeva ponovnu uporabu što je, moglo bi se reći, preduvjet za implementaciju SOA servisa. Sučelje je API-a u prvom redu svrsishodno i jednostavno, dok je sučelje servisa često opširno i upotrebljivo u više različitih scenarija. Znači li to onda da bismo trebali prestati raditi SOA-u i fokusirati se na razvoj API-a? Ne, nikako. SOA i dalje ima svoj važan doprinos labavome povezivanju sustava temeljenog na standardiziranim protokolima kao što su SOAP, XML i HTTP. Činjenica da ste implementirali SOA-u daje vam prednost pred onima koji u isto kreću. Naime, iz postojećih se servisa mogu u vrlo kratkom roku izgraditi API-i koji će kroz inovacije učiniti vaš posao još efikasnijim i atraktivnijim. Razlike i sličnosti API Managementa i SOA Governance metodologije

Mijenjam, mijenjam se | reportaže Krenimo od onih koji po godinama staža u IT-u ipak imaju prednost. IBM, koji je nedavno slavio 100. obljetnicu postojanja, čiji je logo star kao autorica ovog teksta, koji ima tehnologije koje duže umiru nego što prosječna tehnologija danas živi, taj je isti IBM odlučio ovih dana odjenuti novo ruho. Naime, IBM se odlučio žestoko reorganizi- rati i iz temelja promijeniti brendove koje plasiraju na tržište. Tako umjesto Lotusa i Information Managementa danas prema tržištu sjaje Cloud i Systems. Svima koji intenzivno radimo s IBM-om posljednji mjeseci znače otkrivanje koji je proizvod sada gdje i tko je za što zadužen. Zli jezici kažu da nismo jedini koji imamo puno pitanja i da niti unutar IBM-a nije sve sasvim jasno. Mnogi komentiraju da je tranzicija trebala biti brža, no jedno je sigurno – IBM je napravio odličan posao lansirajući novu priču javnosti. Spojivši tri tehnološke konferencije u jednu, dovukli su u Vegas preko 20 000 ljudi. Povreme- no smo svi, ili barem svi s kojima sam pričala, bili izvan sebe. Konferencijski su mi dani na trenutke najviše nalikovali na orijentacijsku trku u štiklama. Predavanja, ali i poslovni sastanci odvijali su se u dva poprilično razdvojena konferencijska pro- stora, pa vam se bez problema događalo da istovremeno birate između dvije ili tri odlične prezentacije dok smišljate kako ćete poslije u drugi hotel odjuriti na važan sastanak. No već sam par dana poslije shvatila da sam obavila posla za nekoliko tjedana rada i cijeli se trud dobro isplatio. Razgovarajući s ključnim ljudima novih IBM-ovih brendova kao što su z-series, Security ili Systems, dobili smo dojam da se u Armoku i Sommersu dobro radi. Ideje su svježe i aktualne, a realizacija proizvoda s kojima mi u CROZ-u redovito radimo je kvalitetna. Konkretni proizvodi kao što su IBM Connections, IBM Liberty for WAS, IBM Integration Bus Advanced, IBM Rational Team Concert i mnoštvo drugih imaju vrlo jasnu strategiju i smisao. IBM nas je počastio i koncertom Aerosmitha. Iako sama nisam veliki obožavatelj benda, mogu se samo pokloniti do poda na trudu, volji i profesionalnosti ekipe od 60+ godina. Toplo se nadam da će i u meni u tim godinama biti volje da se pokazujem u tako dobrom svjetlu, kao što se mogu nadati i da će CROZ u godinama u kojima je IBM imati volje za novu radikalnu pro- Mijenjam, mijenjam se Baš sam se nekako radovala što sam za ovaj broj dobila zadatak prepričati naše dojmove s gigantske IBM-ove InterConnect konferencije i kratkog posjeta Silicijskoj dolini. Sve je bilo sjajno dok nisam krenula pisati, i shvatila da mogu ili krenuti pisati knjigu ili ću vrlo teško sažeti jedan tako impresivan set informacija, povijesnih činjenica, kulturoloških preduvjeta i mogućih smjerova budućnosti. Probala sam s idejom za knjigu, ali urednik se nije složio. Piše: Vedrana Miholić

2015. mjenu načina rada. Očito je iz ovih redaka da me IBM “kupio”, hoće li mu isto uspjeti i na globalnom tržištu, pokazat će vrijeme. Neki novi klinci Na tom istom globalnom tržištu trenutačno pod velikim svjetlima pozornice igraju i neki novi klinci. Možda ne u toliko velikom realnom tržišnom udjelu (za primijetiti je da je IBM-ov godišnji profit 15 puta veći od Facebookova), no u nevjerojatno velikom interesu investitora i javnosti. Silicijska dolina ponovno cvate, a umjesto tratinčica rastu startupovi i investitorske tvrtke. Kao aplikativac, kad si već u “kvartu”, moraš skrenuti do Mountain Viewa i vidjeti te “livade” na svoje oči. Moram priznati da su me se i tamo dojmili (a možda je i u meni problem kad mi se sve svidi A). Osim što ta mala mjesta neodoljivo podsjećaju na moj Samobor i osim što su poduzetnici tamo po karakteru bliži gejmerima, sve nekako odiše visokom razinom tolerancije, slobode, inteligencije i mira. Kao što sve svjetske analize govore, isto kažu i ljudi na terenu – novaca je više nego dobrih priča. Stoga nije ni čudno da se startup groznica može usporediti s onom zlatnom, s tom razlikom da su glavne alatke ove groznice inovativnost i programiranje. Kako malo čovjeku treba da se osjeti sretno što je odabrao ovu struku, koja danas zaista sjaji, od velikog enterprise svijeta reportaže | Mijenjam, mijenjam se do pomalo hipijevskog startupovskog. Posjetili smo i Google i tamo vidjeli puno lipih stvari koje, vjerovali ili ne, imamo i mi u CROZ-u, ali i još nekih koje nemamo (mobilni frizeraj u sklopu kampusa, krevete za popodnevni odmor). Gdje god smo bili, od Stanforda do privatnih domova, svuda odiše doza skromnosti. Osim lokalpatriotskog automobila Tesla i samovozećega Googleova Lexusa, auti nisu nešto čime se ekipa želi isticati. Više uspjehom i dobrom idejom. IT trava je zelenija Bojim se da sam se sad već kompromitirala jer mi je sve super, pa mi je teško i krenuti pisati kako je dolina Napa usporediva s Toskanom i Provansom i koliko je San Francisco živ, a opet opušten. Pa razmišljam da podijelim i dojmove kako je neugodno kad u svako doba dana prolaziš kraj onih automata u Vegasu, a za njima sjede ljudi na kojima sve odiše tugom. Ili da vam kažem da ni Amerika nije više što je bila i da je po novom sve skupo i da ni outleti više nisu što su bili. Pa natrag na pozitivu dok još malo vjerujete mojoj objektivnosti – Sjeverna je Kalifornija nevjerojatna kombinacija lokacija za potpuni hedonizam i onih na kojima, ako ste pametni i educirani, možete ostvariti svoje snove. Nije mi želja da nakon ovog članka vagon mladih i ne više tako mladih odjuri ondje, više da se osvijestimo da je CROZ-ov InterConnect tim u posjetu Googleu: Krešimir Musa, Vedrana Miholić i Vjekoslav Jadrešić Consulting@CROZ Uvođenje lean principa upravljanja poslovnim potrebama Kako postići da svaka aktivnost na poslovno-informatičkom sustavu učini taj sustav još malo boljim umjesto da unese dodatnu kompleksnost? Veliki poslovno-informatički sustavi žive, rastu i nadograđuju se, ali tako istovremeno postaju složeniji i teži za održavanje i korištenje. Bez dobrog upravljanja teško je zadržati početni sklad i red, no tradicionalni način vo- đenja projekata ne uzima u obzir cijeli sustav nego se fokusira na konkretne, kratkoročne ciljeve. Lean principi upravljanja poslovnim potrebama, projektnim portfeljem i projektnom implementacijom omogu- ćavaju jednostavnije planiranje i veću predvidljivost u izvedbi, uz bolju koordinaciju i s manje neugodnih iznenađenja. Više informacija na www.croz.net/consulting moguće ako imaš kapaciteta, ideju, trudiš se, skroman si i realan... osvojiti svijet.

Upravljanje softverskim licencama u svijetu IBM-a | tehnologije i trendovi Upravljanje licencama softvera je svijet za sebe. Microsoft, Oracle, IBM i svi drugi veliki proizvođači softvera imaju svaki svoj način licenciranja. Jedan od najkompleksnijih licencnih sustava svakako je onaj IBM-ov. Korisnicima je često gotovo nemoguće imati pregled nad mnogim IBM-ovim licencnim ugovorima koji su tijekom povijesti rasli i nadalje se konstantno mijenjaju. Ipak, ako koristite IBM softver, bilo bi vrijedno znati kakvo vam je stanje licenci. U slučaju compliance nadzora svaka tvrtka mora dati pregled nad korištenim softverom. Dodatno, čak i bez rizika nadolazećeg nadzora, već sama revizija licenci mogla bi vam donijeti bitne financijske uštede. Zašto je licenciranje IBM softvera složeno? Za jedan IBM softverski proizvod može postojati niz licenci. Softverske komponente ponekad su zapakirane u takozvane bundlove. Takvo je licenciranje izazovno jer često na prvi pogled nije jasno koji su odnosi između licenci i samog softvera. Uz to, ne postoji jedna ili dvije, Upravljanje softverskim licencama u svijetu IBM-a U prethodnom smo broju FYI-a pisali o partnerskoj tvrtki ARS Computer and Consulting GmbH iz Njemačke i našoj međusobnoj suradnji. ARS je specijaliziran za konzalting, razvoj softvera, IBM softver i usluge na području IT infrastrukture. U ovom smo broju odlučili s vama podijeliti iskustvo koje ARS ima na području koje je bitno mnogim našim korisnicima – upravljanje licencama IBM softvera. Članak su napisale Agnes Kuhn, konzultantica za IBM softverske licence i Doris Marwede iz marketinga, stručnjakinje s bogatim iskustvom. Nadamo se da ćete nakon ovog članka znati lakše upravljati vašim IBM licencama. Pišu: Agnes Kuhn i Doris Marwede nego oko stotinu raznih licencnih metrika. Jedna od varijanti je licenciranje bazirano na PVU (Processor Value Units) metrici, gdje troškovi licence nisu bazirani na broju korisnika ili instalacija, nego na kapacitetu procesora koji softver upotrebljava. IBM je razvio PVU tablicu koja svakom procesoru daje određeni broj bodova prema njegovim performansama. Taj se broj mora pomnožiti s brojem procesorskih jezgri stroja kako bi se mogao dobiti broj PVU licenci na kojima se zasniva cijena. Povećana upotreba virtualizacijskih tehnologija i razvoj višejezgrenih procesorskih tehnologija doveli su do dvije varijante PVU licenciranja. U slučaju klasičnog full-capacity licenciranja, sve fizičke jezgre servera moraju biti licencirane. U najgorem scenariju, potrebno bi bilo platiti licence za cijelu farmu servera, iako se IBM softver možda pokreće na virtualnom stroju kojem su dodane samo dvije jezgre. Druga je opcija sub-capacity licenciranje (virtual-capacity). U ovom se slučaju ne broje samo fizičke jezgre, nego samo one dodijeljene virtualnom stroju na kojem se pokreće softver. Ova je varijanta vrlo fleksibilna i često omogućuje puno manje troškove licenciranja od full-capacity modela. Primjer PVU licenciranja Pogledajmo sljedeći primjer: Korisnik ima server s osam fizičkih procesorskih jezgri i dva virtualna stroja (PAR 1 i PAR 2). Po četiri jezgre (virtualne) su dodane svakom stroju. Korisnik je instalirao IBM WebSphere MQ alat na oba stroja. U ovom slučaju nema razlike ako računamo obje metrike (8 fizičkih jezgri i 4 virtualne jezgre na obje particije, PAR 1 i PAR 2). Korisnik je također instalirao IBM WebSphere Application Server (WAS) na stroj PAR 1. S full- capacity licenciranjem i dalje treba licencirati 8 fizičkih jezgri, dok se sa sub-capacity licenciranjem mora za taj proizvod licencirati samo 4 virtualne jezgre na virtualnom stroju PAR 1. Ovaj primjer pokazuje potencijal sub-capacity modela licenciranja, koji je iznimno fleksibilan. Dakako, s njime je teže upravljati.

2015. tehnologije i trendovi | Upravljanje softverskim licencama u svijetu IBM-a IBM License Metric Tool Korisnici koji se odluče na upotrebu PVU sub-capacity licenciranja imaju obvezu upotrebljavati IBM License Metric Tool (ILMT) koji računa potrebu za PVU licencama u (minimalno) kvartalnim izvještajima. Ipak, postoje određene iznimke kada tvrtka nema obvezu generiranja takvog izvještaja s ILMT-om, na primjer kada ima manje od 1 000 zaposlenika. ILMT (ili ručno izrađene) izvještaje korisnik mora verificirati i potvrditi. U slučaju IBM-ova compliance nadzora, mora dati popis softvera i tih izvještaja u posljednje dvije godine. ILMT je nažalost daleko od nepogrešivog kada generira te izvještaje. Ponekad je teško procijeniti jesu li ti rezultati točni, osobito kada je riječ o složenim IBM-ovim softverskim bundlovima jer alat samo generira listu programa u upotrebi. Ponekad su rezultati alata na prvi pogled nerazumljivi i svaki je rezultat uvijek potrebno provjeriti. Korisnik može ručno isključiti neke rezultate iz završne kalkulacije cijene. To se može dogoditi kada, na primjer, znamo da je određeni softver uključen pod nekom drugom licencom. Sam alat nažalost ne omogućuje komentiranje tih odluka. U slučaju nadolazećeg nadzora, dobro je dokumentirati sve informacije koje mogu pomoći razumijevanju ILMT izvještaja. Očito je da je za rad s ILMT izvještajima potrebno znanje i iskustvo rada s IBM softverom. U slučaju nadzora često se ispostavlja da je trošak za konzultanta koji poznaje alat i načine licenciranja i koji će urediti izvještaj i pripremiti korisnika i više nego isplativ. Kako radi iskusan stručnjak za licence? Ako tvrtka nikada nije dokumentirala svoju upotrebu IBM softvera, najprije je potrebno dobiti uvid u sadašnje stanje softvera i licenci. Kao konzultanti, tu možemo podržati tvrtku u generiranju dokumentacije o softveru koji je u upotrebi, njegovim komercijalnim licencama i statusu licenci (je li plaćeno održavanje licenci ili nije). Nakon toga je potrebno verificirati postojeće licence, pregledati povijest kupnje licenci, trenutačno važeće licencne ugovore i dodatke ugovorima, ILMT izvještaje i još mnogo toga. Nakon izrade dokumentacije pregledava se cjelokupno stanje kako bi se pronašao najbolji licencni model koji će zadovoljiti sve tvrtkine potrebe. Jedan od primjera toga može biti prelazak s full-capacity na sub-capacity licenciranje. Konzultant podržava tvrtku pri implementaciji ILMT alata i generiranjem prvih ILMT izvještaja. U nekim slučajevima samo zamjena hardvera može dati bitno manje troškove smanjivanjem PVU vrijednosti. Svakako je uputno uspostaviti procedure za nabavu, podršku i licenciranje softvera, najbolje u jednoj centralnoj točki za cijelu tvrtku. Dobra je praksa obučavanje nekoliko zaposlenika za interne stručnjake za licence. Sve te procedure mogu snažno smanjiti troškove, ali većina tvrtki ne kontaktira stručnjake za licenciranje poput nas sve dok im se ne najavi IBM-ov compliance nadzor. U tom slučaju obično nemamo dovoljno vremena za optimizaciju broja i vrsti licenci nego moramo biti pragmatični i zaštititi tvrtku od mogućih gubitaka. Budući da iskusan konzultant poznaje procedure IBM-ova nadzora, može podržati tvrtku prije nadzora kroz pripremu, ali i kroz podršku tijekom samog nadzora putem generiranja kvalitetnih izvještaja i njihova tumačenja. U tim situacijama nemate vremena za gubljenje, pozovite stručnjaka što je prije moguće. Izgled IBM License Metric Tool alata Isključivanje rezultata iz ILMT izvještaja

nadnaslov | rubrika Upravljanje znanjem u APIS IT-u | projektne priče Radite u organizaciji koja ima osigurane stabilne i dugoročne prihode i kojoj konkurencija ne predstavlja ozbiljniju prijetnju. Interni procesi su visoko optimizirani. Horizontalna i vertikalna komunikacija Upravljanje znanjem u APIS IT-u Tvrtke sve više uviđaju koliko je bitno upravljati znanjem koje postoji unutar njih, ali malo njih poduzima konkretne korake u tom smjeru. U ovom vam broju donosimo iznimno zanimljivu projektnu priču iz naše partnerske tvrtke APIS IT d.o.o., koja je učinila upravo to. Ivana Žugaja, voditelja projekta implementacije upravljanja znanjem, zamolili smo da čitatelje FYI-a upozna s ovom temom i samim projektom. Osnovni ekonomski resursi više nisu kapital, prirodni resursi ili rad. To je, i ostat će, znanje. Peter Drucker je na zavidnom nivou i sva se iskustva i znanja s prethodnih poslova direktno ugrađuju u sustav (učeća organizacija). Uspostavljen je sustav inovativnosti. Fluktuacija zaposlenih je neznatna, a kod novog zapošljavanja uspijevate naći potpuno kvalificirane kandidate sposobne za trenutačno uključivanje u vaš proizvodni proces. Ne postoji tehnološka, metodološ- ka ili organizacijska potreba za unapređe- njem postojećeg načina rada... Za sve one koji su svjesni kako ne ispunjavaju većinu gore navedenih teza slijedi objašnjenje, ali i rješenje – upravljanje znanjem. Ostalima savjet da barem pročitaju zadnja dva odlomka ovog teksta. Upravljanje znanjem Upravljanje znanjem (Knowledge Management – KM) u pojedinoj organizaciji možemo definirati kao proces koji je odgovoran za prikupljanje, analizu, spremanje i dijeljenje informacija, ideja i znanja. Znanje u organizaciji nastaje radom, iskustvom, obrazovanjem, kontaktima s kupcima, rješavanjem problema, odnosno grešaka u radu proizvoda i/ili usluga, dokumentacijom i uputama. Znanje također nastaje kroz internu komunikaciju između zaposlenika te kroz komunikaciju s vanjskim sudionicima: dobavljačima, partnerima, korisnicima pojedinih proizvoda i usluga, konkurencijom. Velik dio znanja postoji izvan organizacije i dostupan je preko raznih kanala poput interneta, medija, knjižnica, edukacijskih ustanova, konzultantskih tvrtki i slično. Cilj je upravljanja znanjem uspostaviti sustav upravljanja znanjem u nekoj organizaciji kako bi se omogućila: Piše: Ivan Žugaj Mudrost (zašto?) Primjena znanja u danim okolnostima; osobne procjene i stavovi; poduzimanje akcije Znanje (kako?) Razumijevanje značenja informacije Priprema (temelj) za akciju Informacija (tko, što, kada, gdje?) Strukturirani, povezani podaci Podatak Neobrađeni materijali; činjenice o događajima Odnos: podatak – informacija – znanje – mudrost. Cilj je uspostaviti sustav za upravljanje znanjem koji objedinjuje prikupljanje i korištenje informacija i znanja. Mudrost predstavlja sposobnost organizacije da se prikupljeno znanje primijeni na optimalan način onda kada je to potrebno. Podatak, informacija, znanje, mudrost

2015. projektne priče | Upravljanje znanjem u APIS IT-u - bolja horizontalna suradnja i kolaboracija među timovima i zaposlenicima (mentori, radionice, umrežavanje zaposlenika, povezivanje u radne grupe – zajednice; uspostava novih kanala komuniciranja) - kvalitetnije upravljanje, dijeljenje te ponovna upotreba informacija, ideja i znanja unutar organizacije (zaposlenicima je u ciljevima zadan transparentan prijenos znanja – eksternalizacija znanja na druge) - veća učinkovitost u obavljanju poslova (projekata): baze znanja, naučene lekcije, riješeni problemi. Postoji više podjela znanja u nekoj organizaciji: na novo i staro, aktivno i pasivno, projektno i izvanprojektno znanje itd. Međutim, najvažnija je podjela na eksplicitno (explicit) i tacitno (tacit). Eksplicitno je znanje ono znanje koje je lako opisivo i strukturirano prema svome sadržaju. Nalazi se u knjigama, stručnim časopisima, raznoj dokumentaciji, bazama podataka – dakle u materijaliziranoj formi. Tacitno je znanje često prešućeno ili intuitivno. Smatra se da je to znanje podrazumijevano. Ljudi se često i ne pitaju zašto ili kako pojedinac obavlja svoj dio posla na postojeći način. Takovo je znanje često i teže dokumentirati, tj. materijalizirati, jer se ono zapravo nalazi u glavama zaposlenika, međutim upravo je tacitno znanje podloga za inovacije i poboljšanja u organizaciji. Treba težiti ostvarivanju transfera znanja u organizaciji kako bi ono bilo na korist svim zaposlenicima. Postoji više smjerova transfera znanja, a posebno treba raditi na eksternalizaciji, to jest transferu tacitnog znanja u eksplicitno, kako bi se moglo zapisati u nekom formatu i tako povećati mogućnost primjene. Primjeri za to su tjedni ili mjesečni izvještaji, recenzije, dnevnici rada, članci, analize, izrada prezentacija i slično. Time postižemo da se tacitna znanja i iskustva s projekata obuhvate, zapišu i prenesu između zaposlenika, a potom i primijene na drugim poslovima. Metodologija upravljanja znanjem u APIS IT-u Postoje različite metodologije koje pokrivaju područje upravljanja znanjem u dostupnoj literaturi. Ovo područje treba biti dobro povezano sa strategijom, ljudskim potencijalima, sustavom za kvalitetu te internim procesima u organizaciji. U APIS IT-u sustav upravljanja znanjem bazirali smo na četiri ključna stupa, tj. kategorije: 1. ljudi 2. procesi 3. tehnologija 4. upravljanje Ljudska je komponenta ključna u cijelom sustavu i tu se utječe na promjenu organizacijske kulture i pravila dijeljenja znanja i informacija u organizaciji. Fokus je usmjeren na povezivanje i motiviranje pojedinaca za pomake u načinu rada. Procesi su važni kako bi se definiralo što i kako se treba provesti unutar sustava upravljanja znanjem u pojedinoj organizaciji. Upravljanje je presudno za postavljanje smjernica i pravila, usmjeravanje ciljeva te nadzor cijeloga sustava, kao i za upravljanje promjenama u sustavu ovisno o rezultatima pojedine faze te reakcijama zaposlenika i menadžmenta. Tehnologija je važna kako bi efikasno podržala postavljene ciljeve. Kvalitetna tehnološka platforma treba omogućiti efikasno i efektivno upravljanje znanjem u organizaciji te podržati ključne principe za upravljanje znanjem (vidi okvir). Uspješnost uvođenja sustava za upravljanje znanjem ovisi o uspostavljanju dobrog balansa i suradnje između navedene četiri kategorije. Stoga se kod uspostave sustava upravljanja znanjem Ključni principi za upravljanje znanjem 1. Collecting (služi za obuhvat eksplicitnog znanja: povezivanje pitanja s odgovorima) & connecting (služi za obuhvat tacitnog znanja: povezivanje s ljudima koji znaju odgovore) 2. Doing from learning (korištenje, tj. primjena prethodnih iskustava i znanja na novom projektu – uvid u baze znanja, prethodna iskustva, korisne informacije) & Learning from doing (kreiranje novih znanja na osnovu upravo stečenih iskustava na projektu – izrada nove naučene lekcije, riješenog problema...) Eksplicitno znanje: podaci, informacije, dokumenti, baze podataka, datoteke Tacitno znanje: iskustva, stavovi, kompetencije, razumijevanja Krajnji je cilj sustava upravljanja znanjem u organizaciji omogućiti da znanje i dobre ideje koje dolaze od internih ili vanjskih IT stručnjaka potaknu poboljšanja i inovacije u području i specijalnostima koje organizacija pokriva

Kreativnost i inovativnost Kreativnost je termin koji se obično koristi za aktivnost stvaranja novih ideja, pristupa ili aktivnosti u poslu koji se obavlja. Inovativnost je proces stvaranja i primjenjivanja navedenih kreativnih ideja u određenom kontekstu (s ciljem povećanja profitabilnosti putem smanjivanja troškova i/ili povećanja prihoda). u APIS IT-u istovremeno radi na izgradnji sve četiri ključne kategorije kako bi se moglo uskladiti i dopuniti pojedine tehnike i principe za upravljanje znanjem unutar kategorija. IBM Connections Kao tehnološka platforma za upravljanje znanjem u APIS IT-u odabran je sustav IBM Connections. Riječ je o platformi koja osim same aplikacije Connections obuhvaća IBM best-of-breed komponente (WebSphere Application Server, DB2, FileNet, Cognos, Forms, Sametime) u formi paketa, tj. jedinstvenog proizvoda. IBM Connectionsi predstavljaju integraciju funkcionalnosti društvene mreže za tvrtku, EDM (Enterprise Document Management) sustava te skupa alata, tj. widgeta za podršku timskom radu (projektima). S obzirom na mogućnosti, u APIS IT-u Connectionsi su se pokazali kao idealna platforma koja je ispunila sve funkcionalne i nefunkcionalne zahtjeve, tj. kriterije koje je projektni tim bio postavio. Kolaborativne mogućnosti alata koriste se za obuhvat tacitnog znanja, a mogućnosti koje pruža sustav za podršku rada s dokumentima i projektnim aktivnostima za obuhvat eksplicitnog znanja. Trenutačno je u APIS IT-u implementirano više scenarija, tehnika i principa za upravljanje znanjem definiranih u fazi I i II projekta, te je kreirano nekoliko zajednica koje pokrivaju određena poslovna područja u projektu upravljanja znanjem. Primjeri za to su: Naučene lekcije, Povratak sa školovanja, eKnjižnica i drugi. U daljnjem se radu u APIS IT-u planira primjena Connectionsa u upravljanju projektima u smislu da se za svaki novi projekt otvara nova zajednica unutar sustava te upotrijebe kolaborativne i ostale mogućnosti koje ovaj sustav pruža. Ta- kođer je u planu implementacija rješenja LMI (Like My Idea) tvrtke CROZ, komponente koja je nadogradnja funkcionalnosti samih Connectionsa, kako bi se omogućila dodatna podrška za upravljanje idejama. Sama je platforma dosta otvorena za pro- širenje i povezivanje s drugim sustavima putem OpenSocial specifikacije. Projektni trokut Staro pravilo u PM-u kaže: odaberi dva od sljedeća tri kriterija kao prioritete za svoj projekt: kvaliteta, brzina, cijena. Kako biste reagirali kada biste mogli primijeniti sva tri kriterija na nivou cijele organizacije? Koliko god da su sva tri kriterija podjednako važna za svaku organizaciju, u zadnje se vrijeme upravo brzina nameće kao “malo jednakiji” od ostalih kriterija i stoga to treba imati u fokusu. Rješenje je u izgradnji sustava za upravljanje znanjem, strukturnim promjenama postojećeg načina rada te uspostavom organizacijske kulture dijeljenja znanja i ideja među zaposlenicima i menadžmentom. Za to su naravno potrebni odlučnost, određeno vrijeme i početno ulaganje, no imamo li u današnjem poslovnom tempu i očekivanjima uopće alternativu? Čak i ako ste među rijetkima koje pitanja iz uvoda u ovaj članak nisu previše uznemirila – trebali biste barem težiti zadržati te dobre Widgeti unutar Connectionsa služe za podršku rada s dokumentima (Files, Library), timsku kolaboraciju (Wiki, Forums, Surveys, Blog, Status Updates), radu s idejama (Ideation Blog) te projektnim aktivnostima (Events, Activities). Ideja je da se za većinu poslova kreiraju zajednice (Communities) s članovima (Members) koje se dalje mogu horizontalno i vertikalno povezivati (Related Communities i Subcommunities). Upravljanje znanjem u APIS IT-u | projektne priče karakteristike vašeg sustava. Rješenje je opet isto: upravljanje znanjem! Zaključak Sustav dijeljenja i upravljanja znanjem treba postaviti kao centralni sustav unutar organizacije tako da se lako integrira u po- slove i postojeće procese rada u organizaciji. To će se postići na taj način da se ključne kategorije upravljanja znanjem: ljudi, procesi, tehnologije i upravljanje, implementiraju u organizaciji putem onih tehnika i principa za upravljanje znanjem koje su najpriklad- nije za pojedinu organizaciju. Krajnji je cilj sustava upravljanja znanjem u organizaciji omogućiti da znanje i dobre ideje koje dolaze od internih ili vanjskih IT stručnjaka potaknu poboljša- nja i inovacije u području i specijalnostima koje organizacija pokriva. Na taj se način cijela organizacija transformira u formu učeće organizacije oko jedinstvene platforme koja povezuje rad na izvršavanju svakodnevnih poslovnih zadataka s kon- tinuiranim poboljšanjima i inovacijama u vlastitom proizvodnom ciklusu. Time se osiguravaju preduvjeti za ostvarenje poslovne izvrsnosti kao i prostor za daljnji poslovni rast i napredak organizacije.

2015. tehnologije i trendovi | tehnološki radar Pišu: Ivan Krnić i Hrvoje Šimić Četvrta verzija tehnološkog radara odražava lagane zaokrete u kori- štenim tehnologijama. Razvese- lila su nas produkcijska iskustva s funkcijskim programiranjem, koje odavno više nije egzotična disciplina. Automatiza- cija infrastrukture i dalje nam je u fokusu, a u tom smjeru nas najviše raduje pojava Dockera. Lean i agile dokazuju svoj primat u području metodologija. Riječ je o dugo- ročnim konceptima koji s vremenom samo potvrđuju svoju vrijednost. Programski jezici Konačno imamo i produkcijske projekte koji su glavninom pisani u Scali, i na temelju dobrih iskustava taj je jezik sad došao u središte našeg radara kao preporuka za korištenje ako u timu imate potrebna znanja. Za Apple razvoj preporučamo korištenje novog programskog jezika Swift. Jezike poput Pythona i Rubyja danas ne koristimo u velikim projektima, osim za skriptiranje. Stoga smo ih spojili u jednu točku na radaru uz preporuku da ih koristite kad su vam potrebni manji izolirani komadi koda. Nove funkcionalnosti u Javi 8 zavrijedile su posebnu točku na našem radaru. Streamovi i lambde kao ključni Tehnološki radar Pola je godine prošlo od našeg zadnjeg tehnološkog radara. Pogledajte čime smo se u međuvremenu bavili, koje smo tehnologije i metodologije proučavali, u koje smo se zaljubili, a od kojih smo putem i odustali... elementi funkcijske paradigme u Javi zavrijedili su da ih pilotirate u svom razvoju ako želite biti u tijeku s razvojem u svijetu Jave. Platforme i alati Jedan od velikih tehnoloških pomaka u našoj percepciji tehnologije u zadnjih pola godine svakako je Docker. Nekoliko CROZ-ovih proizvoda, odnosno servisa, uspješno se izvršava na Dockerovu virtualizacijskom stacku, pokazalo se da na taj način imamo brži razvoj, čišću konfiguraciju i konzistentnije izvršne okoline. ElasticSearch se također pokazao kao vrlo korisna platforma kod bilo kojih projekata s polustrukturiranim podacima koje je potrebno pretraživati u cijelom tekstu. Kombinaciju ElasticSearch – LogStash – Kibana (tzv. ELK stack) preporučamo kao osnovno rješenje za lako praćenje logova i stanja sustava. Metodologije i prakse Lean i agile vrijednosti su nam i dalje u centru radara te predstavljaju osnovne smjernice u razvojnom procesu. Posebno se potiče izgradnja fiksnih timova koji funkcioniraju duže vrijeme, što je osnovni preduvjet postizanja sinergije među članovima tima. Takvi timovi pokazuju manje trenja, produktivniji su, a njihovi članovi puno jednostavnije međusobno dijele znanje. Važnost korisničkih testova prihvaćanja ne treba posebno naglašavati nego im veliku važnost treba dati i tijekom samog razvoja. Sve razvojne aktivnosti trebaju biti usmjerene ka konačnom cilju, a to je implementacija koja zadovoljava korisničke testove prihvaćanja. Ključnu ulogu u tom procesu imaju kriteriji prihvaćanja koji usmjeravaju implementaciju. Praksa Acceptance test-driven development (ATDD) promovira upravo takav način rada u kojem je implementacija podređena zadovoljavanju kriterija prihvaćanja. Jasno definirani kriteriji prihvaćanja jamče kraću i ispravniju implementaciju. Impact mapping je tehnika prepoznavanja i prioretiziranja zahtjeva koja u fokus stavlja poslovni cilj. Odgovaranjem na pitanja na koje dionike i kako treba utjecati dolazi se do skupa mogućih funkcionalnosti čijom će se implementacijom postići zadani cilj. Takav pristup omogućuje lakši odabir minimalnog skupa funkcionalnosti čijom će se implementacijom zadani cilj ostvariti na optimalan način.

Apache Camel Značenje boja PRIMIJENITI PILOTIRATI PROCIJENITI PROMIJENITI Play Akka
Scala FreeMarker JSF JPA ClearQuest CoffeeScript Spray JSP BPEL GWT Deployit OrientDB TorqueBox Azul Zin Jawr OpenShift Ansible Application as a service (Meteor, deployd) MySQL Ant CVS WS-* Ivy TDD Kanban Infrastructure automation Continuous integration Asynchronous/ Responsive architecture Model driven development Structured logging Immutable arhitecture CQRS Fully stateless architectures I only do X (X e { Java, CSS, JavaScript, SQL, ...}) Manual testing No performance tracking Waterfall Lean/Agile values, principles and methods Groovy JavaScript gradle Docker Camunda Twitter Bootstrap Java extjs HTML5 Vaadin Spring Framework Thymeleaf Xtend React D3.js Less Sass AngularJS Swift Skriptni jezici Java 8 Nashorn Quartz OSGi Flex Apache Axis EJB2 Hadoop Cassandra Grails Git Alfresco Selenium Maven WebSphere Liberty Profile Structr Puppet Chef NodeJs CloudFoundry IBM BlueMix Packer Geb Wro4j Redis UrbanCode uDeploy Event sourcing Impact mapping Documentation inproprietary/ binary formats Apache Camel Spock Spring Boot IntelliJ IDEA ElasticSearch/Kibana/ Logstash MongoDB Activiti NoEstimates Continuous delivery Continuous deployment Security/penetration tests as deliverable Nova stavka Prišao bliže centru Udaljio se od centra tehnološki radar | tehnologije i trendovi Neo4J rabbitmq Reactive Systems Everybody commits to same source tree WebSphere App Server < 8.5 FYI by CROZ / broj 18 /svibanj 2015. | 41 Spring Integration ATDD Hawt.io Orientdb OpenStack Vaadin Hazelcast

2015. Posljednjih se nekoliko godina u razvijenim zemljama učenici potiču na to da se orijentiraju na takozvana STEM područja (Science, Technology, Engineering, Mathematics). Europskom unijom vladaju rekordne stope nezaposlenosti mladih ljudi, unatoč tome što se nepopunjena radna mjesta u informacijskim tehnologijama broje u stotinama tisuća. Nameću nam se dva pitanja. Prvo, otkud dolazi povećana potreba za tim apstraktnim i tehničkim znanjima? Drugo, kako to da dobre plaće i povoljni uvjeti rada (a neke su IT firme danas postale poznate po ugađanju svojim zaposlenicima) nisu dovoljni da privuku mlade ljude i da se zadovolji ta potreba za stručnim kadrom? Veća potreba za apstraktnim razmišljanjem dolazi od činjenice da smo kao vrsta napredovali tako daleko da su problemi za koje imamo već razvijene instinkte prestali biti presudni. Naše urođene sposobnosti nisu toliko korisne ako želite odgovore na suvremena pitanja: Jedem li zdravo? Hoću li cijepljenjem pomoći ili odmoći svom djetetu? Pregrijava li se planet zbog nas? Jedino što nam je evolucija ostavila a da nam je tu od koristi jesu naše sposobnosti analitičkog, kritičkog i kreativnog razmišljanja. A te sposobnosti nije lako razviti. Važan aspekt tih kognitivnih sposobnosti jesu vještine koje koristimo tehnologije i trendovi | Dajmo djeci da programiraju Dajmo djeci da programiraju Piše: Hrvoje Šimić Trebamo li djecu učiti programiranje? Zar nam u 21. stoljeću najviše nedostaju vojske tehnologa, kodera koji sve vrijeme provode gledajući u ekran računala? Možda je ta disciplina preteška za naše učenike? Odgovori se možda nalaze u samoj ljudskoj prirodi. kod programskog inženjerstva. Suživot s računalom nije lak – ono ne prihvaća nelogičnosti i nedorečenosti, ne da se manipulirati obećanjima i isprikama, a s druge strane nagrađuje razumnost i sustavan pristup. Naravno, učenje tih vještina i stjecanje takvih znanja ne znači da će sva ta djeca postati programeri, na isti način na koji sat likovnog nije usmjeravanje na karijeru umjetnika, niti je igranje košarke nužno priprema za NBA ligu. Istina je kako projektiranje informacijskih sustava nije za svakoga, a čini mi se da nije ni toliko važno za društvo imati vojske specijalista programera. Važnije je proširiti opću kulturu informacijskog doba, koja djeci daje osjećaj da oni to mogu, usmjerava im maštu i nadahnjuje ih za samostalno istraživanje. Ponekad je dovoljno djeci omogućiti da (poput nekadašnjih trgovačkih putnika) uglave jednu nogu kroz vrata cijelog jednog novog svijeta. Nepodnošljiva lakoća programiranja Strojari trebaju sofisticirane alate i materijal, biolozi trebaju prostrane ekosustave, eksperimentalni fizičari superskupe supersudarače, a makroekonomisti (ponekad) cijele države da na njima eksperimentiraju. Programiranje nema tako velike zahtjeve. Ako imate računalo na raspolaganju (nešto što je, na sreću, danas postalo normalno), jedina bitna barijera je vaša mašta. Internet je krcat informacijama i ljudima koji su spremni pomoći, a mogućnosti koje se otvaraju pred djecom su nepregledne. Programiranje je dostupno i na drugi način. U “analognim” tehnologijama važno je biti pažljiv i pedantan, a vjerojatno imati i sreće da vam rezultati ispadnu jasni i nedvosmisleni. Iako se može reći da je takvo iskustvo korisno jer kod djece razvija sustavnost i pedantnost u radu, kod mlađe ili manje motivirane djece to može biti ozbiljna prepreka na početku. Programiranje je, s druge strane, prilično egzaktno: pogreške se lako ispravljaju, a program uvijek daje jednake rezultate, bar dok se trudimo da ga ne zakompliciramo preko svake mjere. Sve to čini programiranje inženjerstvom koje je vrlo dostupno najmlađima. Pokazuje im kako kombinacijom jednostavnih gradivnih elemenata možemo postići složeno ponašanje, i obrnuto: raščlaniti složeni sustav na jednostavnije dijelove da bismo ga lakše razumjeli, otkrili što ne radi i izgradili nešto bolje. Uči ih kako izgraditi jednostavna sučelja kojima skrivate implementacijsku kompleksnost da bi drugima omogućili da lakše riješe probleme više razine. Kao što je Isaac Newton vidio dalje zato što je stajao na ramenima divova, tako i današnja tehnologija može više jer stoji na već izgrađenim slojevima čija su sučelja jednostavnija za razumjeti i koristiti od njihove izvedbe. Atmosfera Scratch radionice u CROZ-u

Minecraft Znate li koja je najprodavanija igra za PC svih vremena? Ne, nije ratna igra. Nije neka pucačina ili simulacija života urbanih kriminalaca. Gotovo bez marketinga, atraktivne grafike ili podilaženja niskim strastima to je uspjelo maloj “indie” firmi igrom Minecraft. Ona dokazuje kako djecu nije potrebno siliti da nauče kako stvarati u digitalno doba. U Minecraftu dijete nije pasivno, ne prati zadanu putanju, nego samostalno istražuje i izgrađuje vlastiti svijet. Počevši od prvog skloništa i izrade primitivnih alata, djeca mogu naučiti konstruirati složene mehanizme i automate korištenjem mehaničkih i kvazielektroničkih elemenata. Dajmo djeci da programiraju | tehnologije i trendovi CROZ-ovci okupljeni u udrugu Programerko imaju praktično iskustvo podučavanja djece programiranju od vrtićke dobi sve do završnih razreda osnovne škole. Djecu smo učili multimedijalnom programiranju koristeći MIT-ov sustav Scratch. Prve su vježbe pristupačne i nezahtjevne, no u nekim smo se naprednim vježbama dotaknuli i tema iz fizike i matematike. Štoviše, mnoge pojmove poput decimalnih brojeva, koordinatnih sustava, kutova i slično ti su učenici naučili na Scratch radionici i prije nego u školi. Evo za primjer neke od najnaprednijih vježbi koje su osnovnoškolci kod nas radili. Primjeri iz Scratcha Vatromet Vrlo efektna fizikalna simulacija vatrometa može se izvesti programski. Ilustrira osnovna pravila gibanja tijela pod utjecajem gravitacije, a djeci daje puno prilika da se igraju s bojama i vizualnim efektima. Labirint Bube nasumično tumaraju “pokušavajući” izaći iz labirinta. Djeca uče kako potpuno bezumni i besciljni procesi mogu iskazati nešto što izgleda kao namjera, čak i postići neke rezultate ako im damo dovoljno vremena. Fraktali Kako od obične crte ili trokuta neprekidnim umnažanjem možemo dobiti složene oblike koji izgledaju gotovo organski, a ujedno i estetski interesantno. Djeca uživaju igrajući se s tim oblicima.

FYI by CROZ - broj 18

FYI by CROZ - broj 18

More Decks by Tvrtka CROZ

Other Decks in Technology

Featured

Transcript