opis FYI test

1. tehnologijeitrendovi:g*rich•Dajmo
djecidaprogramirajuprojektnepriče:
Implementacijadisasterrecoveryrješenja
uFini•IntranetuSKBbanciintervju:
PeterEeles:Svrhasoftverskearhitekture
predstavljamopartnere:CSILtd.

2. IZDVAJAMO IZ AKTUALNIH
TEČCAJEVA:
TEČAJEVI PO MJERI
LEARN@CROZ
kontaktirajte nas na learn@croz.net
IBM BUSINESS PROCESS MANAGER (BPM)
UVOD U AGILNI PRISTUP RAZVOJU SOFTVERA
RAzvoj mobilnih aplikacija (ios i android)
spring framework
RAzvoj rješenja nad alfresco ECm sustavima
Mentoring i
coaching
essentials of IBM rational
performance tester
certified SCRUM PRODUCT
OWNER (agile42)
management 3.0 (jurgen appelo)

3. FYI by CROZ / broj 18 /svibanj 2015. | 3
nadnaslov | rubrikafyi by croz | uvodnik
FYIbyCROZ|Časopiszainformatiku|Urednik:GoranKelečić|Izdavač:CROZd.o.o.,Lastovska23,10000Zagreb,RepublikaHrvatska|Tel.:0038516184831|Faks:0038516184833
E-mail: fyi@croz.net | Internet: www.croz.net | Grafički dizajn časopisa i naslovnice: SBD Shift Brand Design, www.sbd.ba | Tisak: Tiskara Grafing d.o.o., Zagreb
Piše: Krešimir Mudrovčić
Urednik: Goran Kelečić
T
ema ovog broja je testiranje,
odnosno upravljanje kvalite-
tom softvera. Testiranje, kao i
sigurnost u prošlom broju, su
teme kojih nikada nije previše. Sigurnost
je nekako atraktivnija tema, često čitamo
u medijima o najnovijim sigurnosnim
propustima i gledamo holivudske filmove o
hakerima. A testiranje je ostalo ružno pače
softverske industrije. Pa hajʼmo to ispraviti!
U ovom broju čitajte o automatiziranju
testiranja, performansnom testiranju,
testiranju mobilnih aplikacija… Posebno
smo ponosni što se možemo pohvaliti da
nas je Erste&Steiermärkische banka u jakoj
međunarodnoj konkurenciji odabrala za
strateškog outsourcing partnera u području
testiranja. Priča se savršeno uklapa u temu
broja.
Kada ste sve to proučili, spremni ste
za ispit zrelosti! Oslanjajući se na TMMi
Foundation, naši stručnjaci su osmislili
učinkovit i jednostavan model za provjeru
zrelosti organizacije u području testiranja.
Dakle, ako želite provjeriti kako stojite
s testiranjem i pripremiti strategiju
unapređenja testiranja, ovo je idealan prvi
korak. Topla preporuka od strane vašeg
uvodničara!
Kažu da svaki programer (a pogotovo
javaš) želi razvijati svoj vlastiti framework.
Ipak, to nije jednostavan zadatak, a
zahtijeva i jako puno znanja i iskustva. Naš
tim predvođen Damirom Muratom razvio
je g*rich, framework koji predstavljamo
u ovom broju. Rezultati su vrlo dojmljivi;
ubrzali smo i pojednostavnili razvoj,
korisničko sučelje je ergonomično i
funkcionalno (i seksi), ugrađena je i
integracija s ECM i BPM sustavima.
Standardizacija i sigurnost manje su
vidljivi, ali podjednako važni dobitci. I što je
najljepše, stvar dokazano radi u praksi. Iako
je početna ideja bio interni razvoj, g*rich je
zamišljen tako da ga mogu koristiti i naši
korisnici! Još jedna topla preporuka!
Ovaj uvodnik pišem u slatkom pred-
QED iščekivanju. Naša mala konferencija
(Dalmatinci bi rekli “smišna”) se ove godine
preselila u Rovinj. Sve ono zbog čega
volimo QED, a to je prije svega pozitivna
atmosfera i kvalitetan sadržaj, ostaje
nepromijenjeno. Puno je i novosti, dolaze
svjetske face; Andreu Tomasinija vjerojatno
ne treba više predstavljati, Grady Booch je
računalni znanstvenik i filozof, a pomalo
i umjetnik. Pričat ćemo o kreativnosti i
inovativnosti, bit će baš super!
Naša ekipa bila je u Americi i vratila
se puna dojmova. S jedne strane velika
preobrazba IBM-a, veterana informatičke
industrije, u koju se moglo uvjeriti dvadeset
tisuća sudionika InterConnect konferencije.
S druge je strane nepodnošljiva lakoća
Silicijske doline, Google, Facebook i novi
poslovni modeli. Ostaje nam promatrati i
doživjeti koji će smjer prevladati. Ja bih se
kladio na dijalektiku.
Za kraj ovog uvodnika jedna jako bitna
tema: treba li djecu učiti programiranju?
Mi mislimo da treba, ali program po kojem
se radi u našim školama nepopravljivo
je zastario, a praksa još i više. Iskustva s
radionica za djecu koje organizira udruga
Programerko pokazuje da se programiranje
može učiti drugačije. Naprednije i
zabavnije. Pozivamo i vas da nam se
pridružite u mijenjanju sadašnjeg stanja.

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

5. FYI by CROZ / broj 18 /svibanj 2015. | 5
nadnaslov | rubrikafyi by croz | vijestifyi by croz | vijesti
Održanodogađanje Prediktivnaanalitikai
FraudManagement
Događanje posvećeno primjeni tehnika i alata za naprednu analizu podataka s ciljem
poboljšanja poslovanja s jedne, ali i sprečavanja zloporaba i neželjenih ponašanja s
druge strane, održano je 19. ožujka u edukacijskom centru Learn@CROZ.
U nizu predavanja stručnjaci iz CROZ-a i IBM-a kroz mnoge su primjere i savjete,
s naglaskom na bankarsku i osiguravateljsku industriju te marketing i državne
ustanove, pokazali kako uloga prediktivne analize i ranog otkrivanja prevara može
biti ključna za uspjeh poslovnog pothvata.
CROZ zlatnisponzor
konferencijeAgile
Adria
Udruga Agile Hrvatska, čiji su članovi
i mnogi naši CROZ-ovci, organizirala
je i ove godine od 13. do 15. travnja u
Termama Tuhelj konferenciju Agile
Adria. Konferencija je okupila više od
170 ljudi iz 16 zemalja te tim brojem, ali
i predavačima svjetskog ugleda poput
Mary Poppendieck, Toma Gilba i Stephena
Parryja, potvrdila status najveće i najbolje
agilne konferencije u ovom dijelu Europe.
CROZ je sudjelovao kao zlatni sponzor
konferencije.
Održanfinancijski
RoadshowEvent
U četvrtak 16. listopada 2014. u
edukacijskom centru Learn@CROZ
održan je financijski Roadshow Event u
organizaciji tvrtki CROZ i Liferay.
Demonstracijom uživo i
predstavljanjem najzanimljivijih značajki
približili smo sudionicima događanja način
korištenja Liferay portala u financijskim
ustanovama.
CROZ sponzor
drugog izdanja
konferencije
JavanturaoJavii
srodnim jezicima
CROZ je bio ponosni srebrni sponzor
konferencije Javantura v2 koja je
održana 15. studenoga 2014. u Zagrebu.
Oko 200 razvojnih inženjera, voditelja
projekata i studenata tako su dobili
priliku, tijekom čak 16 predavanja,
upoznati se s najnovijim trendovima u
tom programskom jeziku.
Jedno od predavanja, Dockyourapp,
održali su CROZ-ovi stručnjaci Matija
Folnović i TomislavKlišanić.U sklopu
predavanja demonstrirali su kako se u
tvrtki CROZ koristi platforma Docker
za izradu posebno prilagođenih 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šnoodržanpeti
SmartDay
Peto izdanje serije događanja Smart Day
održano je 20. siječnja u dvorani Müller
kina Europe, u organizaciji časopisa
“Mreža” i tvrtke CROZ. Naziv petog
izdanja ovog događanja bio je Sveti
gral inovativnosti, a u toj se tematici
Vedrana Miholić, direktorica prodaje
CROZ-a, savršeno pronašla. U svom
uvodnom predavanju obradila je temu
kreativnosti i inovativnosti kao ključnim
faktorima za opstanak i napredak svake
organizacije. Ujedno je prezentirala i
glavne karakteristike CROZ-ove platforme
Like My Idea, rješenja koje olakšava
organizacijama prikupljanje, filtriranje i
nagrađivanje ideja zaposlenika.
LMIpredstavljen
slovenskim start-
up tvrtkama na
događanjuImplico
CROZ je 26. siječnja predstavio svoje
rješenje Like My Idea (LMI) u sklopu prvog
dana događanja Implico u Ljubljani. Riječ
je o seriji događanja koju organizira odjel
slovenske Udruge za ljudske resurse
MEKS (Mladi stručnjaci kadrovske struke).
Cilj je Implica da podigne svijest o važnosti
struke ljudskih resursa kao strateški
važne funkcije svake tvrtke, bez obzira na
njezinu veličinu ili tip.
Mirela Držaić iz CROZ-a upoznala
je predstavnike malih i start-up
tvrtki iz Slovenije s LMI-om kao
rješenjem koje omogućava tvrtkama
da prepoznaju istaknute talente
među svojim zaposlenicima i kao
mehanizam motivacije zaposlenika u
smislu aktiviranja pri kontinuiranom
poboljšavanju internih procesa.

6. 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?

7. FYI by CROZ / broj 18 /svibanj 2015. | 7
Provjera zrelosti testnog okruženja | tema broja
sve razine, od unit testova na izvornom
kodu do testiranja ponašanja cjelokupnog
sustava u slučaju ispada dijela
infrastrukture. Koji ćemo pristup imati
jako ovisi o samom sustavu koji testiramo.
Ako se radi o internoj aplikaciji za prijavu
godišnjeg odmora, onda je možda
dovoljno isprobati radi li sve na testnoj
okolini i spremni smo za produkciju.
Uostalom, ako nešto pođe krivo i zapis
o mom godišnjem se izgubi, pa dobro,
nema veze, prijavit ću ga ponovo. Ako
se s druge strane radi o famoznom
internet bankarstvu, onda vjerojatno
želimo testirati i izvorni kod (razne
izračune, provođenje transakcija i tako
dalje) i sigurnost (recimo na OWASP Top
10 – za više detalja vidi okvir u članku o
g*richu), ali i ponašanje sustava u slučaju
nedostupnosti nekog ključnog dijela
infrastrukture. Tu je, naravno, i regresijsko
testiranje – nakon puštanja u rad novih
funkcionalnosti želimo znati rade li one
stare kao i prije. Nije svako testiranje
prikladno, ili bolje rečeno isplativo u
svakoj situaciji, no prepoznavanje pravog
trenutka je vještina koja se uči i brusi kroz
vrijeme. Kako testiranje često predstavlja
pa čak i 30–40% ukupnog troška projekta,
dobrom organizacijom i planiranjem
aktivnosti ne samo da podižemo kvalitetu
isporučenog softvera i sustava u cjelini
nego i smanjujemo cijenu projekta.
Koliko je neka organizacija zrela u
pogledu testiranja se može relativno brzo
i jednostavno izmjeriti. Naime, softverska
zajednica se kontinuirano trudi podići
razinu kvalitete cjelokupnog proizvodnog
procesa, tako da su de facto standardi za
razvoj postavljeni u vodiču pod imenom
CMMI, Capability Maturity Model
Integration. Pandan CMMI-u u domeni
testiranja definira TMMi Foundation,
strukovna organizacija koja objedinjuje
aktivnosti vezane uz testiranje, uključujući
i standarde, referentni model i model
zrelosti.
Snimka stanja i ocjena zrelosti
testnog okruženja
Na temelju TMMi-a, ali i vlastitih
iskustava smo razvili i svoju uslugu
snimke stanja i ocjene zrelosti testnog
okruženja (Testing Environment
Maturity Assessment), kao jednodnevne
radionice na kojoj se vrlo fokusirano i
precizno određuje kvaliteta testiranja
u proizvodnom procesu, i istovremeno
prepoznaje prostor za napredak i
usavršavanje.
Radionica se sastoji od pet dijelova, od
kojih prva tri uključuju odabrane djelatnike
organizacije u kojoj radimo analizu.
Naime, kako bi se čim efikasnije iskoristilo
vrijeme i čim prije došlo do rezultata,
nužno je na jedno mjesto okupiti
Zrelost procesa testiranja se može jednostavno
pozicionirati na prikazanoj piramidi Testiranje se, kao uostalom i svaki drugi proces, sastoji od metodologije, od ljudi koji
provode tu metodologiju i infrastrukture na kojoj se sve odvija
Rezultat drugog dijela radionice. Žute
naljepnice predstavljaju pozitivne segmente,
dok ljubičaste ukazuju na prostor za
unapređenje.
Usluga snimke stanja i ocjene zrelosti testnog
okruženja je drugačija od uobičajenog i, po
našem mišljenju, pogrešnog pristupa ovakvim
zadacima. Ako želimo dobiti presjek stvarnog
stanja nekog procesa unutar organizacije, onda
tradicionalni način jednostavno nije dovoljno
dobar.Višednevno prikupljanje dokumentacije
koja obično ne odražava stvarno stanje stvari,
pojedinačni razgovori s preopterećenim ljudima
koji se razvuku na dane, da ne kažem tjedne, i
subjektivne i nepotpune informacije ne mogu
garantirati kvalitetnu analizu okruženja.
Dobar referentni model i bogato iskustvo
naših stručnjaka omogućava brzu usporedbu
trenutačnog stanja s idealnim i prepoznavanje
koraka za unapređenje u roku od samo dan ili dva.

8. 8 | FYI by CROZ / broj 18 / svibanj 2015.
tema broja | Provjera zrelosti testnog okruženja
kompetentnu ekipu koja ima potrebna
znanja o internim procesima definiranja
i analiziranja poslovnih zahtjeva, razvoja,
puštanja u rad i, naravno, testiranja i
prihvaćanja isporuka.
U prvom dijelu se u tridesetak minuta
postavlja zajednička “referentna točka”
i pogled na idealni svijet testiranja.
Koliko god bio nedostižan, idealni svijet
predstavlja zajednički cilj koji mora
biti jasan svima, bez obzira na razinu
uključenosti u sami proces.
Bitno je definirati što za odabranu
organizaciju znači testiranje, prepoznati
koji se rječnik koristi i kako je posloženo
cjelokupno okruženje koje omogućava
odvijanje povezanih aktivnosti.
Zatim je važno osvijestiti potrebu za
metodološkim pristupom testiranju,
za strategijom i praksama, i na samom
kraju jasno postaviti temelje za nastavak
radionice.
Drugi dio je najduži i predstavlja
pravu radionicu, u tradicionalnom
SWOT analiza će ukazati na potrebne akcije s
ciljem poboljšanja okruženja
smislu. Ovdje je ključno vrlo aktivno
sudjelovanje stručnjaka iz organizacije
koju analiziramo. U svojoj osnovi, ideja je
jasno i nedvosmisleno prepoznati kako
izgleda cjelokupno testno okruženje, što
je prema mišljenju “radne skupine” dobro
i što treba zadržati, a što nije baš najbolje
i treba popraviti. Bitno je razumjeti da
nema točnih i netočnih odgovora već
da želimo iskreno i pošteno sami sebi
razjasniti kakvo nam je okruženje.
Detaljno se ulazi u analizu primijenjene
metodologije, u sami proces testiranja,
organizaciju i okruženje. Na primjer,
najčešće se pokaže da su ljudi vješti
u testiranju svojih aplikacija, ali da
nedostaje formalne naobrazbe, što
kasnije negativno utječe na komunikaciju
između timova, ili da se nedovoljno pažnje
posvećuje automatizaciji, čime se izravno
gubi vrijeme koje se moglo bolje iskoristiti
na nekom drugom mjestu.
Treći dio je možda i najrazličitiji od
uobičajenog pristupa, no jako je dobro
prihvaćen gdje god smo ga isprobali.
Radi se, naime, o kratkim i vrlo ciljanim,
direktnim intervjuima sa svakim od
polaznika radionice pojedinačno.
Iznenađuje koliko se novih informacije
može saznati u tih deset ili petnaest
Na jednom mjestu se vidi trenutačno stanje okruženja, preporuke za quick win i buduće, poboljšano
stanje
Stvarno je zanimljivo vidjeti koliko se korisnih
informacija može dobiti u razgovoru jedan-na-
jedan. Čim nema šefa ili kolega, ljudi se otvore i
progovore o stvarnim problemima. Osnovna je
pretpostavka da svi imaju želju unaprijediti svoje
radno okruženje pa tako ovakvi intervjui daju
ključne informacije što stvarno škripi i gdje treba
uložiti napore koji će voditi k poboljšanju procesa.
minuta razgovora, a pogotovo je
zanimljivo da tijekom intervjua uglavnom
isplivaju detalji kojima ljudi nisu
zadovoljni, ali im je bilo teško ili neugodno
reći u grupi. To je zapravo odlično, jer
tek tako možemo steći potpunu sliku o
procesu.
Tokom četvrtog dijela radionice
analiziramo prikupljene podatke i
pripremamo izvještaj, kao i završnu
prezentaciju koju predstavljamo dan
poslije, na petom i posljednjem dijelu.
Sve prikupljene informacije se vrednuju
i slažu u matricu ovisnih vrijednosti, kako
bi se na jednom mjestu moglo vidjeti
trenutačno stanje okoline.
Što dalje?
Provjera zrelosti testnog okruženja
će dati uvid u proces i organizaciju
testiranja, ukazat će na kritične detalje
koje treba popraviti kao i na one
segmente koje treba zadržati i osnažiti.
Rezultati snimke stanja, takozvani
“nalazi”, doslovce se mogu iskoristiti
kao popis zadataka koje treba ispuniti
kako bi se unaprijedilo testiranje, kako u
kratkom roku, recimo odmah za sljedeći
projekt, tako i dugoročno, za sve buduće
aktivnosti.
Trenutna procjena Prvi koraci Konačnapreporuka Savršeno testiranje
Praksa
Strategija
Proces
Kompentencije
Organizacija
Edukacija
Environment
Incident management tool
Test management tool
Security testing tool
Test automation tool
Performance testing tool
Analiza napretka

9. FYI by CROZ / broj 18 /svibanj 2015. | 9
Automatizacijom testiranja do kvalitete | tema broja
O
snovna 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 praksi
Praksa je pokazala da tvrtke, a i
zaposlenici koji su zaduženi za testiranje,
često gledaju na testiranje kao na nužno
zlo. Testiranje se najčešće obavlja ručno,
oduzima puno vremena i testeri imaju
dojam da gube vrijeme i da bi mogli raditi
nešto “pametnije”. Problem je posebno
izražen kada je potrebno testirati cijeli
sustav nakon svake nove izmjene, a to
najčešće rezultira time da se testiranje
obavlja brzo i površno, što dovodi
do pojave grešaka koje su se mogle
izbjeći kvalitetnijim i sistematičnijim
testiranjem. Naravno, to iziskuje i znatno
odvajanje dodatnih resursa kako bi se taj
postupak mogao provesti. Potrebni su
veći testni timovi, što znači zapošljavanje
novih testera ili dodjela testerskih poslova
zaposlenicima kojima to nije primarno
zanimanje, što je u praksi najčešći slučaj
i često dovodi do nezadovoljstva. Kako bi
se troškovi smanjili, a cijeli proces ubrzao
i unaprijedio, uvodi se automatizacija
testiranja. Kada se govori o automatizaciji
testiranja softvera uglavnom je riječ o
funkcijskom i regresijskom testiranju.
Funkcijskim testiranjem odgovara se
na pitanje: “Radi li implementirana
funkcionalnost onako kako se očekuje?”,
testira se ponašanje aplikacije u realnom
okruženju, onako kako bi je krajnji korisnik
koristio. Regresijsko se testiranje koristi
kako bi se provjerio utjecaj neke izmjene
na ostatak aplikacije. To znači da se neće
testirati samo funkcionalnost na kojoj se
radila izmjena, nego će se testirati cijela
aplikacija kako bismo se uvjerili da tom
izmjenom nije došlo do neočekivanog
rada u nekom drugom dijelu aplikacije.
Ovdje je već jasno izražena potreba
za automatizacijom, ručno testiranje
cijelog sustava ispočetka kod svake
izmjene prilično je naporan posao i praksa
pokazuje da ga ljudi nerado obavljaju.
Što je zapravo automatizacija
testiranja?
Automatizacija testiranja softvera
podrazumijeva korištenje specijaliziranih
alata koji omogućuju izradu testnih
skripti, njihovo izvršavanje i obradu
rezultata. U svom sam dosadašnjem
radu koristio razna programska rješenja
kao što su IBM Rational Functional
Tester, Selenium, HP Unified Functional
Testing, SmartBear TestComplete, TOSCA
Testsuite, BugBuster, a o nekima sam
detaljnije pisao u našem tehnološkom
blogu (http://goo.gl/fxlqAc).
Cijelo se vrijeme govori o automatizaciji
testiranja, ali kako zapravo automatizirati
neki testni scenarij? Kod ručnog testiranja
obično postoje testni slučajevi (test cases)
koji sadrže testne korake. Tester će ručno
proći svaki korak, upisivati razne ulazne
podatke, prolaziti kroz aplikaciju, pratiti
rezultate, provjeravati validacije, otvarati
i zatvarati prozore, uspoređivati dobivene
rezultate s očekivanima. Taj je proces
vrlo spor. Automatizirati taj proces znači
jednostavno pretvoriti testni slučaj u
testnu skriptu, pretvoriti testne korake
iz tekstualnog oblika u programski kod.
Nakon što je testna skripta dovršena, ona
se može izvršiti brzo, kada i koliko god
puta želimo. To znači da se sav zamoran
posao koji je tester ručno obavljao može
obaviti jednostavnim pokretanjem skripte.
Velika je prednost automatizacije testnih
skripti i u neograničenom skupu ulaznih
testnih podataka. Ista se skripta može
izvršiti više puta s različitim podacima,
a to omogućava kvalitetno i detaljno
testiranje. Testna skripta može dinamički
učitavati razne tablice koje se pojavljuju
na ekranima, provjeravati veliku količinu
Praksa pokazuje da se testiranje softvera najčešće provodi ručno. Ipak, za kvalitetnije i
sistematičnije testiranje preporuča se automatizacija tog procesa.
Piše: Ante Cikojević
Automatizacijom
testiranja do kvalitete

10. 10 | FYI by CROZ / broj 18 / svibanj 2015.
tema broja | Automatizacijom testiranja do kvalitete
Jedna ste od vodećih banaka na tržištu u
Hrvatskoj i regiji, gdje leži tajna vašeg uspjeha i
održavanjakonkurentnosti?
Odgovor je lako pronaći u našoj viziji – biti
najbolja banka u Hrvatskoj koja brine o sigurnosti
svojih klijenata i pruža najkvalitetnije proizvode
i usluge. Kad smo kod toga – upravo u domeni
sigurnosti te u kvalitetnim proizvodima i uslugama IT
igra ključnu ulogu u banci te tu vidimo vaš doprinos u
području testiranja sofvera.
Zašto ste nakon toliko godina odlučili krenuti u
potragu za strateškim outsourcing partnerima u
domeni razvoja i testiranja softvera?
Smanjenje troškova vezanih uz non-core
business prva je pomisao koja se javlja na spomen
outsourcinga, međutim fleksibilnost se pokazala kao
jedna od ključnih prednosti outsourcinga. Izazovi s
kojima se susrećemo na ključnim projektima unutar
banke zahtijevaju prije svega izrazitu fleksibilnost
– upravo je ta fleksibilnost i bila jedan od glavnih
razloga za pokretanje strateškog outsourcinga unutar
Erste banke. Nadalje, u partnerskom odnosu možemo
učitanih podataka, provjeravati numeričke
izračune i slične zadatke koji bi ručnim
testiranjem trajali jako dugo. Ako se
taj proces automatizira, izvršavanjem
testne skripte svi navedeni zadaci obave
se u samo nekoliko sekundi. Osim što
se automatizirati može sve što korisnik/
tester radi u samoj aplikaciji, testna skripta
može prolaziti kroz korake testnog slučaja
i istovremeno provjeravati ispravnost
spremljenih podataka direktno u bazi.
Dubina i kompleksnost posla koji 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 (ProofofConcept)
dokaže da je vodeći partner na tržištu u uslugama testiranja softvera, i ispit je položen s odličnim!
NakonuspješnorealiziranogPoC-ausklopukojegsmodokazalinašuekspertizuurazličitimvrstamatestiranja,
izmeđuostalogutvorničkomtestiranjutekućegrazvoja,izradiautomatiziranihregresijskihtestovateizraditestova
zaobradne(batch)programe,stručnjaciCROZ-aiErsteauskosuiuspješnosurađivaliuspostavljanjemvisokog
stupnjarazumijevanja,konkretnihunaprjeđenjausvakodnevnomtestiranjubanketeujednačenemetodologije.
SamompočetkuangažmanajeprethodiloicertificiranjevećegbrojanašihstručnjakazaradstestnimalatomTOSCA,
kojije“kućni”alatubanci.Nakontogasmozajedničkikrenuliustrateškopartnerstvo.Većjegodinakvalitetne
suradnjeizanas,tesmotimpovodomrazgovaraliodojmovimaoveuspješnepričeskoordinatorimaprojektasErstei
CROZ-ovestrane:TomislavomKirincemiDarkomMarijančićem.
Automatizacija testiranja u
Erste&Steiermärkische banci
naučiti nešto od drugih i tu dodatnu vrijednost
pretočiti i u naša rješenja.
U natječaju je osim domaćih tvrtki bila prisutna
renomirana internacionalna konkurencija.
Nije baš svakidašnja situacija da se tvrtke iz
Indije pojavljuju kao konkurencija na domaćem
tržištu. Kad ih uspoređujete s domaćim
tvrtkama, kako biste ocijenili njihov pristup
i ostale karakteristike u odnosu na domaće
tvrtke?
Pristup naših strateških partnera iz Indije izrazito
je profesionalan i strukturiran, te možemo reći da smo
i mi neke stvari naučili od njih glede izvještavanja
i strukturiranog pristupa u domeni outsourcinga.
Razlike u odnosu na domaće tvrtke itekako postoje,
Tomislav Kirinec, koordinator projekta s Erste strane s
Lukom Gautom, CROZ-ovim voditeljem ključnih kupaca
Tomislav
Kirinec
sITSolutions
(Managerfor
ExternalITService
Providers)

11. FYI by CROZ / broj 18 /svibanj 2015. | 11
Automatizacijom testiranja do kvalitete | tema broja
U Hrvatskim se prilikama i velike organizacije podržane brojnim
informacijskim sustavima teško odlučuju na automatizaciju testiranja. Glavni
su izgovori visoki inicijalni troškovi alata i obuke ljudi. No, to nije slučaj u
Erste & Steiermärkische banci, koja već niz godina strateški ulaže i provodi
automatizaciju regresijskih testova za velik broj svojih informacijskih sustava.
Počeci suradnje ponudili su nam nekoliko izazova. U postojeće Ersteove
planove, procese, infrastrukturu i timove potrebno je bilo uklopiti veći broj
CROZ-ovih testera različitih profila. Ersteovi stručnjaci organizirali su i održali
s nama niz radionica i telekonferencija s ciljem prijenosa znanja te lakše i brže
prilagodbe CROZ-ovih testera. Bilo je potrebno da i CROZ interno obuči više od
10 testera za korištenje alataTOSCA, koji do sada u CROZ-u nije bio primaran
testni alat. Bitno je reći da alatTOSCA korišten u Ersteu uvelike pridonosi
kvaliteti poslovnih rješenja omogućavanjem automatiziranih testova. Održan
je i niz sastanaka i radionica s članovima Ersteova tima s ciljem prenošenja
iskustava CROZ-ovih stručnjaka. U svakom slučaju, možemo se pohvaliti da
smo dosta toga naučili od kolega iz Erstea, ali i uspjeli podijeliti naše znanje i
iskustvo s njima – što je i bit strateškog partnerstva.
Danas, s preko 2 000 automatiziranih testova“u nogama”, CROZ ima
uhodani testni tim koji sve kvalitetnije i efikasnije odgovara specifičnim
potrebama Banke, a Erste kvalitetnog i pouzdanog partnera s kojim je
bitno osnažio svoje vlastite kapacitete testiranja. Ovo iskustvo pokazuje da
kvalitetna strategija testiranja, te prije svega sustavna i dobro osmišljena
obuka ljudi, u relativno kratkom roku može opravdati sva ulaganja u
automatizaciju testiranja.
programskog rješenja koje se testira. Ipak,
praksa je pokazala da se najčešće koristi
kombinacija tih dviju metoda, tako da
opcijom snimanja prvo dobijemo “kostur”,
a nakon toga manipulacijom i dodavanjem
koda do kraja izradimo testnu skriptu.
Human vs. machine
Vjerujem da je već jasnije koliko se
automatizacijom dobije na brzini
testiranja s obzirom na to da jednom
snimljenu skriptu možemo koristiti
zauvijek. Što se više testnih slučajeva
automatizira, to je proces testiranja
kvalitetniji i pouzdaniji. Ručni proces
regresijskog testiranja troši puno
vremena, a problem je posebno izražen
kod agilnog razvoja, gdje su česte
isporuke nove verzije programskog
rješenja. Automatizacijom tog procesa
postižu se goleme uštede na vremenu, a
posebnu snagu daju i unaprijed definirani
rasporedi izvršavanja testova (test
schedule). Na taj se način kod agilnog
razvoja na kraju svake iteracije mogu
automatski izvršavati regresijski testovi
(npr. preko noći), a tester rezultate može
pregledati sutra ujutro ili ih čak dobiti
e-mailom.
Budući da automatizacija testiranja
donosi značajnu uštedu vremena
potrebnog za testiranje, kvalitetniji proces
testiranja, poboljšanje kvalitete proizvoda
koji se isporučuje i u konačnici veće
zadovoljstvo korisnika/naručitelja samim
proizvodom, ne čudi što današnji trendovi
idu u smjeru razvoja automatizacije
testiranja.
Omjer troškova ručnog i automatiziranog testiranja
posebice u kulturološkom dijelu, ali smo jako zadovoljni što možemo
istaknuti da smo puno toga naučili na tom području od indijskih partnera,
a i neke smo naše tradicije i običaje podijelili s njima – na veliko obostrano
zadovoljstvo. Jeste li znali što je to Festival svjetla – Divali, Festival boja –
Holi festival, tko je pripadnik koje kaste – kako se to lako uoči iz prezimena,
da ima pojedinaca koji imaju samo jedno ime (nemaju prezimena) itd. – sve
se to može naučiti preko weba, međutim puno je to ugodnije i zanimljivije
čuti uživo
Iza vas je već gotovo godina dana suradnje s CROZ-om, kako biste
ocijenili dosadašnji zajednički rad i kako vidite budućnost?
Prilikom procesa nabave gdje smo birali nove strateške partnere uzeli
smo u obzir potencijalne partnere u regiji, a tako i šire. Nakon što je odrađen
uži izbor, krenuli smo i s ProofofConceptom, gdje smo potencijalnim
partnerima dali manje projekte kako bismo osim financijske odradili i
tehničku evaluaciju. Smatram da CROZ može biti ponosan što je nakon
takvog detaljnog procesa izabran za našeg strateškog partnera – posebice
što se osim financijskog dijela uvelike gledala tehnička evaluacija s
naglaskom na kvalitetu isporuke.
U svakom početku, pa tako i u našem strateškom partnerstvu, bilo
je dosta dječjih bolesti.Tu činjenicu ne treba skrivati, čak štoviše, to je
samo pokazatelj da smo ozbiljno pristupili ovoj dugoročnoj suradnji – bilo
bi čudno da je sve išlo glatko. Međutim, izrazito dobrom međusobnom
komunikacijom i koordinacijom rješavali smo sva otvorena pitanja
u hodu te sa zadovoljstvom mogu reći da danas imamo suradnju na
zadovoljavajućem nivou.Tome uvelike pridonosi postavljen governance
model s naše strane, koji uključuje standardizirano izvještavanje,
redovitu komunikaciju i eskalacijski model – gdje vas moram pohvaliti na
ozbiljnom i profesionalnom pristupu. Istraživajući ovaj dio IT industrije,
došao sam do spoznaje da je zadovoljstvo internih korisnika sa strateškim
outsourcing partnerima tim veće što je bolji governance model i relationship
management. S obzirom na to da ste vi tu pokazali izrazitu profesionalnost, a
uz to i dokazali da možete pružiti kvalitetnu isporuku, budućnost vidim kao
zaista dugoročnu suradnju i partnerstvo.
RUČNOTESTIRANJE
AUTOMATIZIRANOTESTIRANJE
Vrijeme
Ljudi
Infrastruktura
Alati
Obučavanje
Darko
Marijančić
CROZd.o.o.
(koordinator
CROZ-ova
testnogtima)

12. 12 | FYI by CROZ / broj 18 / svibanj 2015.
tema broja | Performansno testiranje
P
erformansno testiranje je razina
testiranja web aplikacija ili
serverski orijentiranih aplikacija
kojoj je svrha utvrditi kako
se aplikacija ponaša pod definiranim
opterećenjem i ispunjava li očekivanja.
Izvršavanje performansnog testa je
procedura koja imitira konkurentne
korisnike i opterećuje sustav, prati
ponašanje sustava te prikuplja podatke
i metrike o opterećenom sustavu,
koje ćemo poslije koristiti za analizu
ponašanja i donošenje zaključaka o
performansama aplikacije ili sustava.
Fokus performansnog testiranja je:
• brzina rada aplikacije – izmjeriti
odzivna vremena aplikacija
• skalabilnost – odrediti maksimalan
broj konkurentnih korisnika koje
aplikacija može uspješno poslužiti
• stabilnost – provjeriti koliko je
aplikacija stabilna pod velikim
opterećenjem
Performansno
testiranje
• propusnost – izmjeriti može li
aplikacija obraditi zahtijevanu količinu
podataka i transakcija u planiranom
vremenu
• definirati minimalnu i optimalnu
konfiguraciju sustava na kojem
aplikacija radi.
Cilj performansnog testiranja nije
otkriti funkcionalne greške, jer aplikacija
namijenjena performansnom testu mora
biti funkcionalno ispravna, nego ukloniti
performansna uska grla aplikacije i
podesiti sustav na kojem aplikacija radi.
Zašto radimo performansne
testove?
Poslije isporuke nove aplikacije ili nove
funkcionalnosti mnogi su timovi iskusili
probleme s performansama aplikacije.
Postavlja se pitanje zašto performansni
testovi nisu pripremljeni i izvršeni na
vrijeme. Često je razlog nedostatak
vremena, no ponekad je razlog i
nedostatak znanja i iskustva u izvođenju
performansnih testova.
Tipoviperformansnogtestiranja
• Load testing – provjerava odzivna vremena
kritičnih poslovnih scenarija i transakcija te
provjerava jesu li u okvirima očekivanja
• Stress testing – provjerava maksimalno
opterećenje i broj istovremenih korisnika za koje
se aplikacija još uvijek uspješno odziva
• Volume testing – provjerava propusnost i
kapacitet sustava, može li aplikacija obraditi
zadanu količinu podataka i transakcija u
definiranom vremenu
• Longevity ili Endurance – provjerava
ponašanje aplikacije i identificira probleme
koji će se pojaviti ako je aplikacija duže vrijeme
izložena konstantnom vršnom opterećenju
Piše:
Miroslav
Zaninović
Hoće li nova funkcionalnost utjecati na brzinu rada aplikacije? Može li aplikacija izvršiti 5 000
transakcija u jednom satu? Hoće li se aplikacija odzivati unutar 5 sekundi ukoliko je opteretimo s
500 istovremenih korisnika? Hoće li 5 000 konkurentnih sesija srušiti sustav?
Mnogo je pitanja na koje ne možete odgovoriti bez performansnog testiranja.

13. FYI by CROZ / broj 18 /svibanj 2015. | 13
Performansno testiranje | tema broja
Performansne testove radimo da
bismo osigurali zahtijevanu brzinu,
skalabilnost, stabilnost i propusnost.
Važno je da performansni test otkrije
performansne probleme i uska grla
u radu aplikacije na vrijeme, kako bi
programeri i sistemski inženjeri što
prije uklonili ili unaprijedili performanse
aplikacije i infrastrukture koje aplikacija
koristi. Provođenje performansnih
testova se laiku na prvu može učiniti
presloženim, no u konačnici to je
jedini način za brzo identificiranje
performansnih problema i uskih grla, te
je znatno jeftinije od njihova uklanjanja
ako takvo testiranje izostane.
Proces performansnog testiranja
Planiranje i dizajn testova predstavlja
definiranje ciljeva koje moramo postići
performansnim testom. Prvenstveno
definiranje propusnosti sustava i
maksimalno očekivanih vremena odziva
aplikacije. Te će nam informacije pomoći
da odredimo broj konkurentnih sesija
ili korisnika, kapacitet infrastrukture
potrebne za generiranje workloada i
kreiranje scenarija izvršavanja testova.
Workload je scenarij koji će se izvršavati
nad sustavom (transakcije i frekvencija
izvršavanja transakcija, testni podaci i
kriteriji prikupljanja podataka) i mora
biti što sličniji stvarnim korisničkim
scenarijima, koji će ispitati i potvrditi
rizike.
Kreiranje i provjera testova
predstavljaju snimanje i pripremu
kritičnih transakcija i scenarija koje
performansni test treba izvršiti. To je
ujedno i najzahtjevniji dio procesa jer u
toj fazi moramo osigurati pouzdanost,
ispravnost i repetitivnost svakog testa, te
osigurati upravljanje zavisnim podacima
kroz cijeli scenarij testa. Workload mora
biti pripremljen tako da zadovoljava
zahtijevanu propusnost, ali ujedno mora
imitirati realnu interakciju sa sustavom
i optimalno koristiti infrastrukturu
predodređenu za performansno testiranje.
Priprema testnog okruženja
predstavlja pripremu odgovarajuće
verzije aplikacije za test, konfiguraciju
infrastrukture potrebne za performansni
test, pripremu testnih podataka, pripremu
alata za praćenje testiranog sustava i
instaliranje potrebnih licenci.
Kako vam CROZ može pomoći
u performansnom testiranju?
CROZ-ov je testni tim kroz godine razvoja
aplikacija stekao zavidna znanja u pripremi i
izvršavanju performansnih testova u različitim
okruženjima i na različitim tehnologijama.
Spremni smo vam pomoći prilikom planiranja i
određivanja kapaciteta performansnih testova,
odabira optimalne infrastrukture za izvršavanje
testova, pripreme i dizajna testova te izvršavanja
i tumačenja rezultata testiranja. Svojim vam
znanjem i iskustvom stojimo na raspolaganju i
pri odabiru adekvatnih alata za performansno
testiranje.
Proces performansnog testiranja
Infrastruktura za performansno
testiranje obično se sastoji od konzole
koja služi za upravljanje testom i
opterećenjem te agenata koji simuliraju
krajnje korisnike aplikacije. Izrada i
priprema workloada uvelike ovisi i o
dostupnoj infrastrukturi i broju dostupnih
agenata.
Izvršavanje performansnih
testova i prikupljanje metrika odvija
se uvijek u nekoliko iteracija, svaka
iteracija otkriva nove performansne
rizike koji se postupno uklanjanju
dok u konačnici aplikacija ne ispuni
zahtjeve i postigne željenu propusnost.
Rezultati performansnog testa moraju
omogućiti donošenje odluka i zaključaka
o performansama. Minimum koji
rezultati moraju pružiti jesu prosječno,
minimalno i maksimalno vrijeme odziva,
devijacija podataka te postotci uspješno i
neuspješno obrađenih zahtjeva.
IBM Rational Performance Tester
Kako bismo vam približili proces
performansnog testiranja, objasnit ćemo
ga kroz praktičan primjer upotrebe alata
koji najčešće koristimo. IBM Rational
Performance Tester (RPT) alat je za
kreiranje, izvršavanje i analizu rezultata
performansnih testova koji pokriva velik
raspon protokola i tehnologija, stvoren
za provjeru skalabilnosti i pouzdanosti
web i enterprise aplikacija. Alat uključuje
funkcionalnosti za snimanje i uređivanje
testova, izradu scenarija i workloada
za izvršavanje testova, izvještavanje i
mehanizam za izvršavanje testova.
IBM Rational SaaS (Software as a Service)
Ukoliko imate projekt na kojem postoji potreba za performansnim testiranjem, a ne namjeravate investirati u
uvođenje alata, CROZ vam može ponuditi usluge najma licenci kroz program IBM Rational SaaS (Software as
a Service). Putem SaaS programa pružena vam je mogućnost najma licenci na ograničeno vrijeme, čime ćete
imati osjetno niže troškove licenci, nećete morati investirati u infrastrukturu, a bit ćete u mogućnosti postići
zadane ciljeve. SaaS program omogućuje vam najam licenci za Rational PerformanceTester, IBM AppScan
i Rational Quality Manager (IBM rješenje za upravljanje testiranjem). Usluge pripreme testiranja možete,
naravno, s punim povjerenjem povjeriti CROZ-ovim stručnjacima.

14. 14 | FYI by CROZ / broj 18 / svibanj 2015.
tema broja | Performansno testiranje
Za vašu smo instituciju samo ove godine radili
nekoliko performansnih testova. Bilo je tu
aplikacija koje razvija CROZ, ali i aplikacija
drugih dobavljača. Možete li nam reći koji
su vam motivi pri odlučivanju što ćete i kada
performansno testirati?
Sve aplikacije se performansno testiraju
prije produkcije. Kad neka aplikacija počinje svoj
produkcijski život, onda želite biti sigurni da će izdržati
nalet svih korisnika i sve njihove zahtjeve, upite i
transakcije. U slučaju da aplikacija ima prekide ili
Performansno testiranje u Raiffeisen banci
Alan-Mirko
Poldrugač
Raiffeisenbank
Austriad.d.
(direktorSD
organizacije,
procesaiprojekata)
ispade u svom radu, to nas može koštati znatno više
od onog što uložimo u testiranje prije produkcije.
Drugo je pitanje kada pristupiti performansnom
testiranju?Tu treba biti praktičan i pogoditi
pravo vrijeme. Ukoliko to bude previše rano, dok
aplikacija još nije spremna za integralni test, onda
ćete vjerojatno morati ponoviti test nešto kasnije,
neposredno prije produkcije. Opet, kad je to previše
kasno, odmah prije produkcije, onda nećete imati
vremena popraviti stvari ukoliko aplikacija padne na
testu. Kao što je to s većinom stvari u životu, morat
ćete pogoditi pravu mjeru stvari, niti prerano niti
prekasno. Po našem iskustvu, najbolja mjera je na
početku integralnog testa.
Kakva je bila aplikacija koju smo zadnju testirali
i kakvi su bili rezultati testiranja?
Zadnje testirana aplikacija je bio novi sustav
za naplatu potraživanja. Uredno je prošao na
performansnom testu, odnosno nismo ga uspjeli
srušiti iako smo pokušavali s nekoliko trikova. Kasnije,
u produkciji, opravdao je očekivanja i uredno radi
bez zastoja, sukladno rezultatima koje smo imali na
testiranju. Ipak, moram naglasiti da se ovdje radi o
drugoj verziji tog sustava i da smo očekivali da neće
biti problema s performansama. Kad smo radili test
prve verzije istog sustava, prije godinu i pol, tada
smo uspjeli srušiti sustav i morali smo raditi ozbiljne
preinake kako bi isti zadovoljio performansne uvjete
za produkcijski rad.
Koristili ste Software as a Service (SaaS) model
licenciranja alata, kakva su iskustva?
Iskustva su pozitivna. U slučajevima kad
povremeno imate potrebu za korištenjem određenog
alata i odgovarajućih znanja, onda je bolje“unajmiti”
komplet tog alata i podrške na određeno vremensko
razdoblje.Takva usluga uključuje zadnju verziju
alata i podršku osobe koja ima iskustvo s traženim
područjem. Na taj način izbjegavate probleme s
održavanjem verzija, odnosno taj dio prebacujete na
pružatelja usluge.
Opet, ukoliko redovito koristite takav alat u
svakodnevnim aktivnostima, onda je dobro razmisliti
i izračunati isplativost kupnje i održavanja istog u
vlastitim redovima.
RPT pomoću snimalice prometa
omogućuje brzu pripremu testova
neovisno o tehničkim i poslovnim
kompetencijama testera. Za pripremu
i snimanje testova potreban je samo
web preglednik ili desktop klijent koji
komunicira sa serverom, za ostalo će
se pobrinuti RPT. Snimljeni će se test
prikazati u editoru kao stablo zavisnih
requesta i responsa, spreman za
uređivanje i izvršavanje. Snimljeni test se
također može prikazati u web pregledniku
kako bismo mogli vizualno provjeriti izgled
stranica i podataka korištenih za vrijeme
snimanja testova. Workload Schedule vam
kroz svoje opcije omogućava kombiniranje
različitih testova u jedinstveni workload
scenarij, koji je u mogućnosti generirati
realno korisničko opterećenje te
promjenu i ugađanje vršnog opterećenja
za cijelo vrijeme trajanje testa. Veliko
opterećenje zahtijeva i infrastrukturu koja
će moći generirati takvo opterećenje, a
RPT vam korištenjem agenata omogućava
optimalno iskorištavanje vaše
infrastrukture. RPT podržava data-driven
testove, čime omogućava realne testove
s realnim podacima. Svaki korisnik ili
sesija koji RPT koristi u tom slučaju koristi
jedinstvene testove. Alat također prilikom
snimanja sam otkriva potencijalne
kandidate za zamjenu s realnim
podacima. Na kraju treba spomenuti
izvještavanje koje nam omogućava da
provjerimo jesmo li zadovoljili željene
zahtjeve i postigli traženu skalabilnost.
Prikupljajući maksimalne, minimalne i
prosječne vrijednosti, računajući prosjeke
i devijacije, RPT nam daje uvid u zdravlje
servera, aplikacije i transakcija. Dobiveni
se izvještaji mogu uspoređivati kako
bismo saznali koliko su konfiguracije
utjecale na performanse sustava te
eksportirati i kao takvi priložiti kao završni
izvještaj o testiranju.
Zaključak
Performansni testovi su neophodni
prilikom objavljivanja novih softverskih
produkata, osobito servisa koji su javno
dostupni. Troškovi performansnog 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
Rational
Performance
Tester
Performance
Tester Agents
System UnderTest

15. Prema zadnjem istraživanju tvrtke Aumcore, godišnji je rast tržišta
mobilnih aplikacija u posljednjih nekoliko godina otprilike 30%, uz
očekivanu vrijednost u 2015. godini od 25 milijardi dolara. (Izvor:
www.aumcore.com)
FYI by CROZ / broj 18 /svibanj 2015. | 15
Testiranje mobilnih aplikacija | tema broja
U
današnje vrijeme kada tržište
mobilnih aplikacija eksponen-
cijalno raste, konkurentnost
je iznimno bitna. Kako bismo
ostali konkurentni na tržištu, potrebno
je u što kraćem roku izbaciti kvalitetan
proizvod na tržište. Da bi se osigurala
kvaliteta proizvoda, potrebno je razraditi
pametnu strategiju provođenja testiranja.
S obzirom na iznimno veliku ponudu
mobilnih uređaja, testiranje mobilnih
aplikacija predstavlja pravu avanturu
u kojoj je potrebno suočiti se s brojnim
izazovima, od kojih su najveći:
• različiti OS-ovi i pripadajuće verzije
• hardverske razlike uređaja
• brze i učestale nadogradnje aplikacija.
Testni tim nije u mogućnosti
garantirati da će neka funkcionalnost
koja radi na jednom uređaju raditi i na
nekom drugom, čak i u slučajevima kada
je riječ o sličnim mobitelima s recimo istim
operacijskim sustavom. Razlog tomu
može biti postojanje razlika u rezoluciji
ekrana, CPU-u, memoriji, kao i drugačiji
hardver.
Strategija testiranja
U cilju lakšeg svladavanja svih izazova
potrebno je definirati kvalitetnu strategiju
testiranja, koja uključuje:
• odabir ciljanih uređaja (iOS/Android,
tablet/smartphone, različite veličine
ekrana, CPU, memorije...)
• automatizaciju testiranja radi
neminovne nadogradnje aplikacija
novim funkcionalnostima i OS-a u
cilju održavanja konkurentnosti te u
konačnici i samog smanjenja troška
regresijskog testa kojim potvrđujemo
da prije implementirane funkcionalnosti
s novom nadogradnjom i dalje rade
kako je očekivano
• odabir različitih tipova testiranja za
funkcijsko i nefunkcijsko testiranje, kao
što su npr.:
• testiranje korisničkog
iskustva (usability
testing), što uključuje
vidljivost na odabranom
jeziku, navigaciju između
ekrana, verifikaciju
implementiranih
funkcionalnosti online i offline,
feedback kod interakcije s aplikacijom
– npr. ako je korisnik preuzeo
aplikaciju, na mobitelu bi se trebala
javiti poruka ili bi se aplikacija trebala
početi instalirati na uređaj
• funkcijsko testiranje (functional
testing) predstavlja testiranje
ispravnosti pojedinih funkcionalnosti
aplikacije i odgovara li implementacija
korisničkim zahtjevima
• testiranje kompatibilnosti
(compatibility testing) podrazumijeva
validaciju aplikacije na različitim
uređajima s različitim operacijskim
sustavima, veličinama ekrana i
različitim rezolucijama. Također
provjerava kako aplikacija radi s
ostalim aplikacijama
• operativno testiranje (operational
testing) podrazumijeva testiranje
aplikacije u slučaju da se baterija
isprazni, mogućnosti gubitka
podataka u slučaju upgradea,
dostupnost aplikacije u slučaju da
korisniku počne zvoniti alarm, primi
poziv, poruku
• mrežno testiranje (network testing)
– testiranje ponašanja aplikacije u
različitim mrežnim uvjetima koje
generiraju specijalizirani alati.
Pišu: Martina Bajza i Ivana Skorupan
Testiranje
mobilnih aplikacijaU ovom tekstu govorimo o osnovnim smjernicama za testiranje
kvalitetnih mobilnih aplikacija kako bismo pojačali konkurentnost
na jednom od najbrže rastućih tržišta današnjice.
Opis strategije testiranja
STRATEGIJA
TESTIRANJA
Provođenje
različitih
tipova
testiranja
Automatizacijatestiranja
Definiranje
ciljane
skupine
uređaja

16. 16 | FYI by CROZ / broj 18 / svibanj 2015.
tema broja | Testiranje mobilnih aplikacija
Uređaji
Nakon definiranja strategije testiranja
mobilne aplikacije potrebno je odrediti
način testiranja, odnosno uređaje na
kojima će se provoditi testiranje.
Fizički uređaji
Testiranje je aplikacije na ciljanoj skupini
uređaja najpouzdanije i najtočnije, a
posebice za testiranje korisničkog iskustva
(user experience). Naravno, s obzirom na
broj uređaja koji se nalaze na tržištu, od
kojih je samo Androida otprilike 20 000,
investicija u uređaje je iznimno visoka.
Kako je korisničko iskustvo presudno
za uspjeh mobilne aplikacije na tržištu,
nužna je određena investicija u fizičke
uređaje.
Emulatori
Emulator predstavlja softver koji se
pokreće na računalu i oponaša fizički
uređaj (vidi sliku Android emulatora).
Prije samog pokretanja emulatora
potrebno je instalirati Android SDK
(Software Development Kit) i definirati
AVD (Android Virtual Device), kojim se
definira hardver kao što je RAM, ima li
uređaj zaslon osjetljiv na dodir, fizičku
tipkovnicu, kameru... Moguće je kreirati
više AVD-ova za potrebe testiranja na više
uređaja.
Emulatori su uglavnom besplatni i
na njima je moguće raditi performansno
testiranje, funkcijsko testiranje i stres-
test. Emulatori mogu poslužiti i za
automatizaciju testiranja jer se na njima
mogu pokretati i automatske skripte.
S obzirom na to da je za
potpuno testiranje potrebno
testirati aplikaciju na fizičkom
uređaju, umjesto kupnje
uređaja, korištenje uređaja od
treće strane (vanjski servis)
može biti korisno za provjeru
rada aplikacije u uvjetima
stvarnog svijeta.
Cloud servisi za testiranje
Cloud servisi za testiranje
predstavljaju vanjski servis
koji nudi uslugu najma
uređaja, čime se testiranje
mobilnih aplikacija znatno
unaprijedilo. Uređajima na
kojima će se raditi testiranje može se
pristupiti na jednostavan način kroz
web preglednik. Nakon prijave u servis
tester odabire željeni fizički uređaj koji
je trenutačno dostupan te započinje s
procesom testiranja. Testiranje se može
provoditi ručno, a određeni servisi nude
mogućnost automatizacije testova kao
i integraciju s testnim alatima. Također,
moguće je paralelno vršiti testiranje na
više uređaja. Cloud servisi, osim samog
testiranja, pružaju i podršku za različite
vrste izvještaja vezanih uz rezultate testa.
Kompanije koje koriste cloud servise za
testiranje mogu znatno smanjiti troškove
testiranja zato što se takvi servisi mogu
unajmiti po satu korištenja te je moguće
mijenjati uređaje na kojima se radi test.
Učinkovit odgovor na izazove
testiranja mobilnih aplikacije nalazi se
u optimalnom izboru ciljanih uređaja.
Nadalje, kombinacijom testiranja na
emulatorima i na fizičkim uređajima
ili unajmljivanjem cloud servisa može
se postići zadovoljavajuća pokrivenost
testovima bez potrebe testiranja
svih značajki na svakom uređaju.
Maksimiziranje automatizacije testiranja
učinkovit je način za ubrzanje procesa
testiranja koji dugoročno omogućava
smanjenje troškova.
Testiranje mobilnih aplikacija u
CROZ-u
U duhu agilne metodologije, proces
testiranja u CROZ-u prisutan je u svim
fazama razvoja. Prije nego što započnemo
rad na projektu, u suradnji s naručiteljima
provodimo istraživanje o tome koji su
ciljani korisnici sustava, kakvo je realno
opterećenje sustava u stvarnom svijetu
i slično. Na temelju tih informacija,
vezano za testiranje, donosimo odluku
o tome koje ćemo vrste testiranja
provoditi, na kojim je fizičkim uređajima
potrebno napraviti testiranje da bi se
zadovoljile korisničke potrebe te koji je
alat(i) najprikladniji za pisanje skripti za
regresijsko i performansno testiranje.
Testiranje počinje u najranijoj mogućoj
fazi, a to znači već nakon implementacije
prvog planiranog seta funkcionalnosti.
Iskustvo je pokazalo da testiranje na
emulatoru tijekom samog razvoja
koje provodi razvojni tim koji razvija
funkcionalnosti daje odlične rezultate. Na
taj smo način postigli najranije moguće
uočavanje nedostataka i potencijalnih
defekata čija bi cijena ispravljanja u
kasnijoj fazi razvoja bila puno viša, a
ispravljanje kompleksnije. Nakon što
razvojni tim testira funkcionalnosti,
testiranje započinje testni tim. On provodi
funkcijsko, istraživačko i operativno
testiranje na emulatorima i na ciljanim
fizičkim uređajima. Testiranja provodi na
vlastitim fizičkim uređajima te prema
potrebi na uređajima kolega koji su voljni
sudjelovati u testiranju. Testiranjem
na fizičkim uređajima postižemo rano
uočavanje nedostataka u korisničkom
iskustvu koje je presudno za krajnji
uspjeh razvijenih aplikacija na mobilnom
tržištu, koje je svakim danom sve veće
i zahtjevnije. Na temelju rezultata
dobivenih testiranjem donosi se odluka o
spremnosti funkcionalnosti za isporuku
korisniku. Razvojni i testni tim prilikom
prvog testiranja nove funkcionalnosti
koriste kriterije prihvaćanja koji su
definirani za svaku funkcionalnost prije
samog početka implementacije, ali i
svoju kreativnost i maštu, te na taj način
simuliraju velik broj realnih korisničkih
scenarija. Nakon svake iteracije inicijalno
raspisane kriterije prihvaćanja pretvaramo
u detaljniju dokumentaciju za testiranje,
koja stalnim nadopunjavanjem nakon
svake nadogradnje zapravo postaje i
službena dokumentacija za testiranje.
Tako opisan proces testiranja ponavljamo
sa svakom novom iteracijom kako bismo
bili sigurni u ispravnost i stabilnost
aplikacije, što osigurava kvalitetniju
isporuku korisnicima.
Android emulator

17. FYI by CROZ / broj 18 /svibanj 2015. | 17
ŠtojesustavzaIdentityGovernance?
Dok se “klasični” sustavi za upravljanje
identitetima i pristupom bave uglavnom
upravljanjem životnim ciklusom identite-
ta i pravima pristupa na tehničkoj razini,
sustavi za Identity Governance nadgrad-
nja su koja omogućuje organizacijama
definiranje, pregled i izvještavanje (npr.
za potrebe revizije) politika za upravljanje
identitetima i pristupom te omogućuje
mapiranje funkcija sustava za upravljanje
identitetima i pristupom na zahtjeve koje
postavljaju standardi s kojima organizacija
treba biti usklađena.
Prilikom utvrđivanja usklađenosti u
nekoj organizaciji lanac događaja često
izgleda kako je prikazano na slici.
Najčešće je rezultat svega mukotrpno
ručno prikupljanje podataka i višestruki sa-
stanci na kojima će se “otkriti” koje ovlasti
zapravo neka osoba ima. Osim toga, vrlo
je teško otkriti opasne kombinacije ovlasti
koje bi zaposlenik s početka priče mogao
imati (npr. izradu i odobrenje ponude u
jednoj osobi), kao i kada je tko za što bio
ovlašten i trebaju li mu još te ovlasti.
IBMSecurityIdentityGovernance
Na scenu stupa IBM Security Identity
Governance (ISIG), novo IBM-ovo rješenje
za upravljanje (governance) identitetima i
pristupom.
IBM Security Identity Governance ima
za cilj pomoći organizacijama da učinkovito
upravljaju identitetima i pristupom 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

18. 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 alatima
ISIG se može dobro integrirati s IBM Security Identity Managerom (ISIM) putem integracijskog adaptera
(ISIGADI) temeljenog na IBM Security Directory Integratoru.Taj adapter omogućuje sinkronizaciju podataka
o entitetima (ljudi, korisnički računi, servisi, role, grupe i organizacije) između IBM Security Identity
Governancea i IBM Security Identity Managera. Pritom ISIM preuzima ulogu izvršitelja promjena na
servisima, a ISIG ulogu mozga cijele priče upravljanja identitetima. Postoji i posebni paket (IBM Security
Identity Governance and Administration) koji objedinjuje oba produkta pod jednim partnumberom.
i web aplikacijskom serveru uz nekoliko
glavnih funkcionalnih modula:
• Accessrequestmodul, koji pruža na-
predne mogućnosti upravljanja tijekom
zahtjeva za pristupom te samoposluž-
nim mogućnostima (kada korisnik sam
zahtijeva neki oblik pristupa za sebe)
• Accessgovernancemodul, koji pruža
funkcionalnosti razdvajanja ovlasti,
usklađenosti sa SAP sustavima te
revizije prava pristupa
• Accessinteligencemodul, koji pruža
mogućnosti analize uloga (role analysis)
i “rudarenja” uloga (role mining).
Zaključak
ISIG predstavlja korisnu nadogradnju na
postojeće IBM-ove (i ne samo IBM-ove)
produkte za upravljanje identitetima i
pristupom koja omogućuje da se 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
korisnikuikritičkiseosvrćunarezultate
vlastitog rada.
Da bi sve to postigli potrebna im je
kombinacija najboljih praksi koje će
upoznati kroz Agile Team Bootcamp.
Ova je usluga skrojena za razvojne
timove koji žele unaprijediti svoj način
rada kroz primjenu tehničkih i metodo-
loških agilnih (najboljih) praksi.
Više informacija na
www.croz.net/consulting

19. P
oslovni zahtjevi u okviru postoje-
ćih servisa i usluga koje Fina pru-
ža, osim uobičajenih razina visoke
raspoloživosti koja se ostvaruje
s redundantnim komponentama u IT
infrastrukturi, podrazumijevaju visoku ras-
položivost servisa i u slučaju ispada iz rada
cijele IT infrastrukture na lokaciji u Zagrebu.
Stoga je u Fini pokrenut niz aktivnosti koji
je za cilj imao izgradnju IT infrastrukture na
pričuvnoj lokaciji radi preuzimanja 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 projekta
Slika 1 prikazuje mainframe infrastrukturu
Fine prije projekta implementacije GDPS
rješenja. Na primarnoj se lokaciji nalaze
dva z9-109 poslužitelja starije generacije
koji rade povezani u parallel sysplex
konfiguraciji. Parallel sysplex je ukratko
konfiguracija koja omogućuje da se dva
ili više mainframe poslužitelja sa z/OS
operativnim sustavima povežu u cluster
kombinaciju i djeluju kao jedan poslužitelj.
Na taj se način s jedne strane ostvaruje
veća procesorska snaga i obradna moć,
dok se s druge strane ostvaruje visoka
raspoloživost. Poslužitelji su spojeni na
enterprise diskovne podsustave između
kojih je uspostavljena replikacija podataka.
Budući da je poslužitelj na DR lokaciji dosta
slabiji od poslužitelja na primarnoj lokaciji,
u slučaju ispada ne može preuzeti sve
servise, nego samo one najnužnije.
Stanje nakonprojekta
Slika 2 prikazuje stanje nakon projekta. Na
primarnoj i DR lokaciji nalazi se po jedan
mainframe poslužitelj spojen na enterprise
diskovni podsustav, a između kojih je
uspostavljena sinkrona replikacija.
Svi se poslovni servisi izvode na
poslužitelju na primarnoj lokaciji.
Poslužitelj na DR lokaciji je manjeg
kapaciteta, ali u slučaju ispada primarne
lokacije automatski se aktiviraju dodatni
kapaciteti računala i on je sposoban
preuzeti sve servise s primarne lokacije.
Izvedba projekta
Projekt je izveden u suradnji s tvrtkama
SV Group i IBM Hrvatska. Implementacija
je realizirana u dvije faze. U prvoj je
Slika1–
Fininamainframe
infrastruktura
prije
implementacije
GDPS rješenja
FYI by CROZ / broj 18 /svibanj 2015. | 19
GDPS u Fini | projektne priče
Implementacija disaster
recovery rješenja u Fini
Piše:
Dejan
Cepetić
Projekt iz naslova jedan je od većih IT projekata koji se u posljednjih
nekoliko godina realizirao u Financijskoj agenciji (Fina) i vrlo je važan za
tamošnju buduću IT infrastrukturu kao i za kvalitetu IT usluga koje Fina
može ponuditi na tržištu. Ponosni smo što smo i kao nositelji projekta i kao
izvođači dijela usluga pridonijeli uspješnoj realizaciji implementacije i time
još jednom pokazali sposobnost odrađivanja velikih enterprise projekata u
domeni sistemske integracije.
Fina - primarna lokacija Fina - DR lokacija
ParallelSysplex
z9-109 z9-109 z900 Tape Unit
ESCON, FICONTape Library
enterprise
storage
enterprise
storage
enterprise
storage
sinkrona
replikacija
asinkrona
replikacija

20. 20 | FYI by CROZ / broj 18 / svibanj 2015.
rubrika | nadnaslovprojektne priče | GDPS u Fini
ZbogčegajeFinaodlučilaimplementiratiGDPS
rješenje?Kojisuglavniciljeviprojekta?
Finajeprijedvijegodinenapravilapričuvnulokacijuu
Zabokujersmohtjeliimplementiratiovakvorješenjekako
bismododatnoosiguralikontinuitetposlovanja.Htjelismo
bitisigurnidanikakvenepredviđenesituacijenećedovestido
ispadasustava,odnosnodausvakomtrenutkusvimnašim
korisnicimajamčimokvalitetnuiod0do24satadostupnu
uslugu.NakonimplementacijerješenjauZabokunapravljeni
sutestovi,prviputnakondugogodinasvisusustavi
kompletnougašenitesuseponovnopodizali.Istotakosu
napravljenitestoviprelaskasvihsustavanapričuvnulokaciju
inakontoganjihovpovrataknasustaveuFinuuVukovarskoj.
Testiranjasuuspješnoprovedena.
Ciljnamjebiodanavisokoraspoloživimsustavimaimamo
našeservisekojisunaraspolaganjukorisnicimaidastvarno
osiguramodasuimdostupniod0do24.
Finajejedanodvodećihpružateljauslugaujavnom
ifinancijskomsektoru,štozakorisnikevašihusluga
predstavljaovounaprjeđenjeinfrastrukture?
Samisukorisnicinašihuslugadobilivećusigurnost,
međutimvažnojenaglasitiidajeFinadobilavećusigurnost
daćesvimsvojimkorisnicimamoćipružitisveštooniočekuju.
KorisnicimajeFinaidosadapružalakvalitetnuidobruuslugu,
asadajesvezajednopodignutonajednuvišurazinu.
PrvistekorisnikGDPSrješenjauHrvatskoj.Jeliono
ispunilovašaočekivanja?Kakvisudaljnjiplanovi?
Svanašaočekivanjasuispunjena.Mislimdasusviuvidjeli
kojejepromjenedonijelaimplementacijaGDPSrješenjau
odnosunadosadašnjirad.Vidimodamožemoinekenaše
internestandardepremainformaticijošpoboljšati,dićinaviši
nivo,štojeupravoovorješenjeomogućilo.Uplanuimamojoš
nekesustaveprebacitiuZabok.Tamovećsadimamoisustave
kojinisuvezanizamainframeimožemorećidasveskuparadi
jakodobro.
Štosetičedaljnjihplanova,namjeranamjejedandio
našihresursaiznajmljivatiidrugimkorisnicima.Nadamoseda
ćekorisnicitunašuprednostiprepoznatisobziromnatoda
smojedniodrijetkihkojiimajupravupričuvnulokaciju.
Kakostezadovoljnisamimprojektom?Jesteli
zadovoljniposlomkojisuobaviliCROZipartneri?
Prilikomrealizacijeprojektanijebilonikakvihproblema.
Zapravo,dosadasCROZ-omnismoimaliproblemanina
kojemprojektu,patakoninaovom.Svisuposloviitestiranja
odrađeniprofesionalnoinavrijeme.Onoštosmoočekivaliod
CROZ-aipartnera,tosmoidobili.
ŽeljkoPavić
Financijska
agencija
(članUprave)
fazi napravljena priprema okoline za
implementaciju GDPS rješenja, dok je u
drugoj fazi izvršena sama implementacija i
testiranje rješenja.
U sklopu pripreme i hardverske i
softverske okoline su prilagođene za
implementaciju GDPS rješenja.
Budući da su prije implementacije z/
OS i z/VM okoline bile raspoređene na
dva stara poslužitelja, potrebno je bilo
napraviti konsolidaciju postojećih okolina
na jedan novi poslužitelj, što je zahtijevalo
opširno planiranje hardverskih definicija.
Nakon definiranja i implementacije novih
hardverskih definicija na novim posluži-
teljima, sve su okoline preseljene na novi
zEC12 poslužitelj. Diskovni su podsustavi
obnovljeni te je time omogućeno korištenje
većeg diskovnog kapaciteta i ostvareni su
preduvjeti za konfiguraciju podatkovne
replikacije između diskova kao jedne od
osnova GDPS rješenja.
Priprema softverske okoline obuhvatila
je podizanje z/OS i z/VM operativnih
sustava na zadnje dostupne verzije
softvera. U osnovi GDPS rješenja je GDPS
control code. Dobra je praksa da se prilikom
implementacije rješenja instalira zadnja
dostupna verzija control codea. Kao
preduvjet za instalaciju zadnje verzije GDPS
koda potrebno je bilo podići z/OS operativni
sustav na verziju 1.13, a z/VM operativni
sustav na verziju 6.2. Kako bi se s novom
verzijom z/OS operativnog sustava
uskladile i verzije ostalih glavnih produkata,
verzija DB2 baze podataka podignuta je
na v10, a verzija WebSphere Application
Servera podignuta je na 8.5.5. Time je i za
Finine aplikativne okoline omogućen razvoj
aplikacija s aktualnim verzijama softvera
kako bi se iskoristile nove funkcionalnosti
koje nove verzije donose.
Implementacija GDPS rješenja odvijala
se u nekoliko koraka. U prvom koraku
odrađene su radionice na kojima su
prikupljene neophodne informacije vezane
uz poslovne ciljeve, servisne zahtjeve,
zacrtane tehnološke smjerove te procese
oporavka poslovnih servisa. U drugom je
koraku detaljno definirana implementacija
rješenja, testna okolina, scenariji testiranja
kao i kriteriji prihvaćanja. Nakon toga je
pokrenuta instalacija potrebnog softvera
zajedno s potrebnim predradnjama:
• pripremljeni su kontrolni z/OS
operativni sustavi
• instalirani su i konfigurirani Tivoli
NetView i Tivoli System Automation
produkti
• instaliran je i konfiguriran GDPS softver.
U sljedećem koraku u testnoj okolini
implementirane su potrebne GDPS funkcije
te definirane veze između trenutačnih
procedura upravljanja sistemima i GDPS
automatiziranim aktivnostima. Nakon
čega je izvršeno testiranje automatiziranog
gašenja i startanja sistema te zavisnih
servisa kao i ostalih GDPS funkcionalnosti.
Nakon zadovoljavajućih testova
pristupilo se implementaciji rješenja u
produkcijskoj okolini.
To je rješenje za Finu od velike
važnosti jer je mainframe označen kao
strateška IT platforma za razvoj novih i
konsolidaciju postojećih Fininih servisa. S
implementacijom tog rješenja omogućen
je brzi oporavak svih postojećih kritičnih
servisa te budućih servisa koji će se
konsolidirati na mainframe platformi.
Slika2–Finina
mainframe
infrastruktura
poslije
implementacije
GDPS rješenja
Fina - primarna lokacija Fina - DR lokacija
ParallelSysplex
zEC12 zEC12
Tape Library
Tape Library
sinkrona
replikacija
Enterprise
disk
Enterprise
disk

21. FYI by CROZ / broj 18 /svibanj 2015. | 21
nadnaslov | rubrikaPeter Eeles | intervju
K
oliko je dizajna u području
softverske arhitekture potrebno
između definiranih zahtjeva
i fizičke implementacije
rješenja? Dizajn softverske arhitekture
rezultira modelom informacijskog
sustava prikazanim kroz perspektive
na različitim razinama apstrakcije.
Isto pitanje možemo postaviti i ovako:
koliko detaljan model i koliko različitih
perspektiva informacijskog sustava
treba kreirati prije same implementacije
rješenja?
Do odgovora treba doći postavljanjem
potpitanja: koja je svrha spomenutog
modela i perspektiva? Informacijski
je sustav složeni sustav u čijoj
implementaciji sudjeluje velik broj
ljudi zaduženih za pojedine aspekte
sustava. Prikaz modela kroz određenu
perspektivu razumljiv je skupini osoba
odgovornim za implementaciju aspekata
prikazanih kroz tu perspektivu. Prije
same implementacije sustava bitno
je postići razumijevanje između svih
osoba odgovornih za implementaciju.
Svrha softverske
arhitektureCROZ-ovo dugogodišnje iskustvo u implementaciji složenih
informacijskih sustava osiguralo nam je i pojedine bitne uloge
u velikim projektima na zapadnom tržištu. Od studenoga 2014.
godine imam priliku raditi kao dio tima u velikoj financijskoj
kući u Velikoj Britaniji koji je zadužen za transformaciju
cjelokupnog procesa dizajna informacijskih sustava i uvođenje
novih alata. Na projektu radim s Peterom Eelesom, svjetskim
autoritetom u području softverske arhitekture, jednim od
dvojice autora knjige “The Process of Software Architecting”.
Iskoristio sam tu priliku kako bih napravio ovaj intervju i
podijelio s vama Peterova razmišljanja o softverskoj arhitekturi.
Iz toga slijedi da je najkraći odgovor na
postavljeno pitanje: potrebno je razraditi
model i kreirati različite perspektive
informacijskog sustava do razine koja će
osigurati konsenzus među svim osobama
odgovornim za implementaciju sustava.
Možeš li nam reći koja je tvoja
trenutačna uloga u IBM-u i nešto o svojoj
karijeri?
Trenutačno sam Executive IT
Architect u IBM Cloud Worldwide Tiger
Teamu. Pomažem klijentima da shvate
relevantnost clouda u njihovu poslovanju
te načine na koje im cloud arhitektura
može pomoći da budu uspješniji. Prije
toga bio sam u sličnoj ulozi u Rational
brendu IBM-a, gdje sam pomagao
organizacijama da nađu bolje načine
razvoja i isporuke softvera. A još prije
toga, vodio sam nekoliko inicijativa s
klijentima, pomažući im da transformiraju
svoj softverski razvoj. Uvijek sam bio i
uvijek ću biti arhitekt!
Kako to da je slika nebodera u izgradnji
izabrana za naslovnicu knjige “The
Process of Software Architecting”, koju si
napisao u suradnji s Peterom Crippsom?
Uz jasnu analogiju softverske i
građevinske arhitekture, simbolika je u
tome da je arhitekt odgovoran za važne
odluke u dizajnu. Arhitekt se obično ne
uključuje u razinu predubokih detalja
(iako će i to učiniti ako je potrebno), ali
osigurava da su svi osnovni elementi
arhitekture na pravom mjestu.
Također bih trebao reći da je analogija
s građevinom prejednostavna, zato što ta
slika prikazuje samo jednu perspektivu,
onu fizičku, i ne prikazuje osnovne 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

22. 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”

23. FYI by CROZ / broj 18 /svibanj 2015. | 23
g*rich | tehnologije i trendovi
T
ko god se primio iole ozbiljnijeg
programiranja u Javi, bar je 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
probleme
Kad je cjelina više od pukog
zbroja dijelova…

24. 24 | FYI by CROZ / broj 18 / svibanj 2015.
okruženjima, ali “to jednostavno nije
to”, “samo čekaš da se sve raspadne”,
“proširivanje funkcionalnosti je noćna
mora” itd. Za ozbiljan posao trebaš i
ozbiljnu platformu. Svi su, dakle, sretni.
Osim programera, jer Java kao platforma
je odlična, Java kao programski jezik baš
i nije.
Java kao platforma je odlična,
Java kao programski jezik baš
i nije.
Ustvari, nije baš da Java kao programski
jezik ne valja, već JVM nudi mogućnost
upotrebe različitih sintaksi, odnosno
na neki način različitih programskih
jezika, a da se sve izvršava na jednoj te
istoj platformi, u istom aplikacijskom
serveru. Od već postojećih jezika i
njihovih “jVarijanti” (jRuby, Jython – da,
Python u Javi) preko posve novih (Scala,
Clojure ili Groovy), nove sintakse donose
moderne programerske trikove, dinamičko
prevođenje i sve što Javi kao programskom
jeziku nedostaje. Brže, lakše, elegantnije,
a sve u poznatom, stabilnom i nebrojeno
puta dokazanom okruženju.
Spomenuti Groovy je upravo takav
jezik. Ako uspijemo zanemariti ne baš
simpatično ime, taj jezik rješava sve
što nas muči s Javom kao sintaksom:
brzo se uči, izvršava se dinamički – ili
statički, ako tako želimo, koncizan je i
elegantan, a povrh svega, integrira se s
Javom bez ikakvih problema. Čovjek se
pita zašto sve to već inicijalno nije u Javi,
ali eto, bar imamo Groovy. Manje linija
koda, jednostavniji izrazi, čitljivije petlje
tehnologije i trendovi | g*rich
i već smo u prednosti, što zbog bržeg
kodiranja, što zbog činjenice da manje
linija koda znači i manje bugova. Groovy se
automatski prevodi u Javu, tako da razlike
u kompatibilnosti nema. Štoviše, Groovy
je od svih alternativnih jezika na JVM-u
najbolje integriran s Javom: bez ikakvih
dodatnih koraka Java zove Groovy, Groovy
zove Javu, Java i Groovy se mogu miješati
u hijerarhiji nasljeđivanja itd. Sve u svemu,
pravi izbor za početak.
Istraživanje Groovyja kao alternativnog
programskog jezika za JVM otvorilo je
vrata onome što danas zovemo g*rich
framework.
g*rich = JVM + Groovy + Grails + Ext
JS + sve između
g*rich, “frejmvork nad frejmvorcima” (u
smislu, frejmvork koji je izgrađen nad
drugim frejmvorcima, ne baš frejmvork
koji je bolji od svih ostalih, iako bi se i o
tome dalo razgovarati), je tipičan produkt
frustracija opisanih na početku priče, s
tim da je danas u jednu ruku lakše jer je
izbor kvalitetnih komponenti odličan, no
istovremeno i kompliciranije jer sve to
treba staviti pod isti šešir, da radi dobro i
stabilno.
Everything great in the world
comes from neurotics.
Marcel Proust
g*rich je nastao kad se moj kolega
Damir Murat, inače smiren i staložen
gospodin u najboljim godinama, zapitao
gore spomenuta pitanja. Kakve su to
tipične poslovne aplikacije i što ne valja u
današnjem razvoju takvih aplikacija? Gdje
se gubi najviše vremena? Što ponavljamo
svaki put, a stvarno ne bismo trebali?
Krenimo od samog početka.
g*rich je integrirano razvojno okruženje
koje uključuje Grails kao web application
framework, Sencha Ext JS kao klijentski
JavaScript framework te, što je najbitnije,
niz posebno razvijenih plug-inova za Grails
i ekstenzija za Ext JS koji, između ostalog,
od tih tehnologija stvaraju međusobno
povezanu, skladnu razvojnu okolinu.
Grails je nevjerojatno moćan framework
za izradu web aplikacija. Napisan je u Javi
i Groovyju i kao takav omogućava sve što
nude ti jezici: radi na JVM-u, vrlo se brzo
nauči koristiti, aplikacije se strahovito
brzo razvijaju i testiraju. Uz sve to, skupa
s Grailsom dolazi i ORM (object-relational
mapper), izvrsna integracija s razvojnim
alatima (Intellij IDEA, Eclipse, NetBeans
itd.), plug-inovi za sve i svašta, razumne
početne postavke okruženja, njeguje se
princip convention-over-configuration
i tako dalje. Odabrati bilo što drugo
osim Grailsa bilo bi na neki način čak i
neodgovorno.
Slično se može reći i za Ext JS. Radi se o
skupu JavaScript, HTML i CSS tehnologija
koje omogućavaju jednostavnu izradu
aplikacija za web i mobilne uređaje. Ext JS
uključuje niz gotovih i u svakoj poslovnoj
aplikaciji očekivanih komponenti pomoću
kojih se razvoj web aplikacija ne razlikuje
od razvoja desktop ekvivalenata. Sam rad
u Ext JS-u je konceptualno puno sličniji
Javi nego JavaScriptu, što je vrlo poželjna
osobina.
Pored navedenih ključnih komponenti,
g*rich objedinjuje i cijeli niz de facto
standardnih biblioteka u svakom
modernom projektu u Javi, ali najzad
usklađeno i bez međusobnih sudaranja.
3, 2, 1 – g*rich!
Da bismo započeli novi projekt, u g*richu
nam je dovoljna jedna naredba i četrde-
setak sekundi vremena. Naredba pokreće
jedan od plug-inova iz g*richa koji na
temelju unaprijed postavljenog predloška
generira inicijalnu verziju aplikacije.
Sve je na svom mjestu: ispravno
postavljena struktura direktorija, osnovne
datoteke već na svom mjestu, testovi gdje
trebaju biti; zatim razvojna baza podataka
s već upisanim testnim podacima,
Za svakog programera u Javi, Groovy je gotovo pa trivijalan za naučiti. Koliko se kodiranje u ta dva jezika
razlikuje najbolje pokazuje sljedeći primjer.
Java:
String postalCode = null;
if (user != null) {
Address address = user.getAddress();
if (address != null) {
postalCode = address.getPostalCode();
if (postalCode != null) {
postalCode = postalCode.toUpperCase();
}
}
}
Groovy:
String postalCode = user?.address?.postalCode?.toUpperCase()
Nevjerojatno, zar ne?

25. FYI by CROZ / broj 18 /svibanj 2015. | 25
g*rich | tehnologije i trendovi
Zapisi se uređuju na istom ekranu. Forme mogu sadržavati vrlo
kompleksne elemente koji, naravno, imaju sve funkcionalnosti
kao i tablice za pregled. Programiranje ovakvih ekrana nije ništa
kompleksnije od standardnih pregleda, a korisnički doživljaj je
značajno poboljšan.
Čemu trošiti riječi kad slike sve pokazuju?
Koliko kompleksne klasične poslovne aplikacije mogu postati
pokazuje i ova slika. Bez dobrog okruženja razvoj ovakvog prikaza
je prava noćna mora. U g*richu to nije nikakav poseban problem.
Nova tema je razvijena prema specifičnim zahtjevima korisnika.
Praćenje životnog ciklusa zapisa u bazi je jedna od onih funkcionalnosti koje ili završe na “nice to have” listi i nikad se ne implementiraju ili dovedu
projekt na rub propasti. g*rich jednostavno ne može dopustiti da se tako bitna stavka zanemari i donosi praćenje povijesti zapisa spremno za
korištenje od samog početka.
osnovna korisnička sučelja za “običnog”
korisnika i administratora (koja su toliko
dobra da se gotovo pa mogu odmah
početi koristiti, samo se upišu stvarni
podaci u bazu), skripte za pokretanje
testnog servera... Predlošci se, naravno,
mogu dodavati ili mijenjati, čak se i bilo
koja radeća aplikacija može pretvoriti u
predložak.
Demo aplikacija koju g*rich automatski
generira uključuje niz upotrebljivih
primjera, od kojih je najzanimljiviji
famozni “šifarnik”, u ovoj ili onoj formi
najčešći oblik poslovnih aplikacija, i to ne
bilo kakav šifarnik! Sve je tu: pametno
pretraživanje podataka, “master-detail
view”, uređivanje podataka...
Šifarnik bez ili šifrarnik s
prvim r? Ovisi koga pitate,
tj. o njegovoj ili njenoj godini
rođenja – prije ili poslije
pojave prvog PC-a. A
Ispod generirane aplikacije se nalazi
jezgra g*richa, koja ustvari predstavlja
srce cijelog aplikativnog okvira u
tehničkom smislu. Tu su sažeti sati i sati
programiranja i peglanja različitih dijelova
frameworka. Bez ove jezgre, g*rich bi
bio samo nakupina odličnih, ali ipak
nepovezanih komponenti. Spomenimo
neke:
Validatori podataka na formama se
najzad implementiraju samo na jednom
mjestu (na serverskoj strani) i automatski
se propagiraju do klijenta. Ponašaju se
onako kako bi i trebali: pokazuju smislene
poruke za pogrešno upisanu vrijednost
pojedinačnog polja, povezanih polja ili
cijele forme.
Podrška za višejezičnost, teme ili
kontrolu pristupa podacima se, naravno,
podrazumijeva.
Za neke mogućnosti koje g*rich
donosi ni ne znamo da su potrebne
sve dok nas surova stvarnost ne opali
po prstima i ne natjera na trošenje
sati i dana na krpanje aplikacije.
Spomenimo samo podršku za OWASP

26. 26 | FYI by CROZ / broj 18 / svibanj 2015.
Top 10 Security ili heartbeat call koji ne
produžuje session (!).
Jesu li šusterova djeca baš uvijek
bosa?
I jedna zanimljivost za kraj: prezentacije
g*richa potencijalnim partnerima su
gotovo uvijek završavale reakcijama
poput: “A gdje ste bili do sada?!” ili “Kad
možemo početi?”. Međutim, na jednom
projektu sam čuo primjedbu: “Dobro, i što
je tu toliko posebno? Pa to je samo brdo
nekakvih biblioteka i tu i tamo poneki
plug-in.” Takva rečenica ne može biti više
u krivu nego što jest. Istina, g*rich neće
od poluzainteresiranih programera koji su
do jučer “čukljali” COBOL stvoriti gurue
razvoja modernih web aplikacija, ali će zato
svakom iole upućenom javašu omogućiti
rad kakvog je htio od prvog dana, a to
znači fokus na poslovni aspekt projekta,
bez petljanja po utrobi frameworka, i sve
to bez gubitka
fleksibilnosti
i bogatstva
različitih opcija
koje razvoj u
Javi donosi. U
slučaju g*richa
ne vrijedi ona
izreka o šusteru
i njegovoj bosoj
djeci. Naime, i
sami ga koristimo
na desetak vrlo
ozbiljnihprojekata
Demo aplikacija “izgleda ko prava i radi ko prava”, samo što nije prava. A Ali zato ima sve elemente
koje prava aplikacija treba imati: kompleksne tablične preglede, mogućnosti direktnog uređivanja
zapisa, prilagodljivo korisničko sučelje. Spojite je na svoju razvojnu bazu i počnite programirati.
Formu nije
moguće spremiti
sve dok svi
podaci nisu
ispravno upisani
OWASP (OpenWeb Application Security Project) je
organizacija koja za cilj ima osvijestiti internetsku
javnost o nužnosti implementacije sigurnosnih
elemenata u web aplikacijama.
OWASPTop 10 Security List je popis
deset najčešćih sigurnosnih propusta u web
aplikacijama, poput XSS-a (Cross-site scripting) ili
ubrizgavanja SQL-a (SQL injection).
g*rich implementira zaštitu od svih
nabrojanih sigurnosnih propusta, odnosno
napada koji iskorištavaju te propuste.
Porijeklo imena g*rich i dan danas ostaje
nepoznanica. Znači li onaj“g”ustvari Groovy,
možda Grails, ili čak“GUI”? Za“rich”je jasno,
bogatstvo komponenti koje stvarno olakšavaju
posao, ali g?
Navodno Grički top sa svojim pucnjem točno
u podne označava kraj radnog dana za korisnike
g*richa, jer su toliko produktivniji da već u podne
mogu na kavu i lagano doma.
I što ona zvjezdica predstavlja u imenu?
Za vas smo razvili dvije aplikacije u našem
g*rich frameworku. Kakva su iskustva
korisnika aplikacija u dosadašnjem radu?
Korisničko iskustvo rada u aplikacijama
napravljenima u g*rich frameworku je jako
dobro. Naime, s aplikacijom Šifrarnici u naše
je korisničko okruženje neprimjetno ušao
potpuno novi, praktičniji sustav za primjenu
kontrola međuovisnosti na administracijski
jako važno mjesto, bazu šifrarnika koju koristi
više sustava Banke. Broj vrsta podataka koji
se administriraju kroz aplikaciju je velik, kao
i broj različitih kontrola koje su primijenjene
po poljima i pojedinim tablicama šifrarnika.
Iako je u našoj struci nemoguće govoriti o
maštovitosti korisnika bez prigodne grimase,
implementacijom ove aplikacije gotovo
smo potpuno onemogućili pogrešne unose,
a korisnici su paljenje kontrola prilikom
pogrešnog unosa proglasili čak i lijepim. A
Kakvi su dojmovi završenih implementacija
u smislu brzine i pouzdanosti? Smatrate li
da je za vas poželjan daljnji razvoj u istom
smjeru?
Vezano uz navedenu implementaciju uistinu
nemam primjedbi, te mogu konstatirati da je
implementacija bilo kojeg novog šifrarnika brza i
bezbolna te da se novi šifrarnici, funkcionalnosti
i kontrole postavljaju i mijenjaju odgovarajućom
brzinom.
MirkoGrbavac
Sberbankd.d.
(Specijalistza
analizu
poslovnih
aplikacija)
tehnologije i trendovi | g*rich
i rezultati su više nego pozitivni, a korisnici
zadovoljniiisporučenimfunkcionalnostima
i vidljivim ubrzanjem isporuka.