44
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 soſtverske arhitekture PrEDStavljamo PartnErE: CSI ltd.

Fyi 18 web

Embed Size (px)

Citation preview

Page 1: Fyi 18 web

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.

Page 2: Fyi 18 web

IZDVAJAMO IZ AKTUALNIHTEČ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 rationalperformance tester

certified SCRUM PRODUCTOWNER (agile42)

management 3.0 (jurgen appelo)

Page 3: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 3

nadnaslov | rubrikaFYI 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 833E-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 kvalite-tom softvera. Testiranje, kao i sigurnost u prošlom broju, su

teme kojih nikada nije previše. Sigurnost je nekako atraktivnija tema, često čitamo u medijima o najnovijim sigurnosnim propustima i gledamo holivudske filmove o hakerima. A testiranje je ostalo ružno pače softverske industrije. Pa hajʼmo to ispraviti! U ovom broju čitajte o automatiziranju testiranja, performansnom testiranju, testiranju mobilnih aplikacija… Posebno smo ponosni što se možemo pohvaliti da nas je Erste&Steiermärkische banka u jakoj međunarodnoj konkurenciji odabrala za strateškog outsourcing partnera u području testiranja. Priča se savršeno uklapa u temu broja.

Kada ste sve to proučili, spremni ste za ispit zrelosti! Oslanjajući se na TMMi Foundation, naši stručnjaci su osmislili učinkovit i jednostavan model za provjeru zrelosti organizacije u području testiranja. Dakle, ako želite provjeriti kako stojite s testiranjem i pripremiti strategiju unapređenja testiranja, ovo je idealan prvi korak. Topla preporuka od strane vašeg uvodničara!

Kažu da svaki programer (a pogotovo javaš) želi razvijati svoj vlastiti framework. Ipak, to nije jednostavan zadatak, a zahtijeva i jako puno znanja i iskustva. Naš tim predvođen Damirom Muratom razvio je g*rich, framework koji predstavljamo u ovom broju. Rezultati su vrlo dojmljivi; ubrzali smo i pojednostavnili razvoj, korisničko sučelje je ergonomično i funkcionalno (i seksi), ugrađena je i

integracija s ECM i BPM sustavima. Standardizacija i sigurnost manje su vidljivi, ali podjednako važni dobitci. I što je najljepše, stvar dokazano radi u praksi. Iako je početna ideja bio interni razvoj, g*rich je zamišljen tako da ga mogu koristiti i naši korisnici! Još jedna topla preporuka!

Ovaj uvodnik pišem u slatkom pred-QED iščekivanju. Naša mala konferencija (Dalmatinci bi rekli “smišna”) se ove godine preselila u Rovinj. Sve ono zbog čega volimo QED, a to je prije svega pozitivna atmosfera i kvalitetan sadržaj, ostaje nepromijenjeno. Puno je i novosti, dolaze svjetske face; Andreu Tomasinija vjerojatno ne treba više predstavljati, Grady Booch je računalni znanstvenik i filozof, a pomalo i umjetnik. Pričat ćemo o kreativnosti i inovativnosti, bit će baš super!

Naša ekipa bila je u Americi i vratila se puna dojmova. S jedne strane velika preobrazba IBM-a, veterana informatičke industrije, u koju se moglo uvjeriti dvadeset tisuća sudionika InterConnect konferencije. S druge je strane nepodnošljiva lakoća Silicijske doline, Google, Facebook i novi poslovni modeli. Ostaje nam promatrati i doživjeti koji će smjer prevladati. Ja bih se kladio na dijalektiku.

Za kraj ovog uvodnika jedna jako bitna tema: treba li djecu učiti programiranju? Mi mislimo da treba, ali program po kojem se radi u našim školama nepopravljivo je zastario, a praksa još i više. Iskustva s radionica za djecu koje organizira udruga Programerko pokazuje da se programiranje može učiti drugačije. Naprednije i zabavnije. Pozivamo i vas da nam se pridružite u mijenjanju sadašnjeg stanja.

Page 4: Fyi 18 web

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

Page 5: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 5

nadnaslov | rubrikaFYI by CROZ | vijestiFYI by CROZ | vijesti

održano događanje Prediktivna analitika i Fraud ManagementDogađ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 jezicimaCroZ 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 poslov-nih aplikacija. Riječ je o platformi koju koriste razvojni inženjeri i sistemski administratori za izradu, distribuciju i po-kretanje aplikacija, koje su onda potpuno portabilne i mogu se bilo gdje pokretati.

Uspješno održan peti Smart dayPeto 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 start-up tvrtkama na događanju implicoCROZ 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.

Page 6: Fyi 18 web

6 | FYI by CROZ / broj 18 / svibanj 2015.

tema broja | Provjera zrelosti testnog okruženja

Zagonetka na početku:• svi se hvale da ga

upražnjavaju• svi se hvale da ga

imaju dovoljno• svi se hvale da su

odlični u tome• svi se hvale da ne

trebaju pomoćne alate• svi se hvale da je “primajuća” strana

sretna i zadovoljna.

O čemu se radi? O testiranju, naravno. Rijetko koja disciplina u razvoju softvera je toliko bitna a da se tako olako ignorira i preskače. Uzmimo, recimo, analizu poslovnih zahtjeva. Čisto sumnjam da će naručitelj posla samo reći: “E, cure i dečki, treba nam internet bankarstvo, dajte napravite nešto. Hvala.” S druge strane, prečesto čujem riječi: “E, cure i dečki, dajte malo stisnite i dovršite implementaciju pa da idemo dalje, testiranje ćemo napraviti kasnije. Hvala.” Zašto je tome tako? Nažalost, vrijednost koju testiranje

isporučuje nije vidljiva na prvi pogled. Ako nešto radi ono što treba, radi zato što je dobro isprogramirano, a ne zato što je napisan test.

Čisto mehanički gledano, da poznajemo poslovnu domenu do najsitnijih detalja, da su zahtjevi potpuno jasni, da je razvojno okruženje idealno, da je izvedbena strana savršena i bez ijednog buga, testiranje ne bi ni bilo potrebno: sve bi radilo iz prve i baš ono što treba, za jednog ili deset tisuća korisnika istovremeno, 24/7/365. Ali svijet razvoja softvera nije takav. Niti je poslovna domena poznata, niti je infrastruktura bezgrešna. Fantastične stvari koje aplikacije rade kad su pod povećanim opterećenjem ne trebamo ni spominjati. I baš zato nam je potrebno testiranje, da u takav nepredvidljiv svijet uvedemo određenu količinu sigurnosti i predvidljivosti, da se ne čudimo kasnije kad se 2 (slovima: dva) korisnika istovremeno prijave u aplikaciju i time uzrokuju zaglavljivanje cijelog sustava jer se odjednom potrošila sva memorija.

Priznajem da malo dramatiziram, iako je ova priča o dva korisnika, vjerovali ili ne, istinita (vidio svojim očima, op. a.).

Provjera zrelosti testnog okruženja

Pet razina zrelosti testiranja, kako ih postavlja tMMi Foundation

Svijest o potrebi za kvalitetnim i strukturiranim testiranjem raste iz godine u godinu, čemu smo i mi iz CROZ-a dijelom zaslužni, što kroz objavljivanje ovakvih članaka, što kroz pokrivanje testiranja na QED-u, a naravno i kroz prakticiranje testiranja na svojim projektima.

Zar nam stvarno treba testiranje?Testiranje je, baš svi će se složiti, kompleksna disciplina koju možemo promatrati iz više kutova i koju možemo početi primjenjivati na različite načine. Ponekad nam je dovoljno odraditi završno korisničko testiranje i spremni smo za produkciju, no ponekad je nužno proći kroz

Piše: davor čengija

Kako napraviti brzi pogled u stanje testnog okruženja u organizaciji?

Page 7: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 7

Provjera zrelosti testnog okruženja | tema broja

sve razine, od unit testova na izvornom kodu do testiranja ponašanja cjelokupnog sustava u slučaju ispada dijela infrastrukture. Koji ćemo pristup imati jako ovisi o samom sustavu koji testiramo. Ako se radi o internoj aplikaciji za prijavu godišnjeg odmora, onda je možda dovoljno isprobati radi li sve na testnoj okolini i spremni smo za produkciju. Uostalom, ako nešto pođe krivo i zapis o mom godišnjem se izgubi, pa dobro, nema veze, prijavit ću ga ponovo. Ako se s druge strane radi o famoznom internet bankarstvu, onda vjerojatno želimo testirati i izvorni kod (razne izračune, provođenje transakcija i tako dalje) i sigurnost (recimo na OWASP Top 10 – za više detalja vidi okvir u članku o g*richu), ali i ponašanje sustava u slučaju nedostupnosti nekog ključnog dijela infrastrukture. Tu je, naravno, i regresijsko testiranje – nakon puštanja u rad novih funkcionalnosti želimo znati rade li one stare kao i prije. Nije svako testiranje prikladno, ili bolje rečeno isplativo u svakoj situaciji, no prepoznavanje pravog trenutka je vještina koja se uči i brusi kroz vrijeme. Kako testiranje često predstavlja pa čak i 30–40% ukupnog troška projekta, dobrom organizacijom i planiranjem aktivnosti ne samo da podižemo kvalitetu isporučenog softvera i sustava u cjelini nego i smanjujemo cijenu projekta.

Koliko je neka organizacija zrela u pogledu testiranja se može relativno brzo i jednostavno izmjeriti. Naime, softverska zajednica se kontinuirano trudi podići razinu kvalitete cjelokupnog proizvodnog procesa, tako da su de facto standardi za razvoj postavljeni u vodiču pod imenom CMMI, Capability Maturity Model Integration. Pandan CMMI-u u domeni

testiranja definira TMMi Foundation, strukovna organizacija koja objedinjuje aktivnosti vezane uz testiranje, uključujući i standarde, referentni model i model zrelosti.

Snimka stanja i ocjena zrelosti testnog okruženjaNa 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.

Page 8: Fyi 18 web

8 | FYI by CROZ / broj 18 / svibanj 2015.

tema broja | Provjera zrelosti testnog okruženja

kompetentnu ekipu koja ima potrebna znanja o internim procesima definiranja i analiziranja poslovnih zahtjeva, razvoja, puštanja u rad i, naravno, testiranja i prihvaćanja isporuka.

U prvom dijelu se u tridesetak minuta postavlja zajednička “referentna točka” i pogled na idealni svijet testiranja. Koliko god bio nedostižan, idealni svijet predstavlja zajednički cilj koji mora biti jasan svima, bez obzira na razinu uključenosti u sami proces.

Bitno je definirati što za odabranu organizaciju znači testiranje, prepoznati koji se rječnik koristi i kako je posloženo cjelokupno okruženje koje omogućava odvijanje povezanih aktivnosti. Zatim je važno osvijestiti potrebu za metodološkim pristupom testiranju, za strategijom i praksama, i na samom kraju jasno postaviti temelje za nastavak radionice.

Drugi dio je najduži i predstavlja pravu radionicu, u tradicionalnom

SWot analiza će ukazati na potrebne akcije s ciljem poboljšanja okruženja

smislu. Ovdje je ključno vrlo aktivno sudjelovanje stručnjaka iz organizacije koju analiziramo. U svojoj osnovi, ideja je jasno i nedvosmisleno prepoznati kako izgleda cjelokupno testno okruženje, što je prema mišljenju “radne skupine” dobro i što treba zadržati, a što nije baš najbolje i treba popraviti. Bitno je razumjeti da nema točnih i netočnih odgovora već da želimo iskreno i pošteno sami sebi razjasniti kakvo nam je okruženje.

Detaljno se ulazi u analizu primijenjene metodologije, u sami proces testiranja, organizaciju i okruženje. Na primjer, najčešće se pokaže da su ljudi vješti u testiranju svojih aplikacija, ali da nedostaje formalne naobrazbe, što kasnije negativno utječe na komunikaciju između timova, ili da se nedovoljno pažnje posvećuje automatizaciji, čime se izravno gubi vrijeme koje se moglo bolje iskoristiti na nekom drugom mjestu.

Treći dio je možda i najrazličitiji od uobičajenog pristupa, no jako je dobro prihvaćen gdje god smo ga isprobali. Radi se, naime, o kratkim i vrlo ciljanim, direktnim intervjuima sa svakim od polaznika radionice pojedinačno. Iznenađuje koliko se novih informacije može saznati u tih deset ili petnaest

na jednom mjestu se vidi trenutačno stanje okruženja, preporuke za quick win i buduće, poboljšano stanje

Stvarno je zanimljivo vidjeti koliko se korisnih informacija može dobiti u razgovoru jedan-na-jedan. Čim nema šefa ili kolega, ljudi se otvore i progovore o stvarnim problemima. Osnovna je pretpostavka da svi imaju želju unaprijediti svoje radno okruženje pa tako ovakvi intervjui daju ključne informacije što stvarno škripi i gdje treba uložiti napore koji će voditi k poboljšanju procesa.

minuta razgovora, a pogotovo je zanimljivo da tijekom intervjua uglavnom isplivaju detalji kojima ljudi nisu zadovoljni, ali im je bilo teško ili neugodno reći u grupi. To je zapravo odlično, jer tek tako možemo steći potpunu sliku o procesu.

Tokom četvrtog dijela radionice analiziramo prikupljene podatke i pripremamo izvještaj, kao i završnu prezentaciju koju predstavljamo dan poslije, na petom i posljednjem dijelu.

Sve prikupljene informacije se vrednuju i slažu u matricu ovisnih vrijednosti, kako bi se na jednom mjestu moglo vidjeti trenutačno stanje okoline.

Što dalje?Provjera zrelosti testnog okruženja će dati uvid u proces i organizaciju testiranja, ukazat će na kritične detalje koje treba popraviti kao i na one segmente koje treba zadržati i osnažiti. Rezultati snimke stanja, takozvani “nalazi”, doslovce se mogu iskoristiti kao popis zadataka koje treba ispuniti kako bi se unaprijedilo testiranje, kako u kratkom roku, recimo odmah za sljedeći projekt, tako i dugoročno, za sve buduće aktivnosti.

Trenutna procjena Prvi koraci Konač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

Page 9: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 9

Automatizacijom testiranja do kvalitete | tema broja

Osnovna definicija testiranja sof-tvera 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 program-skog rješenja, što korisniku donosi manje troškove održavanja i pouzdani proizvod, smanjuje mogućnost nastanka skupih programskih pogrešaka, osiguranjem kva-litete 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 praksiPraksa 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

Page 10: Fyi 18 web

10 | FYI by CROZ / broj 18 / svibanj 2015.

tema broja | Automatizacijom testiranja do kvalitete

Jedna ste od vodećih banaka na tržištu u Hrvatskoj i regiji, gdje leži tajna vašeg uspjeha i održ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 obav-lja 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 KirinecsIT Solutions (Manager for External IT Service Providers)

Page 11: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 11

Automatizacijom testiranja do kvalitete | tema broja

U Hrvatskim se prilikama i velike organizacije podržane brojnim informacijskim sustavima teško odlučuju na automatizaciju testiranja. Glavni su izgovori visoki inicijalni troškovi alata i obuke ljudi. No, to nije slučaj u Erste & Steiermärkische banci, koja već niz godina strateški ulaže i provodi automatizaciju regresijskih testova za velik broj svojih informacijskih sustava.

Počeci suradnje ponudili su nam nekoliko izazova. U postojeće Ersteove planove, procese, infrastrukturu i timove potrebno je bilo uklopiti veći broj CROZ-ovih testera različitih profila. Ersteovi stručnjaci organizirali su i održali s nama niz radionica i telekonferencija s ciljem prijenosa znanja te lakše i brže prilagodbe CROZ-ovih testera. Bilo je potrebno da i CROZ interno obuči više od 10 testera za korištenje 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. machineVjerujem 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ČN

O TES

TIRAN

JE

AUTOMATIZIRANO TESTIRANJE

VRIJEME

LJUdI

INFRASTRUKTURA

ALATI

ObUČAVANJE

darko Marijančić CROZ d.o.o.(koordinator CROZ-ova testnog tima)

Page 12: Fyi 18 web

12 | FYI by CROZ / broj 18 / svibanj 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:• brzinaradaaplikacije–izmjeriti

odzivna vremena aplikacija• skalabilnost–odreditimaksimalan

broj konkurentnih korisnika koje aplikacija može uspješno poslužiti

• stabilnost–provjeritikolikojeaplikacija stabilna pod velikim opterećenjem

Performansno testiranje

• propusnost–izmjeritimoželiaplikacija obraditi zahtijevanu količinu podataka i transakcija u planiranom vremenu

• definiratiminimalnuioptimalnukonfiguraciju 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.

Page 13: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 13

Performansno testiranje | tema broja

Performansne testove radimo da bismo osigurali zahtijevanu brzinu, skalabilnost, stabilnost i propusnost. Važno je da performansni test otkrije performansne probleme i uska grla u radu aplikacije na vrijeme, kako bi programeri i sistemski inženjeri što prije uklonili ili unaprijedili performanse aplikacije i infrastrukture koje aplikacija koristi. Provođenje performansnih testova se laiku na prvu može učiniti presloženim, no u konačnici to je jedini način za brzo identificiranje performansnih problema i uskih grla, te je znatno jeftinije od njihova uklanjanja ako takvo testiranje izostane.

Proces performansnog testiranjaPlaniranje 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 testerKako 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.

Page 14: Fyi 18 web

14 | FYI by CROZ / broj 18 / svibanj 2015.

tema broja | Performansno testiranje

Za vašu smo instituciju samo ove godine radili nekoliko performansnih testova. bilo je tu aplikacija koje razvija CROZ, ali i aplikacija drugih dobavljača. Možete li nam reći koji su vam motivi pri odlučivanju što ćete i kada performansno testirati?

Sve aplikacije se performansno testiraju prije produkcije. Kad neka aplikacija počinje svoj produkcijski život, onda želite biti sigurni da će izdržati nalet svih korisnika i sve njihove zahtjeve, upite i transakcije. U slučaju da aplikacija ima prekide ili

Performansno testiranje u Raiffeisen banciAlan-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čakPerformansni testovi su neophodni prilikom objavljivanja novih softverskih produkata, osobito servisa koji su javno dostupni. Troškovi performansnog testi-ranja 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

RationalPerformance

Tester

PerformanceTester Agents System Under Test

Page 15: Fyi 18 web

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čitiOS-oviipripadajućeverzije•hardverskerazlikeuređaja•brzeiučestalenadogradnjeaplikacija.

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 testiranjaU cilju lakšeg svladavanja svih izazova potrebno je definirati kvalitetnu strategiju testiranja, koja uključuje:• odabirciljanihuređaja(iOS/Android,

tablet/smartphone, različite veličine ekrana, CPU, memorije...)

• automatizacijutestiranjaradineminovne 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

• odabirrazličitihtipovatestiranjazafunkcijsko i nefunkcijsko testiranje, kao

što su npr.:• testiranje korisničkog iskustva (usability testing), što uključuje vidljivost na odabranom jeziku, navigaciju između ekrana, verifikaciju implementiranih

funkcionalnosti online i offline, feedback kod interakcije s aplikacijom – npr. ako je korisnik preuzeo aplikaciju, na mobitelu bi se trebala javiti poruka ili bi se aplikacija trebala početi instalirati na uređaj

• funkcijsko testiranje (functional testing) predstavlja testiranje ispravnosti pojedinih funkcionalnosti aplikacije i odgovara li implementacija korisničkim zahtjevima

• testiranje kompatibilnosti (compatibility testing) podrazumijeva validaciju aplikacije na različitim uređajima s različitim operacijskim sustavima, veličinama ekrana i različitim rezolucijama. Također provjerava kako aplikacija radi s ostalim aplikacijama

• operativno testiranje (operational testing) podrazumijeva testiranje aplikacije u slučaju da se baterija isprazni, mogućnosti gubitka podataka u slučaju upgradea, dostupnost aplikacije u slučaju da korisniku počne zvoniti alarm, primi poziv, poruku

• mrežno testiranje (network testing) – testiranje ponašanja aplikacije u različitim mrežnim uvjetima koje generiraju specijalizirani alati.

Pišu: Martina bajza i ivana Skorupan

Testiranje mobilnih aplikacijaU ovom tekstu govorimo o osnovnim smjernicama za testiranje kvalitetnih mobilnih aplikacija kako bismo pojačali konkurentnost na jednom od najbrže rastućih tržišta današnjice.

opis strategije testiranja

STRATEGIJATESTIRANJA

Provođenje različitih tipova testiranja

Automatizacija testiranja

Definiranje ciljane

skupine uređaja

Page 16: Fyi 18 web

16 | FYI by CROZ / broj 18 / svibanj 2015.

tema broja | Testiranje mobilnih aplikacija

UređajiNakon definiranja strategije testiranja mobilne aplikacije potrebno je odrediti način testiranja, odnosno uređaje na kojima će se provoditi testiranje.

Fizički uređajiTestiranje 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.

emulatoriEmulator 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 testiranjeCloud 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-uU 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

Page 17: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 17

Š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 sa-stanci na kojima će se “otkriti” koje ovlasti zapravo neka osoba ima. Osim toga, vrlo je teško otkriti opasne kombinacije ovlasti koje bi zaposlenik s početka priče mogao imati (npr. izradu i odobrenje ponude u jednoj osobi), kao i kada je tko za što bio ovlašten i trebaju li mu još te ovlasti.

ibM Security identity GovernanceNa 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 apli-

kacijama i premoste jaz između potreba za usklađenošću, poslovnih aktivnosti i IT aktivnosti. Rezultat toga je smanjenje rizi-ka od prijevara, konflikata uloga i ljudskih pogrešaka u provođenju poslovnih procesa.

ISIG na upravljanje identitetima i pristu-pom 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 po-slovne 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 perspek-tive 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

Page 18: Fyi 18 web

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 jednostav-no 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 funkci-onalnosti 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 auto-matski 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 alatimaISIG 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čakISIG predstavlja korisnu nadogradnju na postojeće IBM-ove (i ne samo IBM-ove) produkte za upravljanje identitetima i pristupom koja omogućuje da se uprav-ljanje 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 kvalitet-no 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

Page 19: Fyi 18 web

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 poslov-nih 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 projektaSlika 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 projektaSlika 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 projektaProjekt 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, FICONTape Library

enterprisestorage

enterprisestorage

enterprisestorage

sinkronareplikacija

asinkronareplikacija

Page 20: Fyi 18 web

20 | FYI by CROZ / broj 18 / svibanj 2015.

rubrika | nadnaslovprojektne 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:• pripremljenisukontrolniz/OS

operativni sustavi• instaliranisuikonfiguriraniTivoli

NetView i Tivoli System Automation produkti

• instaliranjeikonfiguriranGDPSsoftver.

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

sinkronareplikacija

Enterprisedisk

Enterprisedisk

Page 21: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 21

nadnaslov | rubrikaPeter 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 arhitektureCroZ-ovo dugogodišnje iskustvo u implementaciji složenih informacijskih sustava osiguralo nam je i pojedine bitne uloge u velikim projektima na zapadnom tržištu. od studenoga 2014. godine imam priliku raditi kao dio tima u velikoj financijskoj kući u velikoj britaniji koji je zadužen za transformaciju cjelokupnog procesa dizajna informacijskih sustava i uvođenje novih alata. na projektu radim s Peterom eelesom, svjetskim autoritetom u području softverske arhitekture, jednim od dvojice autora knjige “the Process of Software architecting”. iskoristio sam tu priliku kako bih napravio ovaj intervju i podijelio s vama Peterova razmišljanja o softverskoj arhitekturi.

Iz toga slijedi da je najkraći odgovor na postavljeno pitanje: potrebno je razraditi model i kreirati različite perspektive informacijskog sustava do razine koja će osigurati konsenzus među svim osobama odgovornim za implementaciju sustava.

Možeš li nam reći koja je tvoja trenutačna uloga u ibM-u i nešto o svojoj karijeri?

Trenutačno sam Executive IT Architect u IBM Cloud Worldwide Tiger Teamu. Pomažem klijentima da shvate relevantnost clouda u njihovu poslovanju te načine na koje im cloud arhitektura može pomoći da budu uspješniji. Prije toga bio sam u sličnoj ulozi u Rational brendu IBM-a, gdje sam pomagao organizacijama da nađu bolje načine razvoja i isporuke softvera. A još prije toga, vodio sam nekoliko inicijativa s klijentima, pomažući im da transformiraju svoj softverski razvoj. Uvijek sam bio i uvijek ću biti arhitekt!

Kako to da je slika nebodera u izgradnji izabrana za naslovnicu knjige “the Process of Software architecting”, koju si napisao u suradnji s Peterom Crippsom?

Uz jasnu analogiju softverske i građevinske arhitekture, simbolika je u tome da je arhitekt odgovoran za važne odluke u dizajnu. Arhitekt se obično ne uključuje u razinu predubokih detalja (iako će i to učiniti ako je potrebno), ali

osigurava da su svi osnovni elementi arhitekture na pravom mjestu.

Također bih trebao reći da je analogija s građevinom prejednostavna, zato što ta slika prikazuje samo jednu perspektivu, onu fizičku, i ne prikazuje osnovne ele-mente 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

Page 22: Fyi 18 web

22 | FYI by CROZ / broj 18 / svibanj 2015.

intervju | Peter Eeles

IT-ovce buni razlika između enterprise, sistemske i softverske arhitekture. Čak i unutar jednog sustava postoje razni dijelovi sistemske arhitekture kojima se moramo pozabaviti, kao što su aplikacijska arhitektura, arhitektura podataka, infrastrukturna i sigurnosna arhitektura i još neke druge. Još jedan važan koncept jest da svaki sustav ima arhitekturu, čak iako ona nije formalno dokumentirana ili ako je sustav iznimno jednostavan.

Možemo li govoriti o industrijskim standardima za proces stvaranja arhitektura softvera ili samo o najboljim praksama? Postoji li neki univerzalni proces koji se može primijeniti na svaku organizaciju ili se proces mora prilagoditi kako bi organizacija dobila iz njega što je više moguće?

Postoje standardi za neke tipove arhitektura. TOGAF (The Open Group Architecture Framework) se, na primjer, može primijeniti na nivou enterprise arhitekture. Postoje i “standardi” koji ulaze u određene aspekte procesa, uključujući ISO 42010 standard za dokumentiranje arhitekture i pristupe kao što su Attribute-Driven Design (ADD) i Architecture Tradeoff Analysis Method (ATAM) koji dolaze od SEI-a (Software Engineering Institute). Jedan je od ciljeva knjige bio staviti sve te pristupe u kontekst end-to-end procesa koji je fokusiran na disciplinu arhitekture.

Ipak mislim da ideja “standardnog” procesa koji je primjenjiv u svim

situacijama nije realistična. Sve bi procese trebalo prilagoditi organizaciji, projektu, timu i rješenju na kojem se radi. To je jedan od razloga zbog kojeg je bitno fokusirati se na paletu praksi koju možemo birati i primijeniti prema situaciji. S druge strane, postoji osnovni framework koji je potrebno primijeniti – onaj koji osigurava da su odluke dokumentirane, da je vođena briga o ponovnoj upotrebi bilo kakvih postojećih asseta, da su napravljeni različiti pogledi na arhitekturu i tako dalje. To je ono što smo probali opisati u knjizi.

Kako možemo mjeriti učinkovitost procesa i kako ga možemo regulirati?Najvažniji test učinkovitosti jest poboljšana produktivnost (brže isporuke), smanjeni trošak i povećana kvaliteta isporučenog rješenja (mjereno kroz broj defekata). Često je vrlo teško atribuirati neko poboljšanje uvođenju neke prakse ili promjeni određenog aspekta procesa. Na primjer, mnogi projekti na kojima sam radio a gdje su organizacije željele poboljšati način na koji razvijaju i isporučuju softver, trebali su kombinaciju poboljšanja procesa, uvođenja integriranog skupa alata, ponešto reorganizacije, edukacije ljudi i sličnih akcija. Nemoguće je izdvojiti relativni doprinos svake od tih akcija.

Velik sam zagovornik ciklusa “mijenjaj-mjeri-mijenjaj-mjeri”, gdje se rade i procjenjuju inkrementalne promjene prije uvođenja novih promjena. Na neki je način to uzimanje principa iterativnog i

inkrementalnog razvoja softvera i njihova primjena na inicijative za promjenu. To je u biti područje na koje se fokusiram više od desetljeća – vjerujem da primjena arhitekturnih principa na delivery okruženje koje trebaju timovi za razvoj softvera može dati puno vrijednosti. Konkretan je primjer toga definicija kvalitetnog i integriranog skupa alata koji ne dolaze nužno od istog proizvođača.

Kako novi i napredni kolaborativni alati, poput alata iz ibM-ove Collaborative lifecycle Management (ClM) ponude, utječu na proces stvaranja arhitekture softvera?

IBM-ovo CLM rješenje u velikoj je mjeri fokusirano na integraciju rada svih koji rade u timu i podršku njihovoj međusobnoj kolaboraciji. Konkretno, dani kada su poslovni analitičari definirali zahtjeve prije nego što su ih bacili “preko zida” dizajnerima i testerima, završili su. To se može vidjeti u širokom prihvaćanju agilnih i DevOps praksi koje su u velikoj mjeri fokusirane na rad timova, vidljivost i end-to-end razmišljanje.

Iz perspektive arhitekture, velike organizacije često imaju silose unutar svoje arhitekturne prakse. Na primjer, mogu postojati timovi za aplikacijsku arhitekturu, infrastrukturnu arhitekturu i arhitekturu podataka. To je bio slučaj u velikoj banci za koju radim ovdje. Čak je i ovdje iznimno bitno stvoriti okruženje u kojem arhitekti iz različitih disciplina mogu surađivati. U ovom je slučaju rješenje bilo stvaranje jedinstvenog okruženja za modeliranje koje služi svim arhitekturnim disciplinama. Organizacija je od toga imala jako puno koristi.

Glavni zadaci arhitekta

naslovnica eelesove knjige “the Process of Software architecting”

Page 23: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 23

g*rich | tehnologije i trendovi

Tko god se primio iole ozbiljnijeg programiranja u Javi, bar je jed-nom 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 problemeKad je cjelina više od pukog zbroja dijelova…

Page 24: Fyi 18 web

24 | FYI by CROZ / broj 18 / svibanj 2015.

okruženjima, ali “to jednostavno nije to”, “samo čekaš da se sve raspadne”, “proširivanje funkcionalnosti je noćna mora” itd. Za ozbiljan posao trebaš i ozbiljnu platformu. Svi su, dakle, sretni. Osim programera, jer Java kao platforma je odlična, Java kao programski jezik baš i nije.

Java kao platforma je odlična, Java kao programski jezik baš i nije.

Ustvari, nije baš da Java kao programski jezik ne valja, već JVM nudi mogućnost upotrebe različitih sintaksi, odnosno na neki način različitih programskih jezika, a da se sve izvršava na jednoj te istoj platformi, u istom aplikacijskom serveru. Od već postojećih jezika i njihovih “jVarijanti” (jRuby, Jython – da, Python u Javi) preko posve novih (Scala, Clojure ili Groovy), nove sintakse donose moderne programerske trikove, dinamičko prevođenje i sve što Javi kao programskom jeziku nedostaje. Brže, lakše, elegantnije, a sve u poznatom, stabilnom i nebrojeno puta dokazanom okruženju.

Spomenuti Groovy je upravo takav jezik. Ako uspijemo zanemariti ne baš simpatično ime, taj jezik rješava sve što nas muči s Javom kao sintaksom: brzo se uči, izvršava se dinamički – ili statički, ako tako želimo, koncizan je i elegantan, a povrh svega, integrira se s Javom bez ikakvih problema. Čovjek se pita zašto sve to već inicijalno nije u Javi, ali eto, bar imamo Groovy. Manje linija koda, jednostavniji izrazi, čitljivije petlje

tehnologije i trendovi | g*rich

i već smo u prednosti, što zbog bržeg kodiranja, što zbog činjenice da manje linija koda znači i manje bugova. Groovy se automatski prevodi u Javu, tako da razlike u kompatibilnosti nema. Štoviše, Groovy je od svih alternativnih jezika na JVM-u najbolje integriran s Javom: bez ikakvih dodatnih koraka Java zove Groovy, Groovy zove Javu, Java i Groovy se mogu miješati u hijerarhiji nasljeđivanja itd. Sve u svemu, pravi izbor za početak.

Istraživanje Groovyja kao alternativnog programskog jezika za JVM otvorilo je vrata onome što danas zovemo g*rich framework.

g*rich = jvM + Groovy + Grails + ext jS + sve izmeđug*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?

Page 25: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 25

g*rich | tehnologije i trendovi

Zapisi se uređuju na istom ekranu. Forme mogu sadržavati vrlo kompleksne elemente koji, naravno, imaju sve funkcionalnosti kao i tablice za pregled. Programiranje ovakvih ekrana nije ništa kompleksnije od standardnih pregleda, a korisnički doživljaj je značajno poboljšan.

Čemu trošiti riječi kad slike sve pokazuju?

Koliko kompleksne klasične poslovne aplikacije mogu postati pokazuje i ova slika. bez dobrog okruženja razvoj ovakvog prikaza je prava noćna mora. U g*richu to nije nikakav poseban problem. nova tema je razvijena prema specifičnim zahtjevima korisnika.

Praćenje životnog ciklusa zapisa u bazi je jedna od onih funkcionalnosti koje ili završe na “nice to have” listi i nikad se ne implementiraju ili dovedu projekt na rub propasti. g*rich jednostavno ne može dopustiti da se tako bitna stavka zanemari i donosi praćenje povijesti zapisa spremno za korištenje od samog početka.

osnovna korisnička sučelja za “običnog” korisnika i administratora (koja su toliko dobra da se gotovo pa mogu odmah početi koristiti, samo se upišu stvarni podaci u bazu), skripte za pokretanje testnog servera... Predlošci se, naravno, mogu dodavati ili mijenjati, čak se i bilo koja radeća aplikacija može pretvoriti u predložak.

Demo aplikacija koju g*rich automatski generira uključuje niz upotrebljivih primjera, od kojih je najzanimljiviji famozni “šifarnik”, u ovoj ili onoj formi najčešći oblik poslovnih aplikacija, i to ne bilo kakav šifarnik! Sve je tu: pametno pretraživanje podataka, “master-detail view”, uređivanje podataka...

Šifarnik bez ili šifrarnik s prvim r? Ovisi koga pitate, tj. o njegovoj ili njenoj godini rođenja – prije ili poslije pojave prvog PC-a. A

Ispod generirane aplikacije se nalazi jezgra g*richa, koja ustvari predstavlja srce cijelog aplikativnog okvira u tehničkom smislu. Tu su sažeti sati i sati programiranja i peglanja različitih dijelova frameworka. Bez ove jezgre, g*rich bi bio samo nakupina odličnih, ali ipak nepovezanih komponenti. Spomenimo neke:

Validatori podataka na formama se najzad implementiraju samo na jednom mjestu (na serverskoj strani) i automatski se propagiraju do klijenta. Ponašaju se onako kako bi i trebali: pokazuju smislene poruke za pogrešno upisanu vrijednost pojedinačnog polja, povezanih polja ili cijele forme.

Podrška za višejezičnost, teme ili kontrolu pristupa podacima se, naravno, podrazumijeva.

Za neke mogućnosti koje g*rich donosi ni ne znamo da su potrebne sve dok nas surova stvarnost ne opali po prstima i ne natjera na trošenje sati i dana na krpanje aplikacije. Spomenimo samo podršku za OWASP

Page 26: Fyi 18 web

26 | FYI by CROZ / broj 18 / svibanj 2015.

Top 10 Security ili heartbeat call koji ne produžuje session (!).

jesu li šusterova djeca baš uvijek bosa?I jedna zanimljivost za kraj: prezentacije g*richa potencijalnim partnerima su gotovo uvijek završavale reakcijama poput: “A gdje ste bili do sada?!” ili “Kad možemo početi?”. Međutim, na jednom projektu sam čuo primjedbu: “Dobro, i što je tu toliko posebno? Pa to je samo brdo nekakvih biblioteka i tu i tamo poneki plug-in.” Takva rečenica ne može biti više u krivu nego što jest. Istina, g*rich neće od poluzainteresiranih programera koji su do jučer “čukljali” COBOL stvoriti gurue

razvoja modernih web aplikacija, ali će zato svakom iole upućenom javašu omogućiti rad kakvog je htio od prvog dana, a to znači fokus na poslovni aspekt projekta, bez petljanja po utrobi frameworka, i sve

to bez gubitka fleksibilnosti i bogatstva različitih opcija koje razvoj u Javi donosi. U slučaju g*richa ne vrijedi ona izreka o šusteru i njegovoj bosoj djeci. Naime, i sami ga koristimo na desetak vrlo 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.

Page 27: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 27

CSI | predstavljamo partnere

Pet godina na otoku AMalo-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 petasezona u UK-uU 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 KingdomNaravno, 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

Page 28: Fyi 18 web

28 | FYI by CROZ / broj 18 / svibanj 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.

akvizicijaOrbital 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 StreatherCSI 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

Page 29: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 29

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 platformaKao 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, goKao tvrtka koja ima mnogo intranet utakmica “u nogama” oformili smo tim i za ovaj susret i krenuli. Liferayove

Liferay MarketplaceLiferay 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.

Page 30: Fyi 18 web

30 | FYI by CROZ / broj 18 / svibanj 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 LiferayCROZ 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ž PevcSKB 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

Page 31: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 31

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–softverskaaplikacijamože

izložiti funkcionalnosti kao API, ali ona sama nije API

• korisničkosučelje(UI)–klijentskaaplikacija 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–kolikojeonoatraktivnoza

potrošača (želimo da odabere baš naš proizvod)

• korisničkimuputama–akopotrošač

odabere naš proizvod, želimo da u što kraćem vremenu ovlada korištenjem proizvoda

• konzistentnostiproizvoda–neželimoda naš proizvod bude manjkav što neophodnim funkcionalnostima, što lošijom kvalitetom nekih sastavnih dijelova

• korisničkapodrška–nakonštojeproizvod 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 ManagementJedan od proizvoda koji olakšava implementaciju API-a jest IBM-ov API Management, skraćeno APIM.

IBM API Managementjedan 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

Page 32: Fyi 18 web

32 | FYI by CROZ / broj 18 / svibanj 2015.

tehnologije i trendovi | IBM API Management

Komponente APIM-a jesu: Developer Portal, API Manager i Cloud Console.

developer PortalJedan 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 ManagerDa 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 servisi-ma, 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 te-stirati. 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 ConsoleKao š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 ManagementPostoji 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 GovernancePrvenstveno REST/JSON servisi Prvenstveno SOAP/XML servisiNiska razina stabilnosti sučelja Visoka razina stabilnosti sučeljaFokus na uporabu API-a Fokus na funkcionalnosti vlasnika servisaAPI-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 servisaSitno granulirani Veće granulacijeNajčešće eksterna uporaba (internet) Najčešće interna ili B2BPokretač 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

Page 33: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 33

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 proizvo-da 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 sebaš 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ć

Page 34: Fyi 18 web

34 | FYI by CROZ / broj 18 / svibanj 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 klinciNa 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 zelenijaBojim 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 koordi-naciju 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.

Page 35: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 35

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-aU 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 licenciranjaPogledajmo 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.

Page 36: Fyi 18 web

36 | FYI by CROZ / broj 18 / svibanj 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

Page 37: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 37

nadnaslov | rubrikaUpravljanje 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-utvrtke 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 pot-puno 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 danimokolnostima; osobne procjene istavovi; poduzimanje akcije

Znanje (kako?)Razumijevanje značenja informacijePriprema (temelj) za akciju

Informacija (tko, što, kada, gdje?)Strukturirani, povezani podaci

PodatakNeobrađeni materijali; činjenice odogađ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

Page 38: Fyi 18 web

38 | FYI by CROZ / broj 18 / svibanj 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-uPostoje 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. ljudi2. procesi3. 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 znanjem1. 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

Page 39: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 39

Kreativnost i inovativnostKreativnost 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 ConnectionsKao 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 su-stava 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, kompo-nente 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 trokutStaro 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čakSustav 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 organizaci-ji. To će se postići na taj način da se ključne kategorije upravljanja znanjem: ljudi, proce-si, 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 zna-njem 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 plat-forme 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.

Page 40: Fyi 18 web

40 | FYI by CROZ / broj 18 / svibanj 2015.

ZNAČENJE BOJA PRIMIJENITI PILOTIRATI PROCIJENITI PROMIJENITI

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 jeziciKonač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 radarPola 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 alatiJedan 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 prakseLean 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.

Page 41: Fyi 18 web

Apache Camel

ZNAČENJE BOJA PRIMIJENITI PILOTIRATI PROCIJENITI PROMIJENITI

Play

Akka Scala

FreeMarker

JSF

JPAClearQuestCoffeeScript

Spray

JSP

BPEL

GWT

Deployit

OrientDB

TorqueBox

Azul Zin

Jawr

OpenShift

Ansible

Application as a service (Meteor, deployd) MySQL

Ant

CVS

WS-*

Ivy

TDDKanban

Infrastructure automationContinuous 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

GroovyJavaScript

gradle Docker

Camunda

Twitter Bootstrap

Java

extjs

HTML5

VaadinSpring 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 AlfrescoSelenium

Maven

WebSphere Liberty Profile

StructrPuppet

ChefNodeJs

CloudFoundry

IBM BlueMix Packer Geb

Wro4jRedis

UrbanCode uDeploy

Event sourcing

Impact mappingDocumentation inproprietary/ binary formats

Apache Camel

Spock

Spring Boot

IntelliJ IDEA

ElasticSearch/Kibana/ Logstash

MongoDB

Activiti

NoEstimates

Continuous deliveryContinuousdeployment

Security/penetrationtests 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 AppServer < 8.5

FYI by CROZ / broj 18 /svibanj 2015. | 41

Spring Integration

ATDD

Hawt.ioOrientdb

OpenStack Vaadin

Hazelcast

Page 42: Fyi 18 web

42 | FYI by CROZ / broj 18 / svibanj 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 programiranjaStrojari 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

Page 43: Fyi 18 web

FYI by CROZ / broj 18 /svibanj 2015. | 43

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

VatrometVrlo 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.

LabirintBube 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.

FraktaliKako 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.

Page 44: Fyi 18 web