FYI UPRAVLJANJE ZAHTJEVIMA. FYI by CROZ. -tema broja- IBM Tivoli Unified Process Composer IBM Maximo Asset Management. Zoran Hrustić, IBM

Transcription

1 FYI FYI by CROZ -Broj 4, lipanj tema broja- UPRAVLJANJE ZAHTJEVIMA IBM Tivoli Unified Process Composer IBM Maximo Asset Management -tehnologije i trendovi- -intervju- Zoran Hrustić, IBM Putopis - Rijad / IBM Rational AppScan / QED konferencija / U šest koraka do Learn@CROZ-a

2 > Uvodnik -Piše: Krešimir Mudrovčić- Nedavno je broj CROZovaca i CROZerica premašio brojku 100. Složit ćete se dobar trenutak za razmisliti o svemu i postaviti samome sebi puno ozbiljnih pitanja. Slično sam se osjećao kada sam navršio trideset. U prvo vrijeme osjećao sam se jako važan samome sebi i mudro razmišljao o ozbiljnim pitanjima. Poslije sam shvatio da se ništa dramatično nije promijenilo i nastavio živjeti normalno. Kasnije sam pak shvatio da se stvari mijenjaju malo-pomalo i da sve promjene u zbroju ipak čine znatnu razliku. I najvažnije: nema natrag! CROZ dakle raste i odrasta. Tema ovoga broja je upravljanje zahtjevima. To je onaj nezgodni dio svakog informatičkog projekta u kojemu mi, informatičari, moramo razumjeti što to vanjski svijet očekuje od nas. Po mogućnosti jasno i precizno. S vremenom smo svi odustali od pokušaja da na početku projekta detaljno preciziramo i stavimo na papir želje i potrebe korisnika, po mogućnosti natjeramo korisnika da potpiše taj papir i onda mirno i spokojno implementiramo stvar do kraja projekta. Naime, korisnički zahtjevi (iz ovih ili onih razloga) uvijek se mijenjaju tijekom projekta. Tako je i nastalo upravljanje zahtjevima. Inače, ovo je proljeće obilovalo novostima u CROZ-u. Otvorili smo edukacijski centar, nominirani smo za finalista nagrade IBM Beacon Award, postali smo IBM-ov Authorized Training Partner... To nas je ponukalo da pokrenemo rubriku novosti. Osobno mi je vrlo drago najaviti intervju sa Zoranom Hrustićem, IBM-ovim direktorom prodaje softvera za područje centralne Europe, Bliskog istoka, Austrije i Švicarske. Ne poznajući osobu, a pročitavši titulu, vjerojatno biste zamislili uspješnog korporacijskog čovjeka koji se bavi prodajom i koji o informatici zna taman toliko koliko treba. Zorana sam upoznao prije dosta godina kao OS/2 gurua i jednog od tehnoloških autoriteta u hrvatskom IBM-u prve polovice devedesetih. Kako to često biva, kasnije se sve manje bavio tehnologijom, a više biznisom. No zadržao je onaj pravi informatičarski način razmišljanja (što vjerojatno ima veze s iskustvom programiranja u asembleru ili nekim sličnim izvornim vještinama) i pokazao se kao vrlo zanimljiv i aktualan sugovornik. Za kraj, otkrit ćemo vam kako nastaje FYI by CROZ! Za početak, morate znati da se FYI priprema po sličnoj recepturi kao i domaći ajvar za zimnicu najvažnije je da sve bude domaće. To znači da su svi autori članaka CROZovci; dakle ljudi koji od ponedjeljka do petka zarađuju informatičarski kruh kuckajući po tipkovnici. Čitatelji, koji su ujedno i naši korisnici, lako će prepoznati autore jer su to istovremeno i ljudi koji alate i metodologije, o kojima pišu, stvarno i implementiraju u svakodnevnim projektima. Svaki broj uređuje drugi urednički dvojac. Kad izaberemo urednike, onda oni odabiru teme i traže autore. Uvijek me oduševljava da je najlakši dio cijelog procesa pronaći autore kandidata je puno i svi su uvijek raspoloženi za pisanje. P.S. Ovdje moramo ispraviti propust u impresumu prethodnih brojeva prvi broj uredila je Vedrana Miholić, drugi su uredili Luka Stepinac i Marko Topolnik, a treći Vedran Vidović i Tomislav Jukić. FYI by CROZ Časopis za informatiku Urednički dvojac: Davor Čengija i Dejan Cepetić Izdavač: CROZ d.o.o. Lastovska 23, 10000, Zagreb, Republika Hrvatska Telefon: Fax: croz@croz.net Grafičko oblikovanje: ebiz d.o.o., Zagreb Tisak: KerschOffset d.o.o., Zagreb 02 FYI by CROZ / broj 4 / lipanj 2008.

3 > Sadržaj Rijad, Kraljevina Saudijska Arabija Uvodnik vijesti Intervju -Zoran Hrustić, IBM: Posegni za zvijezdama kako ne bi ostao u svom dvorištu- Razgovarali smo sa Zoranom Hrustićem, IBM-ovim direktorom prodaje softvera za područje centralne Europe, Bliskog istoka, Austrije i Švicarske. Pročitajte njegova razmišljanja o trendovima u svijetu IBM-ovog softvera, o globalizaciji u informatici kao i o drugim zanimljivim temama. Tema broja -Upravljanje zahtjevima- Upravljanje zahtjevima vrlo je specifična disciplina: različite tehnike prikupljanja zahtjeva, mnogo iskustva, iteracije, pa čak i odgovarajuće znanstvene metode ne jamče da se usred projekta neće promijeniti neki od njegovih ključnih elemenata. Poslovni analitičari su u zaista nezavidnom položaju. Ovaj članak pokušava svakodnevnim jezikom pojasniti upravljanje zahtjevima kao sastavnoga dijela svakog projekta. -Alati za upravljanje zahtjevima- Na koliko smo dosad projekata radili na kojima smo se stalno zapitkivali: Je li nam ovaj zahtjev prijeko potreban? Zašto je sustav implementiran na ovaj način i koje su nam alternative? Koji je utjecaj promjena na postavljene zahtjeve? Ukoliko ste arhitekt ili poslovni analitičar i pitate se kako, možda imamo rješenje za vas... Tehnologije i Trendovi -IBM Maximo Asset Management- U ovom tekstu vas upoznajemo sa vrlo korisnim alatom za upravljanje imovinom. IBM Maximo Asset Management na jedinstvenoj platformi nudi odgovor i izvještaje na brojna pitanja vezana uz upravljanje imovinom koja se javljaju u svakodnevnom radu jedne tvrtke. -IBM Tivoli Unified Process Composer- Kada organizacije kreću u proces dokumentiranja i implementacije najboljih primjera iz prakse za poboljšanje svojih IT servisa, ponajčešće traže savjete i vodilje u ITIL-u. No, ukomponirati ljude, tehnologiju, informacije i procese u jednu cjelinu kojom ćemo poboljšati IT servise i kvalitetnije podržati poslovanje, nije nimalo jednostavno. Pročitajte kako za rješavanje takvog složenog problema može pomoći IBM Tivoli Unified Process Composer. -IBM Rational AppScan- Implementacija sigurnosti u web sustave treba biti sastavni dio procesa razvoja i isporuke softvera. IBM Rational AppScan je alat koji će olakšati, ubrzati i automatizirati vaš proces sigurnosnog i penetracijskog testiranja. CROZ-ovi PUTOPISI Nakon što ste u drugom broju FYI-a mogli pročitati putopis iz Bukurešta, u ovom broju slijedi reportaža iz Rijada, glavnog grada Saudijske Arabije. U šest koraka do Learn@CROZ-a FYI by CROZ / broj 4 / lipanj

4 MEDIJSKI POKROVITELJI

5 > Vijesti CROZ je postao IBM-ov edukacijski partner Tvrtka CROZ postala je ovlašteni IBMov partner za edukaciju za područje Hrvatske IBM Authorized Training Partner (ATP). Kao dio globalne strategije, IBM Hrvatska će od sada izvođenje edukacijskih usluga realizirati u suradnji s odabranim partnerom za edukaciju, tvrtkom CROZ. U praksi to znači da će se tečajevi, kao i do sada, odvijati po globalnim IBM-ovim programima, uključujući edukacijske materijale, a CROZ će preuzeti organizaciju cjelokupne logistike, uključujući instruktore, učionice te računala i opremu. Tečajevi će se održavati u nedavno otvorenom edukacijskom centru Learn@CROZ (Zagreb, Lastovska 23), koji uključuje dvije prostrane i vrhunski opremljene učionice, konferencijsku dvoranu i ugodan lounge-room (više detalja o našem novom edukacijskom centru možete pronaći u ovom broju FYI-a). IBM profesionalna edukacija vodeći je svjetski pružatelj usluga, poznata je po vrhunskoj ponudi edukacije iz područja informatičke tehnologije, ali i šireg područja poslovnih znanja i vještina vezanih uz informatičke projekte. U Hrvatskoj je prisutna već godinama i postala je sinonim za vrhunsku razinu profesionalne edukacije. CROZ u finalu IBM Beacon Award za godinu! U travnju ove godine u gradu Armonk (država New York, SAD) dodijeljene su, za godinu, IBM Beacon Award, nagrade koje se dodjeljuju jednom godišnje, a namijenjene su IBM-ovim poslovnim partnerima iz cijeloga svijeta. Ove je godine tvrtka CROZ nominirana kao finalist u kategoriji Rational Excellence in Software Delivery primjene Rational alata za podršku softverskom razvoju i time je postala prva hrvatska tvrtka koja je dobila ovakvo globalno priznanje. U pitanju je vrlo prestižna nagrada koja je dio IBM-ova PartnerWorld programa i predstavlja veliko priznanje za inovativnost i kvalitetu u primjeni IBM-ove tehnologije i usluga. Nagrada se dodjeljuje u 37 kategorija, a CROZ je bio kandidiran u tri kategorije: 1. Outstanding WebSphere Services Oriented Architecture (SOA) Solution 2. Rational Excellence in Software Delivery 3. Outstanding Industry Solution by an ISV U finalu je u foto-finišu pobijedila tvrtka Sogeti, multinacionalna kompanija sa sjedištem u Parizu koja broji približno zaposlenih. Dobiti ovakvo globalno priznanje velik je uspjeh i čast za jednu hrvatsku tvrtku, u konkurenciji 725 prijava iz cijeloga svijeta, posebice uzevši u obzir da su većina dobitnika nagrade tvrtke koje djeluju na razvijenijim tržištima. CROZ je već ranije dobio status VAP (Value Added Partner) i AITP (Authorized Independent Training Provider) za područje Rational alata, a ova nagrada dolazi kao kruna višegodišnjega kvalitetnoga CROZ-ova rada u području Rational alata. CROZ postao autorizirani partner za IBM WebSphere DataPower SOA Appliances Početkom CROZ je dobio ekskluzivno zastupništvo za IBM WebSphere DataPower SOA Appliances uređaje za bržu i sigurniju obradu i zaštitu XML-a i web servisa, takozvani hardverski ESB. CROZ nudi kompletnu uslugu: implementaciju, konzultacije i podršku za ovaj na tržištu jedinstven uređaj. DataPower uređaji omogućuju ubrzavanje procesiranja, kriptiranja i potpisivanja XML dokumenata, kontrolu pristupa zaštićenim web servisima, temeljenu na sadržaju, broju i učestalosti poziva, te implementaciju Enterprise Service Busa (ESB). Za razliku od softverskih paketa koji se obično koriste pri obradi XML dokumenata, DataPower uređaji imaju ugrađene hardverske elemente za obradu XML podataka zbog čega su brži od softverskih rješenja, a kako ne upotrebljavaju vanjske XML biblioteke, na njih nemaju utjecaja mogući sigurnosni propusti. Uređaji su također u stanju komunicirati i s vanjskim sustavima kao što su baze podataka, MQ ili CICS, te mogu obrađivati čitav niz podataka koji nisu u XML formatu. Prema nekim najavama, DataPower je tek prvi u nizu uređaja koji nude SOA u kutiji. IBM Impact SMART SOA Conference Početkom travnja u Las Vegasu je održana najveća konferencija na temu servisno orijentirane arhitekture, IBM Impact 2008 Smart SOA Conference. Uz prisustvo više od 6000 IBM-ovih klijenata i poslovnih partnera, pa tako i CROZ-a, skup je otvoren na tipično američki showbiz način, uz Cirque du Soleil i dolazak direktora informatike Harley Davidsona na motoru. Konferencija je pokazala da se neke, uglavnom tehnološke teme u SOA-i smatraju apsolviranima, poput messaginga ili Enterprise Service Busa, te da u fokus dolaze metodološke teme (SOMA), upravljanje (SOA Governance), analiza i praćenje poslovnih događaja (business event processing) i prateće tehnologije. Uz svjetske megakorporacije, poput Toyote, Sony Ericssona ili već spomenutoga Harley Davidsona, na skupu je sudjelovala i domaća tvrtka APIS IT. Na okruglom stolu, na temu primjene servisno orijentirane arhitekture u vladinim ustanovama, raspravljalo se o problemima i izazovima u implementaciji. IBM je ovom konferencijom potvrdio vodeću ulogu u svijetu servisno orijentirane arhitekture i predanost razvoju i pojednostavljenju pratećih tehnologija. FYI by CROZ / broj 4 / lipanj

6 > Razgovori / Zoran Hrustić, IBM Posegni za zvijezdama kako ne bi ostao u svom dvorištu Piše: Vedrana Miholić Zoran Hrustić ispričao nam je novosti iz svijeta IBM-ova softvera, dao nam svoj recept za uspješan uspon korporacijskim stepenicama te iznio što misli o perspektivi hrvatske informatike. Sredinom svibnja održana je tradicionalna konferencija IBM Software Days. Otvorenju je prisustvovao i Zoran Hrustić, IBM-ov direktor prodaje softvera za područje centralne Europe, Bliskog istoka, Austrije i Švicarske. Malo je ovako visoko rangiranih menadžera u multinacionalnim IT kompanijama koji potječu iz malih zemalja. Još je manje uspješnih poslovnih ljudi koji su svoje prve menadžerske odluke donosili upravo u Zagrebu. Svijet IBM softvera u zadnjih nekoliko godina doživljava novi procvat i kontinuirano zauzima sve značajnije mjesto u IBM-ovoj ponudi. Dodamo li toj činjenici kratki profil Zorana Hrustića iz uvoda, jasno je da nema bolje osobe za kratku analizu trendova u softverskoj industriji. IBM značajno ulaže u akvizicije softverskih tvrtki. Samo u posljednjoj godini dogodila su se zanimljiva preuzimanja, primjerice Cognosa i Telelogica. Jasna je globalna strategija IBM-a u ovom području, no kako se te promjene doživljavaju u zemljama naše regije? Tri su razloga zašto radimo akvizicije. Prvo, upotpunjujemo svoj portfelj produktima koje u danom trenutku nemamo, a smatramo da za njih postoji prostor na tržištu, te smo svjesni da je akvizicija brža od novoga razvoja. Drugo, tvrtka koju preuzimamo ima tehnologiju koja je možda usko pozicionirana, ali mi procjenjujemo da se radi o tehnologiji koja će biti iznimno značajna u budućnosti. I treće, preuzimamo i tvrtke koje imaju znatan tržišni udio, tj. imaju veliku bazu korisnika, primjerice Cognos ili MicroMuse. S većinom akvizicija bili smo izuzetno uspješni. Kao odličan primjer istaknuo bih MicroMuse, akviziciju staru 3 godine, koja je nadmašila sva naša očekivanja. Na lokalnom tržištu novi će produkti lakše zaživjeti ukoliko je tvrtka koju preuzimamo već prisutna sa svojom partnerskom mrežom. Tada njihove postojeće partnere integriramo u našu partnersku mrežu. Ponekad je dovoljno proširiti vještine naših postojećih partnera, kroz partnersku edukaciju, te na taj način osigurati kvalitetan plasman i implementaciju novih produkata i rješenja. Često i prije akvizicije tvrtka na lokalnom tržištu ima kvalitetan imidž, no nema velik udio. Upravo u tim situacijama IBMova globalna prisutnost i snaga otvaraju mogućnost da kvalitetni produkti pronađu svoje korisnike. IBM-ova softverska ponuda dijeli se u 5 brandova: Tivoli, Websphere, Rational, Information management i Lotus. Svaki brand sigurno nudi svoje novosti i ima svoju strategiju. No čini mi se da se u zadnje vrijeme sve više traže 06 FYI by CROZ / broj 4 / lipanj 2008.

7 > Razgovori / Zoran Hrustić, IBM rješenja koja zahtijevaju kolaboraciju među brandovima, primjerice nadzor IT sustava (Tivoli i Rational), SOA projekti (Websphere, Rational i Tivoli) itd. IBM je oduvijek poznat kao vizionar koja će rješenja, prema Vašem mišljenju, obilježiti idućih nekoliko godina? Trend svakako ide prema tome da se klijenti fokusiraju na rješenja. No još uvijek postoji i potreba za ključnim dijelovima infrastrukture. Naime, korisnici koji su ulagali u baznu infrastrukturu sada prolaze kroz drugi val, u fokusu kojeg je konsolidacija ili usavršavanje aplikativne arhitekture. Upravo u tim situacijama naša SOA priča nailazi na odličan prijem. S druge strane, postoji mnogo korisnika koji imaju potrebu riješiti specifične probleme svojega poslovanja, a tu i jest IBM-ova najveća snaga dugogodišnje iskustvo u rješavanju kompleksnih problema. Naša velika baza specijalista, za primjerice javni sektor, godinama u zemljama regije radi na projektima poput nadzora granica, registracije vozila, pravosudnih i carinskih sustava i sl. U takvim je projektima tehnologija važna, ali ne i ključna. Ključni faktori uspjeha su znanje i iskustvo, koji u spoju s tehnologijom ubrzavaju implementaciju zahtjevnih projekata. No treba dodati da od spomenutih softverskih brandova nećemo odustati. Još uvijek postoje intenzivne potrebe za specifičnim tehnološkim produktima, kao npr. onima za Disaster & Recovery. U drugu ruku, da bi i dalje imali kvalitetne tehnološke stručnjake, moramo u njih ulagati i raditi na njihovim vještinama i znanjima, što su primarni zadaci svakog pojedinog branda. Kad već spominjemo regionalno slične projekte, primjećuje se trend u kojem projekte u Hrvatskoj sve češće odrađuju stranci. Ima li straha za hrvatski IT kruh? Mogu li Rumunji i Poljaci preuzeti poslove koje danas rade naši inženjeri? Churchill je rekao: Optimist u svakoj nevolji otkriva neku mogućnost. Pesimist vidi nevolju u svakoj mogućnosti. Dakle, odgovor na ovo pitanje nije ni da ni ne. No mislim da je neupitan val globalizacije, pogotovo u informatici. To ne znači da će rad otići tamo gdje je najjeftinije, već tamo gdje postoji kompetencija da se posao napravi na najbolji mogući način uz prihvatljivu cijenu. Usporedio bih Hrvatsku po dimenzijama i značaju s Danskom. Danci, za razliku od nas, odrastaju s idejom da su mali i da im je jedina šansa za uspjeh u učenju jezika, kvalitetnom obrazovanju i u tome da ponude nešto novo (odlični su primjeri u dizajnu i prehrambenoj industriji). Jedan moj danski kolega često je spominjao da ga je baka učila Posegni za zvijezdama da ne bi ostao u svom dvorištu. Mi u Hrvatskoj često odrastamo sa stavom da smo najpametniji, što naravno nije točno. Istovremeno, hrvatski inat je velik pokretač. Često to vidim među ljudima koji imaju važne uloge u međunarodnom okruženju. Ta želja za dokazivanjem donosi svoje rezultate. Uz to, Hrvatska ima još jednu prednost nad drugim zemljama bivšeg istočnog bloka. Već godinama živimo u poduzetničkim vodama. Kultura poduzetništva i menadžmenta u nas je bila prisutna već u 70-im, a pogotovo 80-im godinama. To naravno ne smije biti nešto na čemu ćemo graditi uspjeh, već samo prednost koju treba iskoristiti. Ono što je kritično diljem svijeta (pa i u zemljama kao što su Rusija i Pakistan) je nedostatak kvalitetnih kadrova. Velik je broj zemalja, poput Slovačke, koje su plasirale specijalne programe za izgradnju većeg broja informatičkih stručnjaka. Na tome i mi moramo raditi, jer očito broj studenata koji izlaze s tehnoloških fakulteta, primjerice FER-a, nije dovoljan. Hrvatska bi se trebala pozicionirati kroz neku specifičnost i prepoznavati po onom što nudi. Možda se od ostalih zemalja regije možemo razlikovati upravo po spoju iskusnih stručnjaka i kvalitetnih menadžera. CROZ je nedavno postao prvi hrvatski finalist nagrade IBM Beacon Award. Ova IBM-ova nagrada namijenjena je poticanju inovativnosti kod partnera. Saznavši za priznanje, ostali smo zatečeni što smo se našli u krugu odabranih svjetski priznatih tvrtki. Vijest o priznanju koje ste dobili, ugodno me iznenadila. IBM doista posvećuje veliku pažnju zanimljivom i inovativnom pristupu primjena IBM-ove tehnologije. Upravo je to prepoznato u vašem rješenju. Naglasio bih da je IBM izuzetno striktan i ima visoke standarde u ovakvim odabirima, ali i u svim drugim poslovnim praksama. Moram priznati da volim raditi u IBM-u, između ostalog i zbog visokog stupnja poslovne etike kojeg se IBM pridržava. CROZ je odnedavno postao aktivniji u regiji, te smo primijetili da je ponekad lakše stvarati regionalna partnerstva od onih domaćih. Kakva su na tom području iskustva u zapadnim zemljama? Iskustva su poprilično slična, često je lakše svoj kruh podijeliti s onim tko nije toliko blizak domaćem tržištu. Uz to, što je zemlja manja, manje je i kruha koji se dijeli, zato je i borba često okrutnija, a partnerstva rjeđa. No ako želimo dugoročno sagledati situaciju, najbolje se zamisliti u ulozi korisnika. Smatram da će korisnici sve više tražiti partnere koji su jasno profilirani i imaju iskustva za specifične vrste projekata. Vjerujem da će potrebe i želje korisnika natjerati partnere da više rade zajedno, kako bi iskoristili najbolje resurse na tržištu. Ovo me podsjetilo na pitanje koje sam neki dan čuo: A zašto bi morali stalno rasti?. To je odlično pitanje ako zarađujemo dobro, možda zaista i ne moramo rasti. No problem je u konkurenciji koja se neće zaustaviti, te će postupno uzeti naš dio tržišta. Tržište gotovo nikad ne raste tako brzo da bi svi dobili svoj dio. U tom slučaju, izlaz je često konsolidacija. U Hrvatskoj se to već dogodilo u financijskom i telekomunikacijom sektoru, a očekujem sličan scenarij i u našoj industriji. Uspoređujući naše lokalno tržište i ono globalno, recite nam koje su razlike u stilovima upravljanja i kako ste se Vi snašli u regionalnom menadžmentu? Priznajem da sam na početku imao predrasude i vjerovao u Peterov princip. On kaže da se čovjek u hijerarhiji organizacije penje tako dugo dok ne dosegne razinu nekompetencije. U mnogo struktura je zaista tako, a bojao sam se da ni u IBM-u nije drugačije. Neću reći da je IBM savršen, no moje iskustvo pokazuje da iako napredovanje nije lako i potrebno je puno truda, sva su vrata širom otvorena. U IBM-u ne postoji ništa što sprječava one koji žele i koji mogu da na kraju i uspiju. Izuzetno smo aktivni u programima tipa ranog otkrivanja potencijala, čak postoje programi pozitivne diskriminacije, primjerice za žene. Puno smo priznanja dobili upravo za naše vještine upravljanja. Smatram da to dolazi iz kompleksnog poslovanja koje imamo i velikih ulaganja u poslovne vještine. Što se tiče naših hrvatskih menadžera, mogu kao prednost istaknuti komunikativnost i sposobnost stvaranja mreže kontakata, što je u internacionalnom okruženju izuzetno važno. FYI by CROZ / broj 4 / lipanj

8 > Tema broja / Upravljanje zahtjevima Upravljanje zahtjevima ili kontrolirano upravljanje promjenama Pišu: Luka Gauta, Ana Jozić, Aleksandra Bogdan Upravljanje zahtjevima vrlo je specifična disciplina: različite tehnike prikupljanja zahtjeva, mnogo iskustva, iteracije, pa čak i odgovarajuće znanstvene metode ne jamče da se usred projekta neće promijeniti neki od njegovih ključnih elemenata. Poslovni analitičari su u zaista nezavidnom položaju. Ovaj članak pokušava svakodnevnim jezikom pojasniti upravljanje zahtjevima kao sastavni dio svakog projekta. Definirati problem, ali i problem iza problema Osnovna su pitanja kod izgradnje novoga sustava: Zašto gradimo novi sustav? Koje probleme želimo riješiti? Koji je izvorni problem od kojeg sve počinje? Analizom trenutačnog stanja dolazimo do određenog broja faktora koji su pridonijeli krajnjem problemu te ih možemo vizualno lijepo prikazati u obliku fishbone dijagrama. Nakon što smo utvrdili koji su razlozi našega problema, treba odrediti koji je od njih najviše utjecao na nedostatke u radu. Taj ćemo problem pokušati riješiti jer je on najvažniji i njegovim rješenjem ćemo, direktno ili indirektno, riješiti i ostale. Ne treba rješavati sve krize jer ćemo stvoriti klupko koje nećemo moći razmrsiti i sigurno ćemo se naći u situaciji koja će nas koštati i vremena i novca. Da bismo odredili koji je problem prioritet u rješavanju, možemo se poslužiti i znanstvenom metodom. U obliku Paretova dijagrama prikažemo čimbenike našeg problema i nakon što odredimo koji od njih nam je neprijatelj broj 1, krećemo dalje. Analiza problema je dio samog procesa upravljanja zahtjevima i može se odraditi prije ulaska u projekt, kako bi se procijenila isplativost projekta, ali je i dio prve faze upravljanja zahtjevima. Zato formuliramo izjavu o problemu: na koga utječe i kako ga rješavamo. Izjavu prosljeđujemo svima na uvid i nakon povratne informacije i ispravaka / nadogradnje definicije problema, spremni smo. upravljanja zahtjevima jest analiza problema (Analizirati problem). Cilj je ove aktivnosti postizanje međusobnog razumijevanja svih strana uključenih u projekt, prije početka samoga razvoja sustava. Razumijevanjem korisnikova problema započinje i razumijevanje korisničkih zahtjeva. Faza se sastoji od nekoliko koraka: identifikacija stakeholdera (interesnih strana), razumijevanje osnovnih uzroka problema, dobivanje suglasnosti o definiciji problema, identifikacija ograničenja sustava, validacija rješenja te definiranje granica rješenja. Prihvaćanje definicije problema kod svih strana je važan korak u analizi jer Ključni pojmovi omogućava identif ikaciju ograničenja sustava koja mogu ozbiljno ugroziti uspješnost projekta. Ograničenja se pojavljuju u mnogo oblika, a mogu biti političke, tehničke, gospodarske i sistemske prirode, ovisno o području djelovanja korisnika. Identificiranjem najboljeg mogućeg rješenja, odnosno onog koje rješava osnovne uzroke i podupire poslovne ciljeve, te završavanjem faze analize, definiranjem i pojašnjenjem granica Stakeholder - interesna strana, osoba ili osobe koje su pogođene problemom i imaju koristi od njegova rješavanja, odnosno od isporučenoga sustava. Stakeholder request - zahtjev interesne strane o željenom stanju unutar domene rješenja sustava. Requirements Management - proces upravljanja korisničkim zahtjevima. Feature - eksterno uočljiv servis pomoću kojeg sustav zadovoljava jedan ili više zahtjeva interesnih strana. Functional requirement - zahtjev koji, iz perspektive crne kutije, određuje kako rješenje komunicira s vanjskim svijetom. Non-functional requirement - zahtjev koji, iz perspektive crne kutije, izražava kvalitativne osobine rješenja. Constraint - ograničenje dizajna sustava ili procesa koji se koristi u izgradnji sustava. Actor - osoba, hardverski uređaj ili drugi sustav koji koristi Traceability - sposobnost opisivanja i praćenja zahtjeva. To improve is to change; to be perfect is to change often. Winston Churchill Faze u procesu upravljanja zahtjevima Kako bismo izgradili pravi sustav na ispravan način, sa što manje preinaka i popravaka, u procesu upravljanja zahtjevima potrebno je slijediti određenu sekvencu aktivnosti (workflow). Prva aktivnost od koje kreće proces Prikaz područja problema i područja rješenja 08 FYI by CROZ / broj 4 / lipanj 2008.

9 > Tema broja / Upravljanje zahtjevima sustava postavlja se rješenje problema koje određuje inicijalni opseg projekta. Osim granica projekta, koje mogu biti različite ovisno o aktorima koji će koristiti sustav, važno je utvrditi i terminologiju koja će se koristiti na projektu i voditi ju u posebnom dokumentu, Rječniku. U ovoj fazi važno je i sve prikupljene informacije dokumentirati i strukturirati u Viziji, dokumentu koji sadrži informacije dobivene iz aktivnosti analize problema i predstavlja korisnički pogled na sustav koji će se izgraditi. Idući korak u procesu upravljanja zahtjevima može se okarakterizirati kao lista želja interesnih strana, kao primarni input u definiranju Use Caseova i dodatnih zahtjeva, a odnosi se na razumijevanje njihovih potreba (Razumjeti potreben interesnih strana). Ključni zadatak jest otkrivanje zahtjeva interesnih strana i utvrđivanje zahtijevanih osobina sustava u izgradnji. Iako se čini kao trivijalan zahvat, ovaj korak krije mnoge prepreke do kojih dolazi u kontaktu s korisnikom. U tradicionalnom pristupu razvoja korisničke specifikacije zahtjeve se pokušava oblikovati od prve, što gotovo uvijek rezultira neuspjehom. Projektni zastoji pojavljuju se uglavnom na dvije razine. Prvo, zbog različitih perspektiva sudionika projekta - korisnici žele riješiti sve probleme brzo, analitičari misle da razumiju u potpunosti što -Prikaz tijeka procesa upravljanja zahtjevima- -Dubravka Lukić, direktorica informatike i organizacije, Volksbank d.d.- -Voditeljica projekta razvoja aplikacije za kreditni hod- Uspostava projekta i početak razvoja Aplikacija za kreditni hod (LWA) razvijana je na bazi inicijalnih funkcionalnih specifikacija pripremljenih od strane Volksbanke. CROZ-ovi analitičari predložili su od početka svoju metodologiju (RUP), nama dotad nepoznatu. Mi smo tu metodologiju prihvatili prepoznavši njezinu kvalitetu. Uskom suradnjom CROZ-a i poslovnih korisnika budućega sustava, detaljno su razrađivane pojedine funkcionalnosti u obliku Use Caseova. Svaki Use Case nastajao je kroz nekoliko iteracija, a tek kada su obje strane (VB, CROZ) bile suglasne, krenulo se u razvoj. Nisu razvijani svi Use Caseovi odjednom, već su prvo odabrani poslovno i arhitekturno najkritičniji, kako bi se što prije otkrili mogući problemi oko integracije s postojećim sustavima (aplikacija LWA integrirana je s ključnim poslovnim sustavima VB Hrvatska i VB grupacije). Zahtjevi za promjenama i prijave problema Čim su prve funkcionalnosti implementirane i predane na testiranje, uspostavljen je formalni proces upravljanja promjenama i problemima. Svi zahtjevi vode se kroz centralni repozitorij (alat Rational ClearQuest), te su kategorizirani kao problem ili zahtjev za promjenom/novom funkcionalnošću, s dodatnim atributima kao što je npr. prioritet. Nakon prijave, CROZ-ovi djelatnici evaluiraju zahtjev, te ukoliko se radi o problemu, preuzimaju problem (mi automatikom dobivamo obavijest), pristupaju rješavanju problema, a kroz ClearQuest vidimo i status problema te rješavamo eventualna dodatna pitanja. Zahtjev za promjenom ili novom funkcionalnošću ima sličan životni ciklus, s tom razlikom što CROZ-ovi arhitekti prvo procjenjuju potrebno vrijeme za implementaciju, VB potvrđuje (ili odbija), te se proces nastavlja dalje kao i kod prijave problema. Ovakav način rada, iako iziskuje dosta truda i angažmana, pokazao se kao vrlo efikasan. Sve faze razvoja su transparentne, a u svakom se trenutku vrlo brzo može utvrditi status samoga projekta. FYI by CROZ / broj 4 / lipanj

10 > Tema broja / Upravljanje zahtjevima -Zvonimir Križ, PBZ, glavni koordinator u Direkciji aplikacija- -distribucijskih kanala- U PBZ-u smo organizirani po programima koji su u osnovi skupine funkcionalno povezanih projekata. Upravljanje zahtjevima i vremensko planiranje se radi na razini programa, dok se upravljanje korisnici žele, a programeri vjeruju da oni imaju najbolje rješenje i drugo, zbog prirodne zakonitosti konstantne promjene koja utječe i na zahtjeve korisnika. Nakon što primijenimo neke od tehnika prikupljanja zahtjeva te nakon njih dopunimo Rječnik i Viziju, dolazimo i do prvog skiciranja Use Case modela te prelazimo na aktivnost definiranja sustava (Definirati sustav). Svrha ove aktivnosti leži u usklađivanju projektnog tima u razumijevanju sustava koji se gradi, izvođenju analize prikupljenih zahtjeva interesnih strana na visokom nivou te formalnom dokumentiranju rezultata kroz modele i dokumente. Opisivanjem osobina sustava prvi put se opisuju softverski zahtjevi, pri čemu moramo voditi računa o svim odlikama koje želimo da sustav koji gradimo posjeduje, npr. stabilnost, točnost i sl. Softverski zahtjevi opisuju se i dokumentiraju pomoću Use Case modela, koji se sastoji od aktora i Use Caseova. Četvrta aktivnost odnosi se na upravljanje opsegom sustava (Upravljati opsegom sustava) i uključuje definiranje resursa, proračuna i vremena potrebnih za izvođenje projekta. Svrha je usklađivanje korisnikove želje s onim što developeri mogu isporučiti u zadanom vremenskom roku, zbog čega je jako važno dobiti promjenama uglavnom spušta na razinu pojedinog projekta. Poslovni sektori i IT zajednički usuglašavaju specifikaciju buduće funkcionalnosti. Rezultat tih aktivnosti je detaljna Use Case specifikacija date funkcionalnosti. Po završetku formalnog usuglašavanja kreće se u IT analizu, dizajn i implementaciju. U svrhu upravljanja promjenama nad postojećim funkcionalnostima ustanovili smo i Odbor za upravljanje promjenama, koji se redovito sastaje te vrednuje i formalno odobrava sve pristigle zahtjeve. Svi zahtjevi potom završe u issue trackeru, koji je jedino referentno mjesto za status zahtjeva. Također, kroz taj sustav su vidljive sve prošle i buduće verzije projekata, odnosno aplikacija, kao i veza pojedinih zahtjeva na konkretne promjene u kodu. Vrlo smo zadovoljni ovakvim pristupom upravljanju zahtjevima i promjenama. korisnikovu potvrdu o skupu osnovnih osobina sustava u izgradnji. Upravljanje opsegom projekta, na način da zadovolji dostupne resurse, ključno je u vođenju uspješnoga projekta. Idealno je vrijeme za provođenje ovog koraka nakon definiranja korisničkih zahtjeva, a prije usavršavanja definicije sustava. Najvažnije je držati se svih ugovorenih ciljeva i vremenskih rokova, definiranih resursa i proračuna projekta. Usavršavanje definicije sustava (Obnoviti definiciju sustava) u procesu upravljanja zahtjevima bavi se detaljnim opisom tokova izvođenja Use Caseova, upotpunjavanjem dodatnih specifikacija te, ako je potrebno, razvojem specifikacije softverskih zahtjeva. Budući da se zahtjev definira kao sposobnost ili stanje koje sustav mora zadovoljiti, softverski zahtjevi predstavljaju svojevrsnu crnu kutiju u definiciji sustava i definiraju eksterno vidljive osobine sustava. Zahtjevi kao što je npr. zahtjev da sustav bude razvijen u programskom jeziku Java, u ovoj fazi obrađuju se kao ograničenje dizajna. Problem koji se ovdje javlja jest dilema oko toga kako razlikovati zahtjev od dizajna, odnosno kako napisati zahtjev koji govori kako nešto napraviti bez uplitanja načina na koji se to može napraviti. Rješenje nije jednostavno i ovisi o određenim ulogama u procesu. Funkcionalni zahtjevi prikazuju aktivnosti koje sustav treba izvršiti, opisuju način na koji sustav reagira na određene ulaze te detaljno opisuju kako će se sustav ponašati u određenim situacijama. Ograničenja koja se nameću sustavu u odnosu na aktivnosti i funkcije koje obavlja, kao što su vremenska ograničenja, ograničenja u razvojnom procesu, standardi i sl., predstavljaju nefunkcionalne zahtjeve. Funkcionalnost sustava specificira se iz Use Caseova i deklarativnih izjava iz Vizije. Neke funkcionalne zahtjeve teško je izraziti u kontekstu Use Casea, oni mogu biti navedeni deklarativno u dodatnim specifikacijama. Primjerice, zbog lokalizacije može se pojaviti zahtjev da poruke korisniku moraju biti prikazane na jeziku koji on može sam izabrati. Ovaj zahtjev može se provući kroz korake svakog Use Casea kada se prikazuje ova poruka i za koji se u scenariju može napisati sljedeće: Sustav obavještava korisnika da odabere jedan od ponuđenih jezika. Drugo rješenje je napisati jednu deklarativnu rečenicu u dodatnim specifikacijama koja će se odnositi na ovaj zahtjev za cijeli sustav. Aktivnost koja se javlja tijekom cijeloga procesa upravljanja zahtjevima, i opisuje kao najveći izazov softverskom timu, odnosi se na upravljanje promjenama zahtjeva (Upravljanje zahtjevima za promjenom). Promjene zahtjeva su česta i prirodna pojava, zakonitost koja se ponavlja u tijeku trajanja projekta. Mogu se javiti iz više razloga poboljšanje shvaćanja problema, promjena definicije problema tijekom vremena, propusti u postavljanju pravih pitanja odgovarajućim osobama, promjena korisnikove percepcije problema, promjena vanjskog okruženja Upravljanje promjenama zahtjeva nameće se kao ključ uspjeha projekta. Moderni procesi softverskog inženjerstva zagovaraju iterativni pristup životnom ciklusu sustava: određeni skup zahtjeva usavršava se tijekom životnog ciklusa. Takvo konstantno usavršavanje uključuje aktivnu kontrolu zahtjeva koja se podržava odgovarajućim alatima za dokumentiranje, organiziranje, praćenje i preispitivanje promjena. Promjene zahtjeva većinom imaju destabilizacijski učinak na razvoj projekta, mogu rezultirati promjenom završnog cilja, prekoračenjem proračuna te probijenim rokovima, zbog čega je nužna čvrsta i disciplinirana strategija upravljanja promjenama zahtjeva. Tehnike i prakse upravljanja zahtjevima Postoji nekoliko tehnika za upravljanje 10 FYI by CROZ / broj 4 / lipanj 2008.

11 > Tema broja / Upravljanje zahtjevima zahtjevima, a njihova je najveća prednost da se ne isključuju, već se pažljivom i usmjerenom kombinacijom mogu razotkriti svi zahtjevi, kako oni kojih smo svjesni, tako i oni za koje nismo znali da uopće postoje. Intervju je svakodnevna, jednostavna i direktna tehnika, ali se mora imati na umu da je to interaktivna aktivnost za koju se treba dobro pripremiti, a ne obično postavljanje pitanja. Uvijek je poželjno otkriti nove zahtjeve prikupljanjem trenutačno poznatih, jer će to biti od velike pomoći pri upravljanju neminovnim promjenama. Radionice (workshops) su jedna od najmoćnijih tehnika prikupljanja zahtjeva, gdje su sve interesne strane na jednom mjestu, u kratkom ali intenzivnom interaktivnom vremenskom periodu. Ponekad je, ovisno o situaciji, korisno imati neovisnog voditelja radionice, osobu koju ne poznaje nijedna interesna strana. Tako će se indirektno pojačati autoritet te osobe unutar radionice. Brainstorming jest najvažniji dio radionice, koji uključuje opće generiranje i redukciju ideja. Kreativne ideje često proizlaze iz kombinacije mnogobrojnih, na prvi pogled nepovezanih ideja. Nakon popisivanja ideja, određuje se njihov prioritet. Storyboarding čine prezentacije zamišljenog rješenja, mogu biti pasivne, aktivne ili interaktivne, a svrha im je da se uz predstavljanje rješenja otkriju i skriveni zahtjevi. Jedan i jedini: Use Case! Tehnika koja se koristi u softverskom inženjerstvu za konstrukciju funkcionalnih zahtjeva sustava naziva se Use Case i dio je Use Case (UC) modela. Svoje podrijetlo ima u tehnici modeliranja korisničkih zahtjeva unutar objektno-orijentiranog (OO) razvoja softvera. Use Case dijagrami jedan su od 12 tipova dijagrama definiranih UML specifikacijom i opisuju ponašanje sustava u odgovoru na zahtjev koji potječe izvan tog sustava, odnosno interakciju između aktora i sustava prikazanu kao slijed koraka. Aktori mogu biti krajnji korisnici, drugi sustavi, ili dio hardvera, koji postoje izvan sustava u izgradnji, nisu njegov dio, a sudjeluju u komunikaciji sa sustavom. Svaki Use Case potpuni je niz događaja opisanih s aktorova gledišta. Razlikujemo osnovni i alternativni tok, odnosno tekst koji nam prikazuje korake u komunikaciji aktora i sustava. Use Case model sastoji se od Use Case dijagrama te tekstualnog opisa svakog Use Casea. Početak strukturiranja UC modela najbolje je inicirati u trenutku kada se konfigurira set zahtjeva koje korisnik razumije i koje je odobrio, odnosno u procesu definiranja sustava. Prvi koraci odnose se na identificiranje aktora uz kratak opis, skiciranje svakog Use Casea s osnovnim i alternativnim tokom izvođenja, dok se u kasnijem stadiju razvoja sustava detaljno opisuju i strukturiraju tokovi izvođenja te se uključuju dodatni zahtjevi, poslovna pravila, preduvjeti, rezultirajuća stanja, podatkovni skup i kontrole kod unosa te poruke u aplikaciji. Use Caseovi poboljšavaju komunikaciju u procesu otkrivanja i opisivanja funkcionalnih korisničkih zahtjeva. Ostale prednosti su: zbog teksta i dijagrama razumljiviji su svim stakeholderima, pomažu u otklanjanju povećavanja opsega sustava identificirajući granice sustava te pomažu u izbjegavanju preranog dizajna sustava fokusirajući se na ono što sustav treba raditi, a ne kako. Zadnje navedeno omogućava arhitektima i developerima slobodu u odlukama o dizajnu i tehnologiji implementacije -Marina Čizmar, HGK, pomoćnica direktora Centra za informatiku i statistiku Uspostava projekta i početak razvoja Hrvatska gospodarska komora i tvrtka CROZ već dulji niz godina surađuju na razvojnim projektima u sklopu Biznet inicijative Hrvatske gospodarske komore. Biznet je isporučitelj sustava poslovnih informacija čiji su korisnici djelatnici i članovi Komore te sva zainteresirana javnost. U sklopu sustava Biznet razvijane su aplikacije koje nisu imale pandan na tržištu pa je kreativni proces specificiranja nastajao u kući, a dokumentirali su ga djelatnici CROZ-a iz Odjela za poslovnu analizu. Kako smo digitalizirali neke poslovne procese koji su srž našeg poslovanja, proces prepoznavanja i analize procesa prethodio je svakom razvoju. Dokumentirali smo ga koristeći RUP metodologiju, a specifikacije budućih sustava pisali smo kao Use Caseove, što je umnogome olakšalo finaliziranje našega kreativnog procesa, kao i vizualizaciju budućega sustava. Zahtjevi za promjenama i prijave problema Kako je sustav Bizneta rastao te nudio nove aplikacije i nove poslovne informacije, raslo je i njegovo prihvaćanje kao osnovnog sredstva za rad mnogim djelatnicima Komore. Kroz svakodnevno korištenje naših sustava, Poslovni subjekti, Burze roba, Burze otpada, Karneti, Komorski doprinosi, pojavljivale su se želje za proširivanjem funkcionalnosti, izmjene funkcionalnosti, kao i potreba za ispravcima nedostataka. Biznet je, kao centralni subjekt u isporukama ovih promjena, prikupljao sve zahtjeve korisnika, djelatnika i članova Komore, te ih kanalizirao prema djelatnicima tvrtke CROZ. Za prijavu zahtjeva koristimo web bazirani alat koji dopušta kategoriziranje i prioritiziranje prijavljenog zahtjeva i otvara direktnu komunikaciju između djelatnika CROZ-a i Bizneta. Zahtjev se prati od otvaranja do zatvaranja, a u mjesečno izvještavanje uvrštavaju se svi realizirani zahtjevi za izvještajni period. Kvartalno, Biznet i CROZ prioritiziraju zahtjeve koje Biznet prikuplja od korisnika ili koji nastaju kao rezultat kreativnoga procesa promišljanja sustava poslovnih informacija. Tako prioritizirani zahtjevi vode se u zasebnoj dokumentaciji i rješavaju prema kategorijama prioriteta, opet prateći životni ciklus zahtjeva kroz web bazirani sustav. Korištenje sustava za praćenje zahtjeva zaista olakšava dnevni rad, a kvartalno reprioritiziranje osigurava nam da smo uvijek u tijeku s aktualnim potrebama i ažurni prema zahtjevima naših korisnika, te stalno imamo u vidu i širu strategijsku sliku. FYI by CROZ / broj 4 / lipanj

12 > Tema broja / Upravljanje zahtjevima -Prikaz Use Case dijagramasustava, bez nepotrebnih ograničenja funkcionalnih zahtjeva. U kasnijoj fazi razvoja sustava Use Caseovi služe kao podloga za izvođenje funkcionalnih test-caseova mapiranjem osnovnih i alternativnih tokova izvođenja u podatke za testiranje. Osim ovih prednosti, Use Caseovi su moćno sredstvo za inkrementalni i iterativni razvoj softvera jer relativno lako prate promjene korisničkih zahtjeva tijekom životnog ciklusa sustava. U slučaju presloženosti zahtjeva za pisani govorni jezik, postoji velika vjerojatnost nerazumijevanja napisanih specifikacija. Tada se možemo poslužiti tzv. tehničkim metodama za specificiranje zahtjeva, kao što su pseudokôd, modeli krajnjih stanja (finite state machines), tablice ( stabla ) odluke, modeli povezanosti entiteta (entity relationship), te dijagrami aktivnosti (activity diagrams). Svaki od ovih prikaza izuzetno je logičan promatraču, ali isto tako može biti neupotrebljiv zbog eventualnog nepoznavanja sastavnih termina pojedine tehničke metode. Upravljanje zahtjevima ili možda upravljanje promjenama? Tradicionalni modeli procesa razvoja softvera su tzv. vodopadni model (waterfall) i spiralni model. U vodopadnom modelu aktivnosti slijede logički kroz sekvencu koraka, gdje svaki korak temelji početak svojeg izvršavanja na izlazima i aktivaciji iz prethodnoga koraka. Možemo odmah uočiti potencijalni problem: ne možemo napredovati u razvoju dok nam naš prethodnik ne da zeleno svjetlo. U spiralnom modelu razvoj se temelji na generiranju serije rizičnih prototipa koji se detaljnije obrađuju da bi se dobio krajnji rezultat. Glavna prednost ovoga pristupa jest mogućnost mnogobrojnog feedbacka od strane korisnika koji bi trebali izvući skrivene zahtjeve što ranije u procesu razrade. Iterativni model najbolje opisuje sljedeća dobro nam poznata slika, gdje su na jednom mjestu objedinjene faze, iteracije i discipline. Iterativni pristup uzima najbolje prakse iz tradicionalnih modela, te ga u stvari možemo smatrati hibridom prethodno spomenutih modela. Naravno da i on pridonosi sa svojim novotarijama. U tradicionalnim modelima razvoja, aktivnosti izvođenja (analiza, dizajn, implementacija ) bile su sekvencijalno poredane, dok je u ovom slučaju omogućeno da se tijekom brojnih iteracija aktivnosti izvršavaju slobodnije, a sve u svrhu stabilnijeg, sigurnijeg i boljeg krajnjeg rješenja. Slično spiralnom modelu, tijekom svake iteracije uklanjaju se prisutni rizici u tom trenutku faze aktivnosti razvoja. U fazi incepcije poslovni tim se fokusira na razumijevanje poslovnih Use Caseova, opsega projekta i načina implementacije. Problem se analizira, definiraju se preliminarne procjene rasporeda i budžeta, kao i faktori rizika. U fazi elaboracije definiraju se zahtjevi sustava, uspostavlja se arhitektura, te se razvijaju i demonstriraju jednostavni prototipi. Nakon toga slijedi faza konstrukcije, gdje je fokus na implementaciji, a arhitektura i dizajn se u potpunosti razvijaju. Zadnja faza je tranzicija, u kojoj se obavlja testiranje i sve aktivnosti koje podrazumijeva puštanje u rad. -Zlatko Varga, PBZ, direktor Direkcije mainframe tehnologije- Upravljanje zahtjevima za promjenama sistemske infrastrukture IT-a PBZ-a (sistemski SW i HW) definirano je dokumentima: 1. Poslovnik rada Odbora za produkciju, u kojem je opisano na koji se način radi završna provjera i daje suglasnost za zahvate. 2. Smjernice zahvata na produkciji, u kojem su opisane aktivnosti vezane uz provedbu zahvata. Ukratko, bilo koji zahtjev za instalacijom zakrpa, novih releasea i verzija, promjenom parametara sistemskog SW-a, zamjenom ili dogradnjom postojećeg HW-a i implementacijom novog IT sustava u Banci (sistemski SW i HW) implementira se na način: zakrpa, release, verzija, parametri ili novi sustav obvezno moraju biti uspješno provjereni u razvojno-testnoj okolini obavlja se simulacija produkcijskog rada na simulacijskoj okolini analizira se utjecaj na sve usluge koje su direktno povezane sa zahvatom na sistemskoj infrastrukturi te se također analizira međuovisnost i utjecaj na sve ostale usluge i dijelove informacijskoga sustava svi izvršitelji koji rade na implementaciji zahtjeva detaljno su upoznati s planom provedbe Helpdesk odjel IT-a unaprijed je obaviješten i upoznat s provedbom zahvata i mogućim problemima koji mogu zadesiti korisnike klijenti Banke i interni korisnici (djelatnici Banke) obaviješteni su o radovima na IT sustavu prije provedbe samoga zahvata izrađena je i/ili ažurirana dokumentacija Nakon ispunjenja navedenih uvjeta planirani zahvat prijavljuje se Odboru za produkciju (koji sačinjavaju predstavnici svih organizacijskih dijelova informatike PBZ-a). Nakon analize na sastanku Odbora, i provjere dodatnih uvjeta (detaljno razrađen provedbeni plan, ažurirane procedure za disaster/ recovery, pravilno odabrano vrijeme provedbe zahvata i slično), članovi Odbora daju suglasnost ili odbijenicu za implementaciju u produkcijski rad. Po okončanju implementacije radi se provjera svih usluga. 12 FYI by CROZ / broj 4 / lipanj 2008.

13 > Tema broja / Upravljanje zahtjevima Unutar svake faze obavljaju se iteracije koje predstavljaju sekvencu aktivnosti, koje su planirane i koje imaju definirane kriterije odobrenja nastavka o kojima ovisi i njihova mnogobrojnost. Aktivnosti su organizirane kao discipline, od kojih se svaka sastoji od logički povezanog skupa aktivnosti koji je slijedno definiran u svrhu generiranja određenog artefakta (ili radnog produkta). Zahtjevi u iterativnom modelu Prednosti iterativnog pristupa, iz perspektive upravljanja promjenama, su: bolja je prilagodljivost promjenama zahtjeva, jer model prepoznaje da su promjene zahtjeva i aktivnosti zahtjeva aktivne kroz cijeli životni ciklus proizvoda, a ne samo na početku bolje je upravljanje opsegom u smislu definiranja funkcionalnih i nefunkcionalnih zahtjeva zbog velikog broja iteracija, jer učimo iz svake iteracije i reguliramo opseg po rezultatima prethodne. Važno je primijetiti da trenutak u životnom ciklusu novog proizvoda, kad se određena aktivnost pojavljuje, nije fiksan i predodređen, već se aktivnosti zahtjeva mogu nadograđivati tijekom vremena, kako raste i naše razumijevanje krajnjeg proizvoda koji stvaramo. Upravljanje promjenama Ako se sjetite neprijatelja broj jedan s početka priče, možemo reći da smo u ovom poglavlju taj neprijatelj mi sami. Još se nije rodio, tko bi svakom ugodio pa koliko god se trudili da budemo taj ekstrem, korisnije je uložiti tu snagu u -Safenet faze, discipline i iteracije RUP-a- pripremu za nadolazeću situaciju, a to je promjena. Promjenu ne možemo zaustaviti, ali se možemo pripremiti utoliko da možemo upravljati njome kad se pojavi. Proces upravljanja promjenama koristan je samo u slučaju da prepozna i definira predmet promjene. Promjena je prirodni čimbenik svakog procesa i ona će zasigurno nastati pod utjecajem raznih unutarnjih i vanjskih čimbenika, te je stoga bitno osigurati plan/proces upravljanja promjenama. Zato što prije postanite svjesni da je potreba za promjenom neizbježna, i planirajte to. Koristite sustav kontrole promjena da bi opazili promjene. Osigurajte jednoznačni kanal komunikacije prema sustavu kontrole promjene i kad dođe vrijeme, upravljajte promjenom hijerarhijski. Na promjenu mogu utjecati vanjski i unutarnji čimbenici te je poželjno da se ne nađemo u beskonačnoj petlji ne znajući upravljaju li nam zahtjevi dizajnom rješenja ili novi dizajn zahtjevima. Faktori se, bilo unutarnji ( Nismo pitali prava pitanja prave ljude u pravo vrijeme! ) bilo vanjski (promjena okruženja, promjena mišljenja korisnika ), dobro pripremljenim pristupom problemu ipak mogu minimizirati. Minimizirati, ali ne i potpuno ukloniti, jer pogreška je, makar i sićušna, kao i promjena, neizbježna. -Mario Kljusurić, FINA, direktor službe potpore--- Upravljanje zahtjevima u Sektoru komunikacijsko-informacijskih tehnologija u FINA-i odrađuje se primarno kroz proces upravljanja promjenama koji je uspostavljen početkom godine. Prva faza počinje od jedinstvenog mjesta prijave, tj. RFC-a (Request for Change), unutar kojega onaj koji zahtijeva promjenu mora navesti sve ključne podatke vezane uz promjenu, a minimalno vrstu promjene (hitna, redovna...), utjecaj promjene na krajnje korisnike, te opis promjene i pripadnu dokumentaciju. Druga faza procesa jest analiza zahtjeva od strane tima (CAB Change Advisory Board), koji se sastoji od change managera i osoba koje CM, ovisno o zahtjevu, uključuje u tim. Nakon analize slijedi autorizacija, planiranje implementacije, sama implementacija te na kraju puštanje u produkciju izmjene i time provedba realizacije zahtjeva. Osim zahtjeva koji se realiziraju kroz upravljanje promjenama, odvojeno se tretiraju servisni zahtjevi koji mogu, ali ne moraju, prerasti u promjenu te se rješavaju ili kroz opisani proces upravljanja promjenama ili kroz proces upravljanja incidentima. Uspostavljeni procesi su u skladu s ITILom, svjetskim standardom za upravljanje IT servisima. FYI by CROZ / broj 4 / lipanj

14 > Tema broja / Alati za upravljanje zahtjevima Zahtjevi integrirani u razvojnu okolinu -Piše: Darko Benšić- Na koliko smo dosad projekata radili na kojima smo se stalno zapitkivali: Je li nam ovaj zahtjev prijeko potreban? Zašto je sustav implementiran na ovaj način i koje su nam alternative? Koji je utjecaj promjena na postavljene zahtjeve? Došla nam je MDD metodologija gdje egzistiraju različite vrste modela koje možemo povezati s repozitorijem zahtjeva i u svakom trenutku razvojnog procesa revidirati aktivnosti. Ukoliko ste arhitekt ili poslovni analitičar i pitate se kako, možda imamo rješenje za vas... Uvertira Na isti zahtjev krajnji korisnik, projekt manager, poslovni analitičar, programer ili administrator, po prirodi posla, ne moraju uvijek gledati na identičan način. Iz tog se razloga arhitekti i dizajneri sustava često nalaze u nezahvalnoj poziciji jer moraju napraviti pravovaljani balans između korisnikovih često nerealnih zahtjeva na jednoj strani te programera i administratora na drugoj, a pritom moraju pažljivo birati tehnologije i metode implementacije. Stoga metoda detekcije (ne)ispravnih zahtjeva i (ne) implementacija zahtjeva trebaju biti vrlo jednostavne i učinkovite. Također nije za zanemariti i korisničko sučelje, koje bi trebalo biti integrirano s njihovim primarnim razvojnim sučeljem, koje se mora uklapati u perspektivu arhitekta i programera. Zahvaljujući IBM Delivery Platformi, koja se temelji na Eclipsu, plavi div daje nam dobru podlogu za integraciju IBM Rational alata pisanjem raznoraznih dodataka (plugina) s kojima možemo povezati alate na odgovarajuće načine. Jedan od njih je i RequisitePro plugin koji sa sobom donosi zasebnu Eclipse perspektivu pod nazivom Requirement, namijenjenu ažuriranju podataka o definiranim zahtjevima i Use Caseovima. RequisitePro dodatak (plugin) dolazi zapakiran u Software Architect, Rational Data Architect, Rational Modeler, WebSphere Bussines Modeler i dr. alate. U nastavku ćemo kratko opisati integraciju RequisitePro alata s dvije IBM-ove uzdanice: Rational Software Architect (RSA) i Rational Data Architect (RDA). Međutim, prije nego spomenemo mogućnosti koje dolaze sa spomenutom integracijom, spomenimo i osnovni alat ili metodu stručno nazvanu traceability. Traceability Iz perspektive projekt managera traceability daje uvid projekt manageru odgovaraju li svi elementi sustava definiranim zahtjevima, a iz perspektive requirement managmenta, traceability povezuje zahtjeve s elementima modela obuhvaćajući pritom sve potrebne informacije (atribute) za razumijevanje zahtjeva. U praksi traceabilityjem nadgledamo (mjerimo) kvalitetu sustava i zrelost razvojnoga procesa. Već nekoliko godina na svjetskom IT tržištu postoje alati s kojima možemo mjeriti kvalitetu sustava ili zrelost procesa koji razvijamo, a u takve spada i naš junak IBM Rational RequisitePro, koji posjeduje traceability shemu s bogatim setom opcija prikazanim krajnje jednostavnom formom. RequisitePro posjeduje podršku za nadgledanje zahtjeva: ujedinjavanjem pisanih dokumenta sa spreadsheetom ili bazom podataka daje dobar sustav za monitoring zahtjeva. U tako automatiziranom procesu usko grlo predstavlja održavanje i podjela odgovornosti, vezano za ažuriranje informacija o statusu zahtjeva. Između poslovnog analitičara, dizajnera i programera na dobro vođenom projektu mora postojati pravovaljani balans. U suprotnom, kao i u svakom nediscipliniranom sustavu, nastaje kaos, a time i kašnjenje isporuke proizvoda, što svi želimo izbjeći. Da bi se to izbjeglo, programerima, arhitektima, DB administratorima, poslovnim analitičarima, projekt managerima i svim ostalima aktivnim jedinkama u razvojnom procesu moramo omogućiti jednostavnu i upotrebljivu okolinu. Analitičarima je izazov održavati informacije o artefaktima u sustavu, gdje svaki artefakt (Use Case, data structure...) ima svoju reprezentaciju i semantiku, te zbog toga način integracije ovih alata ima važnu ulogu u razvojnom ciklusu. Ukoliko ne povežemo artefakte direktno između analitičara i implementatora sustava (arhitekt, programer ili DB administrator), i ne omogućimo ažuriranje istih u stvarnom vremenu, dovodimo u pitanje Eclipse Element Proxy Ključni pojmovi Stakeholder - interesna strana, osoba ili osobe koje su pogođene problemom i imaju koristi od njegova rješavanja, odnosno od isporučenoga sustava. Requirements Management - proces upravljanja korisničkim zahtjevima. Feature - eksterno uočljiv servis pomoću kojeg sustav zadovoljava jedan ili više zahtjeva interesnih strana. Traceability - sposobnost opisivanja i praćenja zahtjeva. konzistentnost praćenja artefakata, što je jedan od glavnih neprijatelja Requirements Managmenta. Model Driven Development metodologija postavlja nove zahtjeve ispred traceability alata, koji mora biti u stanju raditi s različitim modelima, kao što su modeli poslovnih procesa, modeli podataka, modeli softvera i testova. IBM na ovaj izazov odgovara adutom nazvanim Eclipse Element Proxy, koji se učahuri kao zasebni paket u RequisitePro projektu i primarni mu je cilj raditi traceability s različitim tipovima elementa modela, npr. Use Case aktorima, klasama ili entitetima logičkoga podatkovnog modela. Plavo-zelena integracija zahtjeva i modela U Requirement perspektivi možemo povezati zahtjev s elementom modela brzo povlačeći artefakt između pregleda. Također, u mogućnosti smo upravljati atributima modela kao što su prioritet i status. Funkcionalnost koja se najčešće koristi, traceability, naznačuje ovisnost i daje nam uvid koliko uspješno odgovaramo definiranim zahtjevima. 14 FYI by CROZ / broj 4 / lipanj 2008.

15 > Tema broja / Alati za upravljanje zahtjevima Osim pregleda i povezivanja artefakata, iz ove perspektive možemo mijenjati nazive i sadržaj artefakta, te napraviti sinkronizaciju artefakata temeljenih na poslovnim pravilima koja možemo definirati i po potrebi ih mijenjati. U svakom trenutku možemo unutar perspektive pregledavati dokumentaciju zahtjeva pisanu u Word dokumentu koja se nalazi u RequisitePro repozitoriju, te na taj način u par sekundi pregledati tekstualni opis, atribute i sl. Requirement perspektiva sastoji se od pet pregleda dijelova: 1. Requirement Explorer unutar ovog pregleda otvaramo i šetamo kroz RequisitePro projekt. 2. Requirement Trace unutar ovog pregleda možemo vidjeti trenutačno aktivnu vezu između zahtjeva i pridruženog mu elementa. Veza može biti definirana kao TO, FROM ili SUSPECT. 3. Requirement Link Problems unutar ovog pogleda imamo popis i lokaciju pogrešno povezanih elemenata, ukoliko je nastao problem prilikom povezivanja. 4. Requirement Query Results na ovom pregledu vidimo rezultate traceabilityja koji može biti definiran u obliku matrice ili stabla. 5. Link Clipboard vrlo koristan pogled na označen element, tj. na element koji povezujemo sa zahtjevom. Povezivanje zahtjeva i UML modela Jedna od primarnih zadaća RSA je modeliranje softvera, a jedna od funkcionalnosti alata za modeliranje je i analiza modela. Model možemo analizirati iz perspektive zahtjeva koristeći Requirement perspektivu koja arhitektu omogućava pregledavanje i upravljanje Use Case i class modelima, te elemente takvog modela povezati s točno definiranim zahtjevima. Najzanimljivija Poslovni analitičar skuplja, klasificira zahtjeve te određuje prioritete i najpotrebnija opcija u Requirement perspektivi je opcija Requirement traceability, kojom istražujemo zahtjev koji ovisi o jednom ili više drugih zahtjeva. Kada se definiraju traceability relacije, možemo otkriti može li nam se element modela, njegovo podrijetlo ili međusobna ovisnost usmjeriti i prema točno određenom indikatoru. Npr. možemo povezati zahtjev featurea s Use Case zahtjevom. U tako definiranom primjeru u budućnosti možemo sigurno pretpostaviti da će se mijenjati poslovna pravila, te da će tada vjerojatno doći do promjene zahtjeva tijekom projekta. Ukoliko se dogodi promjena zahtjeva, poveznica nam jasno naznači novo stanje, suspect, što nam na vizualno prihvatljiv način govori da moramo doraditi ili Use Case ili zahtjev. Povezivanje zahtjeva s podatkovnim modelom Rational Data Architect (RDA) alat je primarno namijenjen data arhitektima. U Model Driven Development okruženju veliku ulogu ima logički podatkovni model koji apstrahira stvarni model u kojem čuvamo podatke. Logički podatkovni model u RDA možemo transformirati iz poslovnog procesa ili reverse engineeringom iz postojeće strukture ili iz UML class dijagrama. Ako uzmemo u obzir da svaki model možemo ažurirati tijekom razvojnog ciklusa u nekoliko iteracija, rezultat takve dinamičke i česte promjene modela vrlo se lako može negativno odraziti na projekt, te se vrlo lako može dogoditi da se zaboravi implementirati neki vrlo važan element ili da nam neki element na modelu ostane neažuriran, tj. nekompatibilan s ostalim elementima modela. Integracijom RequisitePro i RDA alata dajemo arhitektu, koji razvija domenski, logički ili fizički model, mogućnost povezivanja zahtjeva analitičara, a time i krajnjeg korisnika sa svakim elementom na modelu. Povezivanjem elemenata modela sa zahtjevima analitičara, a samim time i korisnika, dobivamo moćan alat za uvid u stanje implementacije iz perspektive razvoja, što znači da analitičar i/ili projekt manager mogu u svakom trenutku vidjeti u kojem se statusu nalazi projekt, promatrajući ga iz perspektive zahtjeva, FYI by CROZ / broj 4 / lipanj

16 > Tema broja / Alati za upravljanje zahtjevima Arhitekt otvara RequisitePro projekt i povezuje elemente modela s dodijeljenim zahtjevima ili kreira novi zahtjev iz postojećeg elementa dok arhitekti koji modeliraju sustav mogu traceati zahtjeve te primijetiti jesu li implementirani svi potrebni elementi u razvojni model. Poslovni analitičar često nije u mogućnosti prepoznati, primijetiti i definirati sve potrebne elemente u logičkom modelu, stoga osoba koja modelira može iz svog omiljenog razvojnog sučelja kreirati zahtjev. Takav zahtjev analitičar u istom trenutku može uočiti te dalje obrađivati. Također, ukoliko se dogodi propust, previd ili postavljanje nepotpunog modela na produkciju, tada traceanjem fizičkog modela možemo vidjeti je li propust nastao u definiranom zahtjevu analitičara, korisnika ili je pogreška možda nastala prilikom dizajna modela. I na kraju... Zahvaljujući Requirement perspektivi, koja dolazi s gotovo svakim alatom koji je dio Rational Delivery platforme, razvojni tim može na interaktivan način upravljati zahtjevima, ukoliko se za upravljanje zahtjevima na projektu koristi RequisitePro alat. Koristeći spomenutu Requirement Query Results View prikazuje rezultat traceanja u obliku matrice ili stabla Izvori: integraciju, arhitekti se oslanjaju samo na svoj dio posla i, što je najvažnije, gledaju na zahtjeve iz svoje perspektive: softver arhitekt sa svojim Use Case modelima, data arhitekta s logičkim, domenskim ili fizičkim modelima, te poslovni analitičar sa svojim poslovnim modelima (procesima). Integracija RequisitePro projekta i Rational Delivery platforme vrlo je jednostavna i odvija se u nekoliko klikova mišem. Pregledi se gotovo neprimjetno integriraju te arhitektu modela ne daju ni najmanju mogućnost da se odvoji od svog primarnog pogleda na model, što je svakako pohvalno. Najveći neprijatelji u radu sa zahtjevima su konzistentno korištenje i ažuriranje postojećeg stanja nakon inicijalnog kreiranja zahtjeva. Spomenuti neprijatelji uvelike ovise o savjesti svakog pojedinca u razvojnom ciklusu na koji alat kao takav ne može puno utjecati, ali može pojednostaviti korištenje, što je svakako uspjelo IBM-u s Requirement perspektivom. Poslovni analitičar pokreće trace operaciju i primjećuje što je implementirano u data model Tijek povezivanja Pridruživanje zahtjeva elementima modela: 1. Analitičar ili projekt manager, koristeći RequisitePro, definira novi projekt. 2. Koristeći RSA ili RDA arhitekt otvara RequisitePro projekt u Requirement perspektivi te proučava zahtjev na temelju kojeg razvija novi model (UML, LDM...), koji se reflektira na točno određeni zahtjev. 3. Arhitekt povezuje RequisitePro zahtjev s elementima na modelu da bi točno naznačio koji zahtjev zadovoljava točno određeni element na modelu. 4. Nakon što arhitekt poveže sve zahtjeve s elementima modela, programeri koriste UML model ili DB administratori logički model kao podlogu za razvoj kôda ili deployment fizičkog podatkovnog modela. Pridruživanje zahtjeva elementima modela na postojećem modelu (reverse engineering): 1. Analitičar ili projekt manager koristi RequisitePro i kreira ili modificira zahtjeve za već postojeći model. 2. Arhitekt koristi RSA ili RDA i otvara RequisitePro projekt u svom razvojnom okruženju koristeći Requirement perspektivu, te u njoj povezuje postojeće elemente modela s unesenim zahtjevima ili dodaje nove elemente modelu. 3. Arhitekt modificira model kako bi dizajn pratio promjene nad elementima modela. Također arhitekt nad tako povezanim elementima može raditi analizu utjecaja zahtjeva nad modelom, te na taj način eliminirati moguće razlike između napisanih zahtjeva i ažuriranoga modela. 4. Nakon promjena na dizajnu programer ili DB administrator može modificirati postojeći kôd ili refaktorirati bazu. 16 FYI by CROZ / broj 4 / lipanj 2008.

17 > Tehnologije i trendovi / IBM Maximo asset management Upravljanje imovinom -Piše: Tomislav Majdančić- Potrebno je naručiti opremu za obavljanje određenih funkcionalnosti tvrtke. Koje je stanje pojedine opreme na skladištu? Koji se dobavljač preferira za određenu opremu? Koji su ostali dobavljači? Koje su ponude najpovoljnije? Kakvo transportno vozilo je potrebno? U kakvom je stanju to vozilo? Kakvo je stanje spremnika s gorivom u transportnom vozilu? Tko je odobrio narudžbu opreme? Ovo su samo neka pitanja u svakodnevnom funkcioniranju tvrtke. IBM Maximo na jedinstvenoj platformi nudi odgovor i izvještaje na ova i mnoga druga pitanja. Čemu upravljanje imovinom? Svako moderno poslovanje, bez obzira na djelatnost, ovisi o ključnim faktorima (critical asset) za obavljane svakodnevnih poslova, bez obzira radi li se o sredstvima transporta, sredstvima za proizvodnju, računalnoj opremi Briga o tim sredstvima (engl. asset) je krucijalna, jer imaju izrazit utjecaj na produktivnost i profitabilnost korporacije. Kompanije su uglavnom bile primorane oslanjati se na raznolika softverska rješenja zbog različitih tipova sredstava. Takva rješenja pružala su samo djelomično praćenje u odnosu na sva sredstva kompanije, što je otežavalo prepoznavanje mogućnosti poboljšanja učinka. IBM Maximo Asset Management (Maximo AM) diže upravljanje imovine na potpuno novu razinu. Razvijen na jedinstvenoj softverskoj platformi, pruža iscrpan uvid u sve tipove sredstava, proizvodnju, objekte i transport kroz vašu kompaniju. Ovakav kompletan pregled imovine pruža mogućnost uočavanja neiskorištenih potencijala unutar sredstava. Dugogodišnje iskustvo razvilo je duboko razumijevanje za unikatne probleme prilikom upravljanja imovinom u raznim djelatnostima. Kako optimizirati upravljanje imovinom? Analiza skladišta: Koliko se često pojedini dijelovi koriste? Koliko je kritična svaka pojedina komponenta? Koliko to košta? Koliko je pouzdan indirektan sustav nabave? Gdje koristimo kritična sredstva? Kolika je Vaša zamjena za svaki dio? Možete li unaprijed planirati potrebe? Analiza sredstava: Na koji su način vaša sredstva prioritetna? Koliko se često kvare? Što se najčešće kvari i zašto? Možemo li smanjiti ili ukloniti kvarove? Kako možemo unaprijediti performanse sredstava? Koliko je novca utrošeno u popravak/ zamjenu? Analiza nabave: Koliko Vas dobavljača snabdijeva? Koliki im dohodak ostvarujete? Možete li konsolidirati dobavljače? Možete li postaviti dogovor o cijenama? Kako se pojedini dobavljač odnosi (na vrijeme, kvalitetu )? Analiza i planiranje rada: Koliko praznog hoda inženjeri imaju? Jesu li ljudski resursi propisno kvalificirani? Jesu li radni nalozi odrađeni u skladu s predviđenim vremenom? Koja je kvaliteta odrađenog posla? Radi li pravi djelatnik pravi posao? Dakle, analizom inventara smanjujemo zalihe, analizom sredstava povećavamo performanse i smanjujemo vrijeme ispada, analizom nabave reduciramo troškove nabave i smanjujemo cijenu inventara, a analizom i planiranjem rada optimiziramo raspodjelu ljudskih resursa prema poslu. Kako sve to radi Maximo? Maximo na ovo pitanje odgovara sa šest ključnih rješenja za upravljanje: Assets, Work, Services, Contracts, Materials i Procurement. Ova rješenja sa svojim funkcionalnostima u potpunosti pokrivaju sve što je potrebno za optimizaciju i upravljanje sredstvima i pripadajućim servisima. U nastavku ćemo Vam probati približiti neke od glavnih funkcionalnosti kako biste stvorili sliku zašto je upravo Maximo AM cjelovito rješenje za upravljanje imovinom. Arhitektura Maximo alata Šest ključnih rješenja za upravljanje FYI by CROZ / broj 4 / lipanj

18 > Tehnologije i trendovi / IBM Maximo asset management Upravljanje sredstvima Asset Management Ova komponenta Maxima je sveobuhvatni sustav koji posjeduje sve potrebne kontrole kako bi s lakoćom pratili upravljanje sredstvima kroz cijeli njihov životni vijek. Detalji o pojedinom sredstvu sadrže lokaciju, povijesno praćenje utrošenog vremena i resursa kroz vrijeme, te se samim time maksimizira produktivnost i produljuje vijek sredstva. Hijerarhija lokacije i opreme dozvoljava nam raspodjelu troškova kroz sustav i lokacije, što pruža cjelovit uvid u troškove sredstava. Nadzor stanja sredstva pruža mogućnost proaktivnog upravljanja, čime se smanjuje reaktivno upravljanje i neplanirano vrijeme ispada. Ukratko, Maximo pruža mogućnost poboljšanja performanse i iskoristivost svih sredstava unutar kompanije. Upravljanje radom Work Management Podržano je planirano i neplanirano djelovanje na održavanju, od inicijalnog zahtjeva preko generiranja radnog naloga, sve do izvršavanja i evidentiranja obavljena posla. Planeri posla mogu se podudarati s radnim zadacima (job task mogućnost da se unutar Maxima definiraju standardni radni zadaci, predviđeno vrijeme za odrađivanje, te razina vještine potrebnog tehničara) kako bi potrebni resursi bili dostupni, procjenjivanje i odobravanje potrebnih troškova, postavljanje prioriteta te pokretanje djelatnosti održavanja kroz organizaciju. Alati za praćenje omogućuju detaljnu analizu utrošenih resursa, materijala i opreme, kako bi se smanjili utrošak materijala i rada. Grafičko upravljanje dodijeljenim zadacima optimizira utrošak rada te se brine da je prava osoba s pravim kvalifikacijama određena za posao. Time izbjegavamo učestale probleme nedovoljno kvalificiranih tehničara za određeni posao ili pak pretjerano kvalificiranih tehničara, jer nepravilna raspodjela ljudskih resursa donosi dodatne troškove u poslovanju. Postavljanje funkcionalnosti preventivnog održavanja (PM Preventive Maintenance) smanjuje neplanirane ispade i reaktivno održavanje. Upravljanje servisima Service ManagEment Upravljanje servisima omogućuje korisniku da unese novi servisni zahtjev (Service Request), te također omogućuje praćenje i ažuriranje postojećih zahtjeva. Sa servisnom podrškom možete implementirati ITIL smjernice za incidente, probleme, change i release management za visoko kvalitetne i cijenom niske Service Desk operacije. Prilikom pružanja usluge može se koristiti SLA (Service Level Agreement) i Performance Monitoring kako bi se uskladili ciljevi i prioriteti na najbolji način podržavajući cjelovite ciljeve poslovanja. Upravljanjem incidentima i problemima poboljšava se praćenje procesa s ciljem rješavanja korisničkog problema brže i povoljnije. SLA monitoring proaktivno nadzire SLA metriku kako bi se izbjegli nedostaci u service level obavezi. Upravljanje eskalacijama omogućava pravilno upravljanje resursima kako bi se ispunile service level obaveze. Bitna komponenta također je i Listener, koji služi za generiranje servisnih zahtjeva direktno iz elektronske pošte. Upravljanje ugovorima Contract Management Iscrpan sklop funkcionalnosti pruža kompletnu kontrolu nad ugovorima s dobavljačima te podržava nabavu, davanje u najam, unajmljivanje, jamstva, procjenu posla, glavne i korisnički definirane ugovore. Ugovori se s dobavljačima povezuju Service Level Agreementima (SLA) kako bi se lakše identificirali nepouzdani dobavljači i proizvodi nezadovoljavajuće kvalitete, te pružila mogućnost referenciranja na SLA metriku učinkovitosti prilikom ponovnog ugovaranja uvjeta dobavljanja. Automatska izvješća i upozorenja pomažu nam u praćenju uvjeta dobavljača, čime izbjegavamo penale te izvlačimo najveću moguću vrijednost od svakog ugovora. Izradom vremenskoga plana podržano je praćenje plaćanja, čime se smanjuju administrativni troškovi i učvršćuje odnos s dobavljačem. Upravljanje materijalima Materials Management Cilj ove komponente Maxima je da zna sve što, kada, kako, koliko, koliko dragocjeno o materijalima vezanim za sredstva i njihovoj uporabi. Upravljanje materijalima bilježi sve transakcije pružajući uvid u stanje materijala u realnom vremenu. Optimizacija skladišta i funkcionalnost planiranja postavlja ispravan nivo skladišta, ispunjavajući zahtjeve održavanja, brinući da su pravi dijelovi dostupni, na pravim lokacijama kada su potrebni, smanjujući time količinu robe na skladištu, veličinu skladišta i cijenu prenošenja robe. Upravljanje nabavom Procurment Management Podržane su sve faze dobavljanja unutar organizacije, uključujući i direktnu kupovinu potrebnih sredstava i nadopunjavanje skladišta. Ove mogućnosti informiraju kupca o zahtjevu, ponudama, dobavljačima, narudžbama i podacima iz ugovora, omogućujući time proaktivno planiranje. Također se ove mogućnosti lako integriraju s proizvodima treće strane kao što su SAP ili Oracle. Work Management 18 FYI by CROZ / broj 4 / lipanj 2008.

19 > Tehnologije i trendovi / IBM Maximo asset management Maximo IT Service Management Količina imovine koja je na brizi IT odjela rapidno raste. Od poslužitelja, mrežne opreme, prijenosnika, radnih stanica, preko niza mobilnih uređaja, sve šireg spektra računalnih periferija, do softverskih licenci. Posao upravljanja tom imovinom nije više isključivo pitanje instalacije i tehničke podrške. Imovinu vrijednu milijune kuna potrebno je upravljati s aspekta financija, optimalne nabave, ugovora s dobavljačima, efikasne inventure i pravovremenog održavanja kroz cijeli životni vijek imovine. Upravo iz gore navedenih razloga, na osnovi Maximo EAM, nastao je Maximo IT Service Management, prilagođen IT djelatnosti. Naravno da fizički unos podataka svih IT sredstava nije nimalo jednostavan i brz posao. Maximo Discovery alat, koristeći računalnu mrežu, identificira fizičku lokaciju uređaja i pruža reviziju korištenog softvera. Ovakav pristup može značajno smanjiti uloženo vrijeme i novac u kreiranju i održavanju IT sredstava, jer omogućava vremensko planiranje automatizirane provjere inventara, pružajući precizne, najnovije informacije. Prilagodljivost postojećim sustavima U današnjem svijetu tvrtke zahtijevaju sustav koji omogućuje suradnju unutar njihove tvrtke, te s njihovim partnerima i klijentima. To zahtjeva integraciju više poslovnih sustava unutar tvrtke, te integraciju s eksternim sustavima partnera i klijenata. Ključ interoperabilnosti između sustava je korištenje određenih standarda, što automatski pruža veću agilnost IT sustava. Tehnologije i standardi kao što su SOA, Web services, J2EE, XML, LDAP i SSO olakšavaju interoperabilnost, konzistentnost i upravljivost. Također Maximo se s ERP-om integrira koristeći zajedničko upravljanje skladištom ove tehnologije i standardi pružaju izbor između proizvoda i dobavljača, ne ograničavaju klijenta na jednu platformu, aplikacijski set ili stil u programiranju. Maximo software nastao je na ovim standardima. Nastao kompletno na JAVA 2 Enterprise Edition (J2EE ) Internet arhitekturi, Maximo se lako integrira u većinu postojećih poslovnih sustava. Maximo interoperability framework pruža integraciju infrastrukture baziranu na servisno orijentiranoj arhitekturi (SOA). Ugrađena integracijska komponenta, Maximo Enterprise Adapter, omogućava bržu integraciju s enterprise poslovnim sustavima. Koristeći opsežan izbor predefiniranih integracijskih točaka, pruža kompletno integracijsko okruženje Maximo softverom. Zaključak Vrijeme je učestalih promjena u političkom sustavu, ekonomiji, relacijama među institucijama, tehnologiji, očekivanju korisnika i drugdje. Cilj nam je ne samo pratiti promjene koje nastaju, nego i prednjačiti u istim. U protivnom, dolazimo u opasnost da zaostajemo i ne budemo pripremljeni za budućnost. Odlika dobrog sustava za upravljanje imovinom je ta da nam pruža spoznaju što posjedujemo, vrijednost imovine, što je potrebno učiniti za unaprjeđenje, krajnja dostignuća od različitih ulaganja, različite akcije koje odrađujemo na sustavu i sve djelatnike koji su uključeni u upravljanje sustavom. Za to nam je potreban integrirani fokus, sustav baze podataka, alat za inženjersku i ekonomsku analizu, potrebna nam je metodologija koja razumije taj sustav! Moderno poslovanje gotovo je nezamislivo bez kvalitetnog i cjelovitog sustava za upravljanje imovinom. Došlo je vrijeme sustava za upravljanje imovinom, a IBM Maximo Asset Management je upravo jedan od lidera na ovom tržištu! Maximo industrijska rješenja Prilagođavajući se tržištu IBM Maximo pruža cijeli niz gotovih rješenja za određene djelatnosti: Maximo Industry Solution for Government je specijalizirano rješenje namijenjeno državnoj upravi. Maximo Industry Solution for Life Sciences pomaže u nadzoru opreme, objekata, mobilnih i IT sredstava na jedinstvenoj platformi, a rješenje je usklađeno s FDA standardom (21CFR part 11). Maximo Industry Solution for Nuclear Power jedinstvena je platforma za upravljanje produkcijskom opremom, objektima, transportima i IT sredstvima. Maximo Industry Solution for Oil and Gas je također prilagođeno rješenje kao i prethodna, te pruža najbolju praksu za upravljanje naftnom kompanijom. Maximo Industry Solution for Service Providers pomaže kod upravljanja sredstvima za više korisnika u jednoj instanci. Maximo Industry Solution for Transportation pruža tvrtki najbolja rješenja u ovom sektoru poslovanja upravljajući striktnim regulativnim zahtjevima kako bi produžio životni vijek sredstava, optimizirao upravljanje rezervnim dijelovima te smanjio broj poziva s ceste. Maximo Industry Solution for Utilities podržava upravljanje kompletnim radom i svim sredstvima za prijenos i distribuciju u djelatnosti vodovoda, plina i električne energije. FYI by CROZ / broj 4 / lipanj

20 > Tehnologije i trendovi / IBM Tivoli Unified Process Composer Dirigent ITIL filharmonije -Piše: Bojan Koprivčić- Kada organizacije kreću u proces dokumentiranja i implementacije najboljih primjera iz prakse za poboljšanje svojih IT servisa, ponajčešće traže savjete i vodilje u ITIL-u. No, ukomponirati ljude, tehnologiju, informacije i procese u jednu cjelinu, kojom ćemo poboljšati IT servise i kvalitetnije podržati poslovanje, nije nimalo jednostavno. Organizacije u pravilu znaju definirati što treba napraviti, no ne osiguraju detaljno objašnjenje kako i tko će to napraviti. Tako i najbolje ideje i namjere često padaju u vodu na pitanju Tko je, dovraga, trebao odraditi taj posao?. Umjesto da počnete od nule, iskoristite alat za brzo dokumentiranje u praksi dokazanih procesa. Uvod Dulje mi je vrijeme bila pomalo mutna uloga dirigenta orkestra klasične glazbe ili filharmonije. Svaki član filharmonije zna besprijekorno odsvirati, po notama, bilo koju partituru, bilo koje djelo. Zašto je onda dirigent toliko važan i na kraju pobere najviše slave za uspješnu izvedbu, kada to sami glazbenici mogu odsvirati i bez njega? Ne tako dobro ugođeni orkestar Nedavno sam imao priliku gledati intervju s jednim poznatim dirigentom u kojem je postavljeno pitanje koje je i mene mučilo, a zapravo je odgovor prilično jednostavan. Naime, kad se orkestar od stotinjak glazbenika priprema za izvedbu neke kompozicije, mada su note svima iste, postoji toliko ideja i vizija kako bi skladba trebala zvučati, koliko je i glazbenika u orkestru. Kada treba svirati jače? Kada tiše? Na koji način odsvirati pojedini ton? Samo o trivijalnom detalju, npr. hoće li sekcija violina započeti svoj dio na način da gudalom krenu odozdo nagore ili obrnuto, značajno ovisi kako će zvučati konačna izvedba. Dirigent mora sve sitne dijelove posložiti u cjelinu i učiniti da svi vide, osjećaju i sviraju kompoziciju jednako. Slaganjem kockica dirigent čini razliku između obične izvedbe i izvedbe u kojoj svi dišu jednako, izvedbe koja zvuči kao čarolija. Prema definiciji iz ITIL-a, upravljanje servisima je skup specifičnih mogućnosti organizacije za davanje vrijednosti korisnicima u obliku servisa. U suštini, sve što IT odjeli čine u svakodnevnom radu, može se svesti na upravljanje servisima. Čak i specifični procesi i funkcije, kao upravljanje znanjem, ljudima i budžetima, vrlo se jasno i jednostavno mogu dovesti u kontekst ključne svrhe IT odjela omogućiti korisnicima da komuniciraju om, koriste Internet, sigurno pohranjuju datoteke, rade na raznim poslovnim aplikacijama i koriste ostale IT servise. Pritisak na IT u svrhu poboljšanja kvalitete servisa ili učinkovitiju (u praksi to najčešće znači i jeftiniju) isporuku servisa svakim je danom sve izraženiji u gotovo svim organizacijama. Suočeni s takvim izazovom, IT odjeli se, u pravilu, u potrazi za pomoći, okreću javno dostupnim standardima i preporukama. Sretna je okolnost velika količina javno dostupnih standarda i preporuka, kao što su ITIL, COBIT, CMMI, ISO 20000, ISO 27001, etom, i drugi. Gdje se uklapa ITUPC? Nažalost, sve je to puno jednostavnije u teoriji nego u praksi. Implementacija upravljanja IT servisima zahtijeva ITUPC arhitektura ITUP+RMC = ITUPC optimalnu integraciju ljudi, procesa, tehnologija i informacija. Nijedna od spomenutih komponenti sama za sebe ne služi svrsi. Nužno je orkestriranje svih segmenata. Slično kao i glazbenik u orkestru, svaki informatičar s par godina iskustva zna kako upravljati IT servisima, kako bi se neki proces trebao obavljati, ne treba niti mistificiranje ITSM discipline. No, tek kada svi članovi tima imaju istu viziju i svatko točno zna što i kada treba učiniti da bi pojedini proces uspio, tek tada se postižu vrhunski rezultati i osjetno poboljšanje kvalitete IT servisa. Upravo ITUPC je alat koji nam može pomoći u ostvarivanju opisanoga cilja. Mada, kao što rekosmo, alat sam po sebi ne znači ništa, ITUPC je, u ovom slučaju, vitalan čimbenik uspješnog dirigiranja IT odjelom koji izvodi upravljanje IT servisima. ITUPC arhitektura i funkcionalnosti ITUPC se sastoji od dva bitna funkcionalna dijela: ITUP i RMC. ITUP predstavlja sveobuhvatne i detaljne dokumentacije najbolje prakse pri 20 FYI by CROZ / broj 4 / lipanj 2008.

21 > Tehnologije i trendovi / IBM Tivoli Unified Process Composer Modeli za upravljanje IT servisima Jedna od vrlo zanimljivih informacija koje možete naći u ITUP-u jest opis i usporedba raznih modela za upravljanje IT servisima Model Domain Specifications Best Practices Process Model Maturity Model ITIL IT Service Management no yes no no COBIT IT Governance yes no no yes SOX Regulatory yes no no no CMMI Software development and no yes no yes etom Telecommunications no yes yes no ISO17799 Information security management yes no no no ISO20000 IT Service Management yes no no no Six Sigma Process improvement no yes yes no implementaciji ITSM procesa, a osim toga sadrži i čitav niz dodatnih informacija vezanih uz ITSM, te može poslužiti i kao izvor i odlična baza ITSM znanja za cijelu organizaciju. Sadržaj ITUP-a temeljen je na najboljoj praksi IT industrije i omogućuje lako razumijevanje procesa, međusobnih odnosa između procesa, uloga pojedinih članova tima, informacija potrebnih da bi se pojedini proces proveo, te alata uključenih u efikasnu implementaciju procesa. ITUPC nadopunjava ITUP sadržaj s RMC-om (detaljno opisan u FYI broj 2), koji koristimo za prilagodbu sadržaja i procesa specifičnostima organizacije. Ukratko, ITUP je read-only baza procesa, a ITUPC nam daje write mogućnosti. ITUP Composer nam donosi sljedeće resurse: Biblioteka procesa ITUPC sadrži detaljno dokumentiran 41 proces. Procesi opisuju manje-više sve čime se IT bavi ili se treba baviti, ne samo u segmentu upravljanja servisima nego i šire. Svaki proces je detaljno opisan, definirani su njegovi ciljevi, opseg i KPI, te odnosi s ostalim procesima. Opisani procesi usklađeni su s ITIL-om, i to s upravo nedavno objavljenom trećom verzijom. No, dok ITIL daje vodilje što i kako implementirati, ITUP sadrži detaljne dijagrame procesa i opise pomoću kojih je lakše razumjeti procese i njihove međusobne odnose, čineći time ITIL lakše i brže primjenjivim. Također je važna funkcionalnost ITUPC-a, mogućnost objavljivanja procesne dokumentacije kroz web site, čime omogućuje jedinstven pogled i razumijevanje procesa cijelom timu ili organizaciji. Drugim riječima, ITUPC pomaže da svi sviraju iste note na jednak način. Procesi opisani u ITUP-u, usporedba s ITIL procesima (treća verzija) Architecture Management Asset Management Availability Management Capacity Management Change Management Compliance Management Configuration Management Customer Satisfaction Management Data Management Event Management Facility Management Financial Management Incident Management IT Customer Transformation Management IT Governance and Management System Capabilities IT Governance and Management System Evaluation IT Governance and Management System Framework IT Management System Operation IT Portfolio Management IT Research and Innovation IT Service Continuity Management IT Strategy Knowledge Management Problem Management Program and Project Management Release Management Risk Management Security Management Service Execution Service Level Management Service Marketing and Sales Service Pricing and Contract Administration Solution Acceptance Solution Analysis and Design Solution Build Solution Requirements Solution Test Stakeholder Requirements Management Supplier Relationship Management User Contact Management Workforce Management Service Asset and Configuration Management Availability Management Capacity Management Change Management Service Asset and Configuration Management Event Management Financial Management Incident Management Service Portfolio Management IT Service Continuity Management Strategy Generation Knowledge Management Problem Management Release Management Information Security Management Service Level Management Supplier Managemen FYI by CROZ / broj 4 / lipanj

22 > Tehnologije i trendovi / IBM Tivoli Unified Process Composer Odličan primjer kako ITUP dokumentacija integrira procese, uloge i alate jest swimlane dijagram. Na slici je primjer change management procesa prikazanog kroz swimlane dijagram. Što donosi C iz ITUPC? Ključna funkcionalnost koju nam donosi RMC kao nadogradnja ITUP-a jest mogućnost prilagodbe svih navedenih podataka potrebama vlastite organizacije. Naravno, ako nam navedeni procesi uopće ne odgovaraju, moguće je skicirati i dokumentirati nove, od nule. RMC nije jednostavan alat, za njegovo korištenje potrebno je savladati osnove kako korištenja tako i korištene terminologije. Detaljno je o RMC-u pisano u drugom broju popularnog FYI-a, pa se nećemo ponavljati. Vodilje za upotrebu alata Vodilje za upotrebu alata opisuju najbolju praksu i preporuke kako upotrijebiti IBMove alate u kontekstu implementacije i automatizacije pojedinih procesa, pomažu identificirati koje alate i rješenja upotrijebiti za odrađivanje specifičnih zadataka i kako na pravi način primijeniti alate. Time se iznimno skraćuje vrijeme i resursi koje IT organizacija mora potrošiti za smišljanje načina kako tehnološki riješiti neki problem, i uštedit će vam dosta googlanja. Naravno da se konkretno spominju samo IBM-ovi alati, no ako želite evaluirati i rješenja drugih proizvođača softvera, lako je povući paralelu i naći pandan IBM-ovu softveru kod konkurencije. Uloge Prosječni IT djelatnik u pravilu je odgovoran za više uloga u opsegu njihova posla koje su povezane s izvršenjem konkretnih zadataka. ITUPC omogućuje detaljno opisivanje uloga i odgovornosti te njihovo objavljivanje kako bi svi u organizaciji imali jasnu informaciju tko što treba odraditi. Isporuke Ulaz i izlaz iz procesa i pojedinih zadataka unutar procesa obično karakteriziraju isporuke, najčešće su to dokumenti. ITUP opisuje isporuke za svaki proces te ključne zadatke unutar procesa, uključujući i dodatne informacije kao definiciju bitnih stavaka koju treba isporuka sadržavati. Scenariji Scenariji opisuju uobičajene probleme i preporučena rješenja. Korištenjem scenarija moguće je uočiti koji se problemi iz stvarnoga svijeta mogu dogovoriti te kako ih adresirati kroz poboljšanje i integraciju procesa, pravilnu upotrebu alata, pravilno postavljanje uloga i odgovornosti. Swimlane dijagram change management procesa Ukratko, ITUPC donosi predefiniran method library za RMC, koji sadrži upravo sve procese i njihove elemente kako su dokumentirani u ITUP-u. Ne temelju tog predloška lako je prilagoditi procese specifičnim potrebama pojedine organizacije. Možemo dodati ili izbaciti korake iz procesa, definirati role i konkretne ljude koji izvode pojedine zadatke, povezati pojedine zadatke s dokumentacijom potrebnom za izvršavanje istih, opisati obavezne i opcionalne isporuke pojedinih zadataka itd. Nakon što je proces opisan prema našim potrebama, moguće je objavljivanje u PDF, HTML i Microsoft Word formatu. Feature ITUP ITUP Composer Industry best practices Y Y Process-level information Y Y Activity-level information Y Y Tool use guidance Y Y Task-level information Y Y Content customization Content creation Content publishing Cijena Besplatan 1613 Zaključak ITUP, kao besplatni resurs, s informacijama koje sadrži, zasigurno je vrlo vrijedan za svaku IT organizaciju. Dapače, vrlo je koristan i za edukaciju svakog IT profesionalca. ITUP je dostupan, uz registraciju, za preuzimanje s IBM-ovih web stranica. ITUPC je, s cijenom od 1613 za 10 autoriziranih korisnika, definitivno alat s vrlo dobrim omjerom funkcionalnosti i cijene, a može koristiti svakoj organizaciji koja kreće u proces ili je već u procesu uvođenja upravljanja svojim IT servisima. Y Y Y 22 FYI by CROZ / broj 4 / lipanj 2008.

23 > Tehnologije i trendovi / IBM Rational AppScan Ugradite sigurnost u svoje web sustave -Piše: Miroslav Zaninović- U današnje vrijeme mnoge organizacije svoje poslovne procese povjeravaju web orijentiranim aplikacijama. Upravo iz tog razloga implementacija sigurnosti u web sustave treba biti sastavni dio procesa razvoja i isporuke softvera, no na nesreću, nove funkcionalnosti i usluge treba uvijek isporučiti u kratkim rokovima; često na štetu testiranja, osobito sigurnosnog. Kao rezultat imamo aplikacije koje su ranjive i dozvoljavaju razne načine za krađu kako poslovnih tako i privatnih korisničkih podataka. IBM Rational AppScan je alat koji će olakšati, ubrzati i automatizirati vaš proces sigurnosnog i penetracijskog testiranja. IBM Rational AppScan je alat namijenjen automatizaciji sigurnosnog i penetracijskog testiranja web aplikacija i servisa. Rješenje kao što je AppScan omogućava organizacijama kontinuirano otkrivanje sigurnosnih rizika u aplikaciji te da pravovremeno osiguraju svoju aplikaciju, čime se znatno umanjuju rizici prije isporuke softvera. Verzije koje nam AppScan nudi su: IBM Rational AppScan Standard Edition (desktop instalacija) IBM Rational AppScan Enterprise Edition (web rješenje koje omogućava paralelno izvršavanje različitih testova i zajedničku bazu testnih rezultata) IBM Rational AppScan Tester Edition (integracija za vodeće QA alate i razvojne okoline). Svaki od ponuđenih alata omogućava odabir testova koje ćete izvršavati, skeniranje sustava i pronalaženje potencijalnih sigurnosnih rizika i ranjivosti, testiranje, analizu dobivenih rezultata te detaljno izvještavanje o izvršenim testovima. AppScan je sa svojim mogućnostima namijenjen gotovo svim članovima razvojnog tima, od programera preko testnih timova, penetracijskih testera, ljudi zaduženih za kontrolu sigurnosti u sustavima pa do senior managera. Kao dio Rational Portfolija, Rational Software Delivery Platforme, AppScan omogućava korisnicima rad u željenom tehnološkom okruženju te prilagođavanje postojećim Quality Assurance alatima i razvojnim okruženjima. Važnost AppScana Zna se koliko je važna sigurnost sustava i aplikacije. Sve ranjivosti aplikacije, otkrivene od neželjenih korisnika, narušavaju povjerenje kako u proizvođača tako i u vlasnika softvera. Kada se govori o sigurnosti, obično se misli na sigurnost sustava, no zaboravlja se sigurnost web aplikacija i servisa. Iako je sustav zaštićen od različitih vrsta neželjenih ulaza, aplikacija, koja je legalnim portovima propuštena, ranjiva je ukoliko nije sigurnosno kvalitetno razvijena. AppScan je alat koji u stvarnom vremenu skenira aplikaciju i pronalazi potencijalne sigurnosne ranjivosti u kôdu aplikacije. Pri tome ga sustav i okolina ne zanimaju, uz iznimku sigurnosnih propusta aplikacijskih poslužitelja na kojima je aplikacija instalirana. Svi rizici koje AppScan pronađe ravnopravni su bilo kojem funkcionalnom bugu pronađenom u kôdu aplikacije. Evo kratkog objašnjenja položaja i svrhe AppScana u odnosu na ostale softvere koji osiguravaju vaš sustav. Network firewall blokira promet u stvarnom vremenu, no mora propuštati portove do aplikacije (npr. 80 i 443). Sustav je zaštićen, no aplikacija je ranjiva upravo preko legalno propuštenih portova. Intrusion Detection System (IDS) i Intrusion Prevention System (IPS) analiziraju sustav u stvarnom vremenu i pokušavaju pronaći različite sigurnosne rizike, vanjske i interne napadače, no kao i firewall nemoćni su pred aplikativnim napadima koji u sustav ulaze legalnim putovima. Application firewall može zaštiti vašu aplikaciju od napada i izmijenjenih requesta, no potrebno ga je ažurirati prilikom svake promjene aplikacije, što je presložen i prezahtjevan posao. Network Scanners pronalaze potencijalne ranjivosti na sustavima te mogu skenirati infrastrukturu web i aplikacijskih poslužitelja, čime se približavaju funkcionalnostima AppScana, no ne mogu analizirati ranjivosti aplikacije instalirane na serveru. Source Code Scanners (White Box Analysis) analiziraju kôd aplikacije i pronalaze potencijalne sigurnosne greške u kôdu, oslanjajući se na teorijska znanja, koja su često nepotpuna. Pogodni su za otkrivanje grešaka u kôdu, no ograničeni su i ne mogu sigurnosno testirati aplikacije u stvarnom vremenu. Database Scanners pronalaze slabosti u radu i konfiguraciji baze podataka, no ne mogu provjeravati sigurnost podataka kada im se pristupa preko web aplikacije. Application Scanners (Black Box Analysis) pristupaju aplikaciji pronalazeći različite potencijalne sigurnosne rizike i šalju različite requeste, dobronamjerne i zlonamjerne inpute, s namjerom generiranja responsa web aplikacije. Responsi se analiziraju i pronalaze se potencijalne ranjivosti. AppScan nema pristup kôdu aplikacije, pokušava pronaći ranjivost kroz internetski preglednik i postići jednake rezultate koje bi potencijalni hacker mogao vidjeti. Skeniranje AppScan može izvršavati penetracijske testove nad web aplikacijama i servisima. Proces je u oba slučaja identičan. Sastoji FYI by CROZ / broj 4 / lipanj

24 > Tehnologije i trendovi / IBM Rational AppScan se od definiranja testova koje želimo izvršavati, skeniranja sustava, samog testiranja i analize rezultata. Korisničko sučelje je jednostavno i intuitivno te omogućava analizu kroz tri različita pogleda. Najvažniji je Security Issue koji pokazuje Application Tree sa svim datotekama i direktorijima pronađenim prilikom skeniranja aplikacije, grupiranih prema vrsti podataka koje aplikacija koristi. Naglasak je na URL-ovima unutar aplikacije koji sadrže potencijalne sigurnosne rizike i naprednom pretraživanju numeričkih parametara korištenih prilikom skeniranja. Remediation Tasks je pogled koji pokazuje zadatke i akcije potrebne za ispravljanje pronađenih ranjivosti u aplikaciji. Zadaci su povezani s pronađenim ranjivostima i sistematizirani prema prioritetima rješavanja. Application Data je skup svih elementa pronađenih u aplikaciji prilikom skeniranja (URL-ovi, interaktivni URL-ovi, filtrirani URLovi, Broken Links, Script Parameters, Comments, Java Script, Cookie). Prijavljivanje korisnika u sustav vrlo je bitan segment sigurnosti svake aplikacije i vrlo zahtjevna zadaća prilikom automatizacije testiranja. AppScan pruža nekoliko načina za prijavu u sustav prilikom testiranja. Uz klasične načine jedinstvenih korisničkih podataka prilikom svake prijave u sustav ili neprijavljivanja u sustav, podržani su kompleksni načini prijavljivanja u sustav. AppScan može snimiti proceduru prijave korisnika i njegove pristupne podatke, te ih svaki put, kad aplikacija to zahtijeva, rekonstruirati, a nudi i rješenje ukoliko je prilikom svake prijave potrebna interakcija s korisnikom (Completely Automated Public Turing Test to Tell Computers and Humans Apart /CAPTCHA/, mul-tifactor authentication, one-time passwords, Universal Serial Bus /USB/ keys, smart cards, mutual authentication). AppScan podržava velik skup sigurnosnih i penetracijskih testova koje možete izvršavati nad web aplikacijama i servisima. Skup se neprestano dopunjava novim testovima i automatski se ažurira. Prilikom definiranja testova alat zahtijeva kreiranje Test Policyja, odabir testova koje ćete izvršavati ovisno o tehnologiji koju testirate, potrebama i rezultatima prijašnjih testova. Radi lakšeg pretraživanja testovi su sistematizirani u nekoliko skupina prema važnosti testova, prema tipu testova (ovisno o tome testiraju li aplikaciju ili infrastrukturu, ovisno o tome želimo li onesposobiti aplikaciju) i prema klasifikaciji Web Application Security Consorciuma. Testiranje AppScan omogućava automatsko i ručno skeniranje sustava. Prilikom skeniranja pronalazi potencijalne sigurnosne rizike te kreira Application Tree. Prilikom testiranja aplikacije alat izvršava etički hakerski napad na vašu aplikaciju, oslanjajući se na top 10 OWASP (Open Web Application Security Project) i top 20 SANS (System Administration, Networking, and Security Institute) ranjivosti. Testiranje se sastoji od mijenjanja originalnoga requesta i slanja promijenjenih requesta prema aplikaciji. AppScan zatim analizira zaprimljene response i pronalazi sigurnosne ranjivosti u aplikaciji. Za vrijeme i nakon testiranja u Result List, Security Issue pogleda, vidljive su sve ranjivosti pronađene u aplikaciji. Sve ranjivosti povezane su s URL-ovima iz Application Treea i sistematizirane prema važnosti (High, Medium, Low, Information). Odabirom bilo koje pronađene ranjivosti vidjet ćete na kojim je URL-ovima ranjivost pronađena te će se u Detail Paneu pojaviti detalji o ranjivosti. Detail Pane je HTML dokument koji sadrži detaljne informacije o ranjivosti i mogućim posljedicama ranjivosti, nudi rješenje pronađene ranjivosti, ovisno o tehnologiji u kojoj je aplikacija razvijena (Java, PHP,.NET). Request/ Response HTML je najvažniji za analizu ranjivosti. Pokazuje originalni request, originalni response i izgled aplikacije u internetskom pregledniku prilikom skeniranja, zatim pokazuje i objašnjava sve promjene u requestima koje je poslao prema aplikaciji, analizu zaprimljenih responsa te pokazuje kako aplikacija izgleda u internetskom pregledniku nakon penetracijskog testa. Omogućeno je i dodatno ručno istraživanje aplikacije, kreiranje screenshota aplikacije koji se može dodati u izvještaj o testiranju i slanje maila s exportom statusa testa. Izvještavanje AppScan implementira vlastiti sustav za generiranje izvještaja koji se sastoji od sljedećih skupina izvještaja: Security Report izvještava o sigurnosnim ranjivostima otkrivenim prilikom testiranja. Uključuje informacije iz svih pogleda AppScana: Security Issue, Remeditaion Tasks i Application Data. Report sadrži template pomoću kojega se može odrediti koliko će izvještaj biti detaljan, što ovisi o članovima razvojnog tima kojima je namijenjen. Industry Standard izvještava o usklađenosti vaših rezultata sa zahtjevima pojedinih industrijskih standarda (OWASP top 10, International Standard ISO 27001, SANS top 20, WASC Threat Classification ). Regulatory Compliance izvještava o usklađenosti vaših rezultata s regulativama i legalnim standardima različitih zemalja i institucija (European Directive 2002/58/EC, Japan s Personal Information Protection Act, UK Data Protection Act, US DCID, MasterCard SDP, Visa CISP, US Financial services GLBA ). Data Analysis uspoređuje dva skupa testiranih podataka i pokazuje razlike URL-ova i sigurnosnih ranjivosti pronađenih prilikom testova. Svrha je otkriti sigurnosna poboljšanja između prijašnjih i trenutačnih testova. AppScan nudi potpuno rješenje za sigurnosno i penetracijsko testiranje web aplikacija i servisa oslanjajući se na razumijevanje i iskustvo u rješavanju sigurnosnih aplikativnih problema. AppScan omogućava razvijanje kvalitetnijih i sigurnijih softvera. Preko 800 kompanija, vladinih i financijskih agencija širom svijeta sigurnost svojih web aplikacija povjerilo je AppScanu. Zašto i vi ne biste bili među njima? WASC je potencijalne napade sistematizirao u sljedeće skupine: Authentication Brute Force, Insufficient Authentication, Weak Password Recovery Validation Authorization Credential/Session Prediction, Insufficient Authentication, Insufficient Session Expiartion, Session Fixation Client-side Attacks Content Spoofing, Cross Site Scriptoing Command Execution Buffer Overflow, Format String Attack, LDAP Injection, OS Commanding, SQL Injection, SSI Injection, XPath injection Information Disclosure Dirctory Indexing, Information Leaking, Path Traversal, Predictable Resource Location Logical Attacks Abuse of Functionality, Denial of Service, Insufficient Anti-automation, Insufficient Process Validation 24 FYI by CROZ / broj 4 / lipanj 2008.

25 > CROZ-ovi putopisi / Rijad, Kraljevina Saudijska Arabija CROZ od Arabije -Piše: Dejan Cepetić- Nakon što ste u drugom broju FYI-a mogli pročitati putopis iz Bukurešta, u ovom broju slijedi putopis iz još jednog zanimljivog mjesta na kugli zemaljskoj kamo je noga jednoga CROZovca kročila. Dakle, što je to je CROZ radio u glavnom gradu Kraljevine Saudijske Arabije (KSA)? Posredstvom nekih starih poznanstva koja potječu još iz pred-ibmovskih vremena kada je CROZ zastupao tvrtku Candle, te zahvaljujući renomeu i iskustvima koje imaju naši hostaši u radu s ex-candle (sada Tivoli Omegamon) proizvodima, na adresu CROZ-a stigao je upit za angažman u Saudijskoj Arabiji. Vidjevši priliku za dokazivanje našeg znanja i u tom dijelu svijeta, odlučili smo prihvatiti izazov. Ubrzo su počele i pripreme za put. Prvo je trebalo ishoditi vizu koja je obavezna za sve strane državljane. U Hrvatskoj nema veleposlanstva KSA pa se trebalo obratiti veleposlanstvu koje je zaduženo za Hrvatsku, a nalazi se u Sarajevu. Nakon ponešto složenijeg postupka, i dosta truda naše Dolores, viza je sletjela u putovnicu. Sretna okolnost bila je da nije trebalo osobno odlaziti u Sarajevo po vizu. U pripreme za put spada i raspitivanje o mjestu u koje se putuje. Za početak, na stranicama Ministarstva vanjskih poslova RH stoji doslovce sljedeće: Postoji rizik putovanja. Zadnje dvije godine zabilježeni su teroristički napadi i ubojstva zapadnih državljana. Prije putovanja potrebno je prikupiti detaljnije informacije. Hm. Nije baš ohrabrujuće, zar ne? Zahvaljujući činjenici da je prije mene u nekoliko navrata Rijad pohodio kolega Dieter iz IBM-a Austrija, došao sam do korisnih informacija iz prve ruke i zaključio da nije baš tako strašno. Put Stjecajem okolnosti put do Rijada vodio me neuobičajenom rutom preko Beča i Damaska, glavnog grada Sirije, što se poslije pokazalo da i nije baš sretna kombinacija. Na stranu to što je aerodrom u Damasku napravljen prije godina i izgleda da od tada nije u njega uložen niti najmanji djelić sirijske valute (koja god bila), ali pokazalo se da je razmak od skoro dva sata između letova za lokalno aerodromsko osoblje premalen, tako da prtljagu nisu stigli prebaciti iz jednog aviona u drugi te sam u Rijad sletio bez iste. Poslali su je sljedećim letom za tri dana! Moram priznati da, što se više moj dolazak bližio, sve sam više strahovao gdje ja to zapravo idem. Aerodrom u Rijadu, nakon onoga u Damasku, izgleda kao NASA-in svemirski centar, tako da je prvi dojam bio ohrabrujući. I prvi susret s lokalnom aerodromskom policijom bio je ugodan. Izvolite, tu ovo samo popunite, ostalo ne treba, ljubazan osmijeh. Fino. Bližilo se vrijeme Hajja i puno vjernika je pristizalo, ali velikoga čekanja nije bilo. Iako na aerodromu stoji upozorenje da treba, među ostalim, prijaviti knjige, audio i video materijale, nitko me nije ništa pitao i sve je išlo glatko, osim onog dijela s prtljagom. Budući sam stigao u večernjim satima, prvi mi je susret bio s Rijad by night i mora se reći da grad po mraku izgleda odlično. Rijad na prvi pogled Grad je poprilično velik i prostran. Prevladavaju široke ceste prilagođene mnogobrojnim i velikim autima. Uz glavne ceste uglavnom su velike i nove zgrade koje karakterizira moderna arhitektura pod lokalnim utjecajem. Rijetke su zgrade veće od desetak katova. Po visini i izgledu ističu se dvije građevine: Kingdom Tower i Al Faisaliyah Center. Kingdom Tower najveći je neboder u gradu, visok 309 m s 45 katova. U sklopu nebodera nalaze se, među ostalim, veliki shopping centar i luksuzni hotel Four Seasons. Al Faisaliyah Center, visok 267 m s 30 katova, bio je najveći neboder dok nije izgrađen Kingdom Tower. U njemu je također shopping centar, a sâm neboder dio je Al Faisaliyah kompleksa, koji se još sastoji od luksuznoga hotela i dvije manje zgrade. Grad je pun gradilišta na kojima se dosta užurbano grade nove zgrade koje će privlačiti poglede. S druge strane neka mjesta u blizini izgledaju loše održavano i nedovršeno i potpuno su u neskladu s ostatkom okoliša. Sve su takve stvari neprimjetne kada padne mrak i grad zablista pod uličnim svjetlima. Ono što, krećući se po gradu, svakako upada u oči i podsjeća na prije spomenuto upozorenje našeg ministarstva su vojni kontrolni punktovi i betonski blokovi. U blizini svake važnije zgrade postavljeni su vojni kontrolni punktovi pred kojima treba usporiti i prema potrebi stati zbog kontrole. Najčešće vojnik samo pokaže rukom ili kimne glavom kao znak da se može proći. Na ulazima u hotele auti se obavezno pregledavaju, da nisu opremljeni kakvom eksplozivnom napravom. Uokolo važnih zgrada i hotela postavljeni su betonski blokovi, ponegdje i višestruko. Ispred nekih zgrada parkirani su kamioni, a u sanduku svakog dežura vojnik s mitraljezom povećeg kalibra. Način života Rijad inače odaje dojam svjetske metropole. U širem poslovnom dijelu grada svi su natpisi, osim na arapskom, i na engleskom jeziku. Engleski je gotovo službeni jezik. Puno stranaca iz svih dijelova svijeta živi i radi u Rijadu, tako da se i ja, kao još jedan od mnogih, nisam osjećao neobično. Stranci su većinom iz arapskih zemalja, Indije, Pakistana i ostalih azijskih zemalja. Bijelaca ima, ali manje. Rođene Saudijce Al Faisaliyah Center FYI by CROZ / broj 4 / lipanj

26 > CROZ-ovi putopisi / Rijad, Kraljevina Saudijska Arabija se lako prepozna po tradicionalnim haljama koje su karakteristične za arapski svijet. Stranci su obučeni kao u Europi i općenito u zapadnom dijelu svijeta. Žene su obučene u crne odore (abaya) koje prekrivaju cijelo tijelo. Saudijke imaju pokrivenu cijelu glavu i lice, osim očiju (niqab: pokrov za lice), a ponekad i oči, dok strankinje nemaju pokriveno lice. Žene se općenito manje viđa, uglavnom u shopping centrima i trgovinama. Sve poslove u kojima postoje kontakti sa strankama rade muškarci. Čistači, konobari, prodavači, sve su muškarci. Čak i u trgovinama sa ženskim donjim rubljem. U informatici se također susreću samo muškarci. Religija je priča za sebe. Stranci islamske vjeroispovijesti i domaći Saudijci vrlo su religiozni. Mole se pet puta dnevno, od ranoga jutra do kasnih večernjih sati i sve je tome prilagođeno. U vrijeme molitve prestaju s radom, zatvaraju trgovine i restorane i upućuju se u mnogobrojna i sveprisutna mjesta za molitvu. Dvorane za molitvu mogu se naći i u shopping centrima, i to posebno za žene, a posebno za muškarce. Evo jedne anegdote koja će dočarati status molitve. Prvu večer po dolasku sjedim s kolegom iz IBM-a Austrija u nekom pristojnom restoranu i jedem svoj obrok. U jednom trenutku usred zalogaja konobar nas lijepo zamoli da se preselimo na terasu jer je vrijeme molitve i oni za to vrijeme zatvaraju restoran. Pri tome nam uljudno pomogne prenijeti tanjure i pribor na terasu. Šok i nevjerica, ali ubrzo se čovjek navikne i počne u vrijeme molitve izbjegavati posjet restoranima i trgovinama. U Saudijskoj Arabiji vlada šerijatski zakon, a Qur an je ujedno i nacionalni Ustav te se shodno tome zakonodavni i pravosudni sustav ravnaju. Za kriminalne aktivnosti vezane uz drogu, kao i ostale teže oblike zločina (ubojstvo, silovanje, teža razbojstva), predviđena je smrtna kazna ili amputiranje udova. Većina stranaca živi u zatvorenim i dobro čuvanim naseljima (compounds). U takvim naseljima su vrtići i škole i sve ostalo potrebno za život. U razgovorima s nekim Europljanima koji žive i rade Rijadu, stekao sam dojam da, zahvaljujući visokim zaradama, žive na visokoj nozi te da nisu pretjerano zabrinuti za vlastitu sigurnost. Kažu da su, što se tiče sigurnosti i odgoja djece, spokojniji nego da žive u nekim većim gradovima na Zapadu. No, svjesni su da će morati odseliti jednom kada djeca dođu u adolescentske godine jer će im tada takvi uvjeti života biti neodgovarajući. Shopping i hrana Prilike za shopping su velike. Ima nekoliko velikih i modernih shopping centara sa svim poznatijim svjetskim trgovinama: Zara, Marks&Spencer, Toys r Us, Mango, Boss, Gucci, Lacoste, sve čega se možete sjetiti. Veliko tržište s priličnom kupovnom moći privuklo je sve poznatije svjetske trgovačke marke da otvore svoje trgovine. Osim shopping centara, u širem poslovnom dijelu grada ima mnogo manjih i većih trgovina sa svime što novac može kupiti. Osim alkohola. Zlato je jeftinije nego u drugim dijelovima svijeta pa se po gradu može naći velik broj zlatarnica. Također, puno se trguje i s mirisima. Mirisi su specifični jer se rade na bazi ulja, a ne na bazi alkohola i obično se nanose na odjeću, a ne na kožu. O hrani nažalost ne mogu reći puno, jer domaće specijalitete nisam istraživao. Mogu reći da su cijene otprilike kao i u Hrvatskoj i da je izbor poznatih fast food restorana vrlo velik. Hotelska hrana je, naravno, prilagođena strancima, kao i hrana u internom restoranu institucije u kojoj sam radio. Od domaćih specijaliteta probao sam samo kolače. Vrlo su slatki i zasitni, a u sastojcima je umjesto svinjske masti prisutan loj tako da neki kolači imaju okus janjetine. Promet Promet u Rijadu prilično je gust. Po cestama se kreću veliki automobili uglavnom američke i dalekoistočne (Japan, Koreja) proizvodnje. Budući da u Saudijskoj Arabiji poreza nema, automobili su dosta jeftiniji nego u ostatku svijeta, tako da su ti limeni ljubimci dostupni svima. To, kao i niska cijena benzina (litra je oko 1,5 kn) uzroci su da se automobil koristi kao glavno prijevozno sredstvo. Taksija ima prilično i vožnja taksijem je također vrlo raširen način transporta po gradu, zahvaljujući i činjenici da cijena vožnje nije visoka. Početna cijena je oko 8 kn. U gradu postoji i javni prijevoz koji se sastoji od autobusa malo većih od kombija, ali moram priznati da ih nisam baš previše viđao po gradu i imam dojam da se vrlo malo ljudi koristi tim načinom transporta. Vjerojatno manje imućni stranci. Budući da je vožnja automobilom vrlo prihvatljiva, pješaka skoro i nema, a oni koji se i odvaže prošetati, moraju dobro paziti. Na pješačkim prijelazima nitko ne staje, a priličan broj semafora za pješake ne radi. Na nekim mjestima niti nema nogostupa. O biciklima i biciklističkim stazama suvišno je govoriti. Ne postoje. Način vožnje sličan je kao u nekim mediteranskim zemljama (Italija, Hrvatska). To znači da se propisi uredno ignoriraju, do određene mjere. Vozači voze prilično brzo i agresivno. Zanimljivo je da se truba koristi gotovo često koliko i kočnica. Ne može se reći da nema vozačke kulture. Ona je jednostavno drugačija. Stekao sam dojam da zaista nema ljutnje i psovanja, već se sve odvija nekako ležerno. Ipak, podaci o prometnim nesrećama zabrinjavajući su. U posljednjih pet godina zabilježeno je 1,36 milijuna nesreća s poginulih i ozlijeđenih. Kako bi se bolje kontroliralo loše i nestašne vozače, ministarstvo unutrašnjih poslova planira instalirati po cijeloj zemlji kamere koje bi trebale snimati prekršitelje. Inače, žene prema zakonu ne mogu pohađati autoškolu i ne mogu dobiti vozačku dozvolu. U pripremi je zakon koji bi krajem godine trebao to promijeniti. Do tada, ovdašnji vozači još neko vrijeme neće moći optuživati žene za loše stvari u prometu. Umjesto žena, krivi su Indijci i Pakistanci. Nadam se da sam uspio barem donekle dočarati svoje dojmove iz posjeta glavnom gradu jedne nama daleke i egzotične zemlje kao što je Saudijska Arabija. Ova zemlja sigurno je privlačna za one željne dobre zarade za kraće vrijeme, pod uvjetom da se prilagode njezinim posebnostima. Što se turističkih posjeta tiče, vjerojatno će privući ljude koji su skloniji avanturi jer, među ostalim, uz vizni režim i sigurnosno stanje, zemlja baš i nije okrenuta turizmu. Npr. fotografiranje je dosta otežano, što iz sigurnosnih razloga, a što zbog položaja žene u tamošnjem društvu. Naime, ako vam žena uđe u kadar, mogli bi nastati problemi koji obuhvaćaju i zapljenu kamere. Na kraju moram priznati da je meni svakako ostao bolji dojam od onoga što sam očekivao prije posjeta. 26 FYI by CROZ / broj 4 / lipanj 2008.

27 U šest koraka do 1. korak Tri, dva, jedan, kreni! Nije tajna da se CROZ i edukacija vole. Ljubav se rodila još davnih dana, u vrijeme kada je CROZ rastao i u svojim inkubatorima podizao nove tehnološke snage. Edukacija je dodatno dobila na važnosti kada smo se intenzivno počeli baviti uvođenjem tehnoloških i metodoloških promjena u velike timove. 2. korak Prvi IBM-ovi edukacijski koraci Idući korak bio je ulazak u svijet IBM Rational edukacije. Status ovlaštenog edukacijskog centra skrenuo je pažnju na naše instruktore i u regionalnom smislu. Iz mjeseca u mjesec naš se tim instruktora povećavao i danas u svojim redovima imamo gotovo 30 Rational certifikata. 3. korak Vrijeme je za vlastitu produkciju Vrlo se često kroz rad na živim projektima ukazivala potreba za specifičnim edukacijama. I iako smo i ranije koketirali s kreiranjem vlastitih tečajeva, došlo je vrijeme da se ponuda CROZ tečajeva zaokruži. Naši domaći profesori i R&D odjel pomogli su da danas imamo vlastite tečajeve u domenama Java osnovnog i naprednog razvoja, upravljanja projektima, poslovnim procesima itd. 4. korak Od techno gurua do pedagoga Bilo da se radi o IBM ili CROZ tečajevima, gradivo je uvijek specifično, tehnološki izazovno i novo, a takvo gradivo mogu predavati samo ljudi koji kontinuirano uče i aktivno rade na projektima. I to nije sve J, svaki predavač mora znati prenijeti znanje i motivirati studente. Baš je zato 4. korak možda najvažniji u CROZ mašinu za edukaciju predavača ubacili smo svoje tehnološki najkvalitetnije ljude. P.S. Mašina je sustavni rad na njihovim komunikacijskim vještinama, ali nemojte nikome odati tajnu J. 5. korak Cigla po cigla Najprirodniji korak od svih imamo ljude, znanje i tečajeve, što nedostaje? Naravno kućica, odnosno naš novi edukacijski centar Learn@CROZ kojega smo otvorili ovog proljeća. A koliko je kućica ugodna i lijepa, provjerite na slikama. 6. korak velik IBM-ov edukacijski korak I kao šlag na tortu, evo i novog modela IBM edukacije. CROZ je odabran za Authorized Training Providera za Hrvatsku. IBM i CROZ krenuli su u široku edukacijsku suradnju. Nadamo se da će se svim dosadašnjim korisnicima IBM edukacije, ali i svima novima, ovaj korak svidjeti i da će im novi dom IBM znanja biti poticajan i ugodan. FYI by CROZ / broj 4 / lipanj

28 RASPORED I KATALOG TEČAJEVA PROVJERITE NA