today software magazine n19/2014

La mulți ani !

TSM T O D A YS O F T WA R E

Nr. 19 • Ianuarie 2014 • www.todaysoftmag.ro • www.todaysoftmag.com

M AG A Z I N E

Command Query Responsibility Segregation

Pitch design. Cum conceptualizezi şi livrezi prezentarea unui start-up

Deep learning

Trend-uri în HR pentru 2014

Depășirea Așteptărilor în Asigurarea Calității

Startup Weekend – Aici şi Acolo

Search versus Discovery

Machine Learning

Multithreading în C++ 11

IT Days 2013

Sonar

Spre comunitatea IT – via HR (4)

Tom Gilb. De ce furnizarea calității cătreclient îți face afacerea durabilă și de succes

34Deep learningRoland Szabo

36Detectarea și corectarea obicei-urilor alimentare nesănătoase la persoanele în vârstăTudor Cioară

38Command QueryResponsibility SegregationAndrei Păcurariu

41Naţiunea Startup-urilor Dhyan Or

43SonarRadu Vunvulea

44Leadership-ul inovativ şi construirea sistemelor sustenabile Monica Soare

46Externalizarea dezvoltării software. Cum va puteți proteja proprietatea intelectuală?Claudia Jelea

48Depășirea Așteptărilor în Asigurarea Calității Mihai Nadăș

50O schimbare de paradigmă în online: Discovery vs. SearchGeorge Bara

52Trend-uri în HR pentru 2014 Andreea Pârvu

54Pitch design. Cum conceptualizezi şi livrezi prezentarea unui start-upMarius Iatan

6IT Days 2013 (I)

Ovidiu Mățan

9Startup Weekend

– Aici şi Acolo

Irina Rotaru

10Inovația sau despre cum să

influențezi viitorulAndrei Kelemen

13Clientul Today Software

Magazine pentru Android3Pillar Global India

17Valoarea ca strategie

Cornelia Stan

19Multithreading în standardul

C++11 (partea I)Dumitrița Munteanu

21Ce să

înveți în 2014

Alexandru Bolboaca și Adrian Bolboacă

25Tom Gilb. De ce furnizarea

calității către client îți face afacerea durabilă și de succes

Alexandra Beșe

28BPMN – util în modelarea

proceselor de business Anita Păcurariu

31SPRE COMUNITATEA IT – via HR (4)

Dan Ionescu

http://www.kinectforwindows.org



4 nr. 19/Ianuarie | www.todaysoftmag.ro

La mulți ani !!! Începem noul an plini de elan și ne așteptăm la mai multe reali-zări pentru 2014. Prima inițiativă este legată de îmbunătățirea modului în care apare revista Today Software Magazine. Intenționăm să lansăm simultan edițiile

în română și engleză, pentru a elimina diferența de o lună care exista până acum.Retrospectiv, ne putem mândri cu 153 de autori care au scris până acum cel puțin

un articol în TSM! Cei mai mulți dintre ei, deși sunt foarte buni specialiști, sunt la prima publicare a unui articol, motiv pentru care ne mândrim că au ales TSM ca prim spațiu de afirmare. Numărul articolelor publicate până acum este 328 în română, iar 269 dintre acestea sunt disponibile și în engleză. Așa cum am publicat în primul editorial al revistei apărut în februarie 2012, un fel de manifest TSM, am promovat specialiști valoroși care și-au arătat valoarea prin articole și prin prezentările susținute la evenimentele de lan-sare a fiecărui număr. De asemenea, am mai respectat un punct al acestui manifest, prin realizarea din decembrie 2013, a evenimentului IT Days, oferind comunității IT clujene ocazia unor importante luări de poziție care vizau și raportul cu întreaga comunitate clujeană. Deja începem să ne gândim la următoarea ediție din acest an, iar orice sugestie sau dorință de a aduce un anumit speaker va fi luată în considerare

Acest prim număr al anului 2014 deschide seria unor articole dedicate descrierii eve-nimentului IT Days. Sunt și alte articole care focalizează evenimente și efectele acestora . De exemplu, articolul care descrie implicarea în organizarea unui Startup Weekend în Montreal, ne informează despre ceea ce apreciază canadienii la noi, dar și care sunt punc-tele lor forte atunci când vorbim despre startup-uri. Punctele forte care să devină repere în funcționarea unor companii sunt prezentate în alte articole. Unul dintre acestea,Valoarea ca strategie, este articolul realizat de un reprezentant al companiei locale Accesa, care a primit recent din partea primăriei Munchen premiul Phoenix ca o recunoaștere a performanței acesteia. Importanța inovației și modul în care poate fi aceasta sprijinită este tema articolului semnat de Andrei Kelemen, directorul IT Cluster-ului clujean. Tom Gilb ne transmite într-un interviu De ce furnizarea calității către client îți face afacerea durabilă și de succes.

Alte repere de luat în considerare precum tehnici, procedee și abilități menite să crească performanțele unei companii, sunt descrise în articole precum Business pro-cess model and notation (BPMN), Depășirea așteptărilor în asigurarea calității sau ce putem învăța de la un vânzător de papuci: Zappos. Tot în aceeași temă includem și articolul care conține câteva sfaturi despre cum să ținem un pitch Domeniul tehnic este acoperit în acest număr cu o serie de articole interesante. Iată titlurile lor și o scurtă prezentare a lor ! Multithreading in C++ 11, partea I, ne prezintă principalele modificări care au apărut în această versiune de C++. Deep learning abordează un concept foarte la modă în științele informației. Sonar analizează impactul metricilor în dezvoltarea pro-iectelor software . Ce să înveți în 2014 enumeră și descriu zece aspecte de care ar trebui să se țină cont în îmbunătățirea profesională indiferent de limbajul în care programăm . Dan Ionescu ne prezintă ultima parte a studiului de HR realizat despre companiile de IT din Cluj și care este publicat în exclusivitate de către noi. Continuăm și seria de articole din zona legal cu expunerea modalităților de protejare a proprietății intelectuale în cazul externalizării serviciilor.

Vă dorim o lectură plăcută !!!

Ovidiu MăţanFondator al Today Software Magazine

Ovidiu Măţan, [email protected]

Fondator @ Today Software Magazine

Organizator@ IT Days

editorial

mailto:[email protected]

5www.todaysoftmag.ro | nr. 19/Ianuarie, 2014

TODAY SOFTWARE MAGAZINE

Redacţia Today Software Magazine

Fondator / Editor în chief: Ovidiu Mățan [email protected]

Editor (startups și interviuri): Marius Mornea [email protected]

Graphic designer: Dan Hădărău [email protected]

Copyright/Corector: Emilia Toma [email protected]

Traducător: Roxana [email protected]

Reviewer: Tavi Bolog [email protected]

Reviewer: Adrian Lupei [email protected]

Produs de Today Software Solutions SRL

str. Plopilor, nr. 75/77Cluj-Napoca, Cluj, [email protected]

www.todaysoftmag.rowww.facebook.com/todaysoftmag

twitter.com/todaysoftmag

ISSN 2284 – 6352

Copyright Today Software Magazine

Reproducerea parțială sau totală a articolelordin revista Today Software Magazine

fără acordul redacției este strict interzisă.

www.todaysoftmag.rowww.todaysoftmag.com

Lista autorilor

Alexandru [email protected]

Agile Coach and Trainer, with a focus on technical practices@Mozaic Works

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

Radu [email protected]

Senior Software Engineer@iQuest

Monica [email protected]

Manager@ Artwin

Claudia [email protected]

Avocat & Consilier in domeniul marcilor

@ IP Boutique

Andreea Pâ[email protected]

Senior Recruiter@ Endava

Mihai Nadăș[email protected]

CTO@ Yonder

George [email protected]

Co-founder @ZA Cloud

Business Consultant @SDL

Marius [email protected]

CEO & Co-fondator@ RenderStreet

Andrei Pă[email protected]

Software arhitect@ Endava

Dhyan [email protected]

CEO & Co-fondator @ Social ReHub

Roland [email protected]

Junior Python Developer@ 3 Pillar Global

Dan [email protected]

Executive director@ Danis Consulting

Tudor Cioară[email protected]

Asistent Doctor Inginer@UTCN

Alexandra Beșe [email protected]

Marketing Assistant @ ISDC

Irina [email protected]

HR@ Skobbler

Andrei [email protected]

Director executiv@ IT Cluster

Cornelia [email protected]

Communications Officer@ Accesa

Dumitrița [email protected]

Software engineer@ Arobs

Anita Pă[email protected]

Senior Business Analyst@ Endava






www.todaysoftmag.ro

twitter.com/todaysoftmag

www.todaysoftmag.ro

www.todaysoftmag.com


eveniment

Evenimentul a fost o ocazie de a-i reuni pe aproape toți cei care se implică în dezvoltarea comunității IT din Cluj: reprezentanți ai businessului local, startup-uri locale, incubatoare de startup-uri, Cluj IT Cluster , cercetători de la Universitatea Tehnică și de la Institutul de Știință și Tehnologie și autoritățile locale prin prezența primarului Emil Boc. Alți doi invitați speciali din Europa : Tine Thygesen, CEO Everplaces și Eduardo Mendez Polo, head of IT Cloud, Telefonica Spain.

De-a lungul celor două zile, Dan Suciu și-a împlinit cu prisosință rolul de gazdă, reușind să creeze o atmosferă agreabilă, dominată de coerență și profesionalism, c o n d i ț i e n e c e s a r ă d e s f ă ș u r ă r i i evenimentului.

Prima zi a debutat cu o conferință de

presă, după care a avut loc deschiderea oficială, unde l-am avut alături de noi pe primarul Clujului Emil Boc. În discursul pe care acesta l-a susținut la deschiderea oficială, acesta a subliniat avantajul major pe care comunitatea IT îl oferă Clujului, considerând-o voce capabilă să schimbe destinul Clujului : “Aceasta ( comunitatea IT) primește o formă instituțională, o formă vizibilă, o formă organizatorică în prima instanță care îi va da consistență și viitor pentru că a lucra independent, izolat, este un lucru, dar a avea o structură constituțională și concretizată așa cum vedeți astăzi IT Days. Pentru prima dată cred că reprezintă un punct de istorie, un punct de pornire, care va marca și dezvoltarea Clujului. “ De asemenea, a fost evidențiată importanța revistei TSM în coagularea comunității IT

Articolul de față este dedicat IT Days, www.itdays.ro. - reprezentând o primă parte a retrospectivei celui mai important eveniment organizat de către Today Software Magazine în orașul de reședință, Cluj-Napoca. Înainte de a vă oferi

informații mai mult sau mai puțin detaliate despre eveniment, doresc să mulțumesc celor peste 170 de auditori și celor 10 companii care au fost alături de noi la acest eveniment: AROBS, Endava, Evoline, EBS, Gemini Solutions Foundry, Accesa, Yardi, Skobbler, 3Pillar Global si msg systems Romania. De asemenea, mulțumim partenerilor care ne-au susținut: Primăria și Consiliul local Cluj-Napoca, it-events.ro, Cluj Hub și Microsoft Student Partners.

IT Days 2013 (I)

Ovidiu Măţan, [email protected]

Fondator @ Today Software Magazine

Organizator@ IT Days




din Cluj. În continuare s-a discutat despre strategia de dezvoltare 2014 - 2020 , în care componenta IT este o componentă fundamentală alături de cea universitară. Acestea din urmă ne oferă un avantaj competitiv față de alte orașe și regiuni din România. A fost salutată și colaborarea cu cluster-ul de IT Cluj alături de care se propune proiectul Cluj Innovation City care va schimba profilul și viața Clujului. Acesta va fi construit în cartierul Lombului unde au fost alocate peste 100 de hectare de teren. Primi pași sunt reprezentați de Centrul de dezvoltare a afacerii și Centrul de Industrie Creativă și IT unde cel puțin 25 de companii își vor putea desfășura activitatea în acest incubator. Referitor la smart city, primăria deja implementează câteva soluții:

• programarea online a căsătoriilor (râsete în sală),

• plata prin SMS a parcărilor,• plăcuțe pe monumentele istorice cu

QR cod,• sistemul de transport folosind auto-

mate de bilete pentru transportul în comun care va fi dat în folosintă în luna octombrie 2014.

• Cluj Bike Sharing - 500 de biciclete care vor fi la dispoziție în Cluj-Napoca.

D e as emene a , au fos t l ans ate comunității locale câteva provocări:

• Proiectul plat formă Incident Management prin care orice cetățean poate să pozeze sau să filmeze o situație/problemă pe care să o trimită la primărie care prin serviciile de specialitate rezolvă problema și să poată răspunde înapoi cetățeanului.

• Plata prin telefon/SMS a impozitelor și a taxelor locale.

• E-guvernare prin care f iecare cetățean sau companie să poată fi iden-tificat printr-o semnătură electronică și să poată plăti taxele către autoritățile statului.

• Plata biletelor de autobuz prin SMS.

Discursul s-a încheiat cu promisiunea unui parteneriat onest în ceea ce privește generarea de soluții care pot să vină în serviciul cetățeanului.

În prezentarea sa, Alexadru Tulai, președintele Cluj IT Cluster, a remarcat vo lumu l de munc ă impres ionant poate fi solicitat IT-ului de către zona metropolitană. În opinia sa, strategia de dezvoltare metropolitană a Clujului se face printr-o colaborare strânsă între

adminstrația publică, mediul universitar și mediul de afaceri. S-a subliniat și faptul că, deoarece industria de IT își obține veniturile din activități prestate pentru exterior, suntem decuplați de contactul cu cei care pot fi clienți din interior, adică instituțiile statului. De asemenea, Alexandru Tulai a semnalat oportunitatea de a valorifica deschiderea manifestată de Emi Boc pentru recuperarea decalajului tehnologic. O colaborare între sectorul public, mediul academic și mediul de business se impune ca o condiție necesară în implementarea unor măsuri care să reducă din decalajul tehnologic. O materializare a acestei colaborări între cele trei paliere se va încerca prin inițierea de către ITCluster a proiectului Cluj Innovation City. Făcând trimitere la rezultatele remarcabile obținute de universitățile clujene, dintre care cel mai recent, obținerea sângelui artificial în premieră mondială, Alexandru Tulai a accentuat importanța transformării ideilor strict academice în produse utile comunității. Conceptul de cercetare inovată, în funcție de care este conturat acest proiect, este axat tocmai pe această valorificare în beneficiul comunității a reușitelor științifice. Pentru domeniile vizate de proiect ( bioeconomie, sănătate, IT, energie verde) vor fi construite centre de cercetare specifice. Reușita proiectului va fi dată însă de modul cum rezultatele cercetării vor f i preluate de către dezvoltatori și lansate în România, sau chiar exportate.

Eduardo Mendez, head of IT Cloud, Telefonica Spain, a avut prezentarea cu titlul What can we expect from the next Cloud services ? (La ce ne putem aștepta de la următoarele servicii cloud?), care a oferit o viziune originală asupra serviciilor cloud.

Acesta a punctat dificultatea de a integra conceptul cloud într-o definiție unică, pentru că prin natura conținutului său predispune la multiple interpretări.Fiecare are o idee despre cloud computing.- în

acești termeni simpli a rezumat atitudinea generală față de acest concept. Dar pe parcursul întregii prezentări, abordarea lui Eduardo Mendez a subliniat aspectele evidente ale acestui concept care nu favorizează interpretările subiective.Astfel, el delimitează conceptul între private cloud și public cloud , ambele formând construcția hibridă, Hybrid cloud. (vezi figura de mai jos care reprezintă modelul de deployment din prezentare).

Dincolo de preocuparea de a defini în termeni cât mai clari acest concept, se analizează și natura implicațiilor acestor servicii în dezvoltarea companiilor. Analizele statistice semnalează o situație problematică: într-o organizație 75-80% din resurse sunt alocate menținerii structurilor existente și doar 20-25% este alocat proiectelor noi. Timpul de deploy fiind de 2-3 luni. Se știe că recursul la serviciiile cloud ar reduce din acest timp. Adopția cloud nu este datorată organizațiilor de IT, în schimb este susținută de către programatori, startup-uri, departamente interne și de business care caută soluții mai rapide în exterior. Acestea sunt cele care caută fast and cheap deployments.

În final, predicția lui Eduardo este că în câțiva ani, vom avea mașini virtuale gratuite, memorie și procesoare gratuite, însă va trebui să plătești pentru serviciile primite.

Maria Diaconu, CEO Mozaic Works, ne-a povestit despre modul de construire a echipelor inovative pe termen lung. Am reținut ca sugestivă o definiție a inovației: Inovația este un mod de a face lucrurile pe


8 nr. 19/Ianuarie, 2014 | www.todaysoftmag.ro

evenimente

care le cunoaștem într-o altă manieră, venind cu soluții diferite la probleme existente. Această definiție a inovației se aplică echipelor care își propun să fie inovative. Implicarea în experimente care să vizeze selectarea și rafinarea ideilor originale se impune în viziunea Mariei Diaconu, ca un demers necesar în construirea unei echipe inovative. A fost dat ca exemplu Steve Jobs, care este perceput în termeni supraapreciativi ca fiind unicul creator al inovațiilor, ignorându-se că în spatele său a fost o întreagă echipă. Meritul său cel mai mare este acela că a reușit să valorifice creativitatea echipei. De aceea este important să detectezi și să stimulezi capacitatea creatoare și viziunile originale ale unei echipe. Respectând acest principiu putem asigura toate condițiile constituirii unei echipe inovative. Definiția dată de Einstein nebuniei - dacă realizăm lucrurile în aceași manieră dar ne așteptăm la ceva diferit, atunci avem o problemă- este foarte sugestiv aleasă pentru a caracteriza riscurile pe care și le asumă o companie care amână la nesfârșit aplicarea principiilor inovative. De la finalul prezentării, mai selectăm sugestia de a renunța la persoanele din cadrul organizației care nu reușesc să învețe din greșeli și de a pretinde întodeauna consecvență și excelență în realizarea proiectelor.

Prima parte a zi le s-a încheiat cu discursul lui Voicu Oprean, CEO Arobs

Subiectul prezentării sale a fost Trecerea de la outsourcing la produs, fiind de fapt relatarea poveștii de succes a Arobs. Evident că Voicu Oprean își focalizează discursul asupra principiilor care i-au servit ca reper și care i-au adus reușita. ,, Lecțiile,, sale pot fi deci foarte utile celor care își propun să reușească.

Arobs a făcut această trecere, având 400 de angajați. Produsele pe care le vând local și internațional au generat o cifră de afaceri de 4 milioane de euro. De asemenea, s-au implicat și în zona de hardware prin produsele de navigație și mai nou în zona de tablete, având brand-ul propriu: Smilo. Arobs a pornit acum 15 ani făcând primul pas prin outsourcing. Aceasta este de fapt prima lecție: faceți primul pas. În 2002 a trebuit să ia o decizie și în loc să dea oameni afară a decis să se reinventeze. A doua lecție: reinventați-vă. Primul produs a fost o soluție de SMS-uri care acum nu mai există pe piață. Au continuat cu dezvoltarea unei soluții pentru terminale mobile de Winodws Mobile 1.0, care ulterior a fost mutată pe Palm Treo. Într-o astfel de abordare, toată lumea trebuie să își asume riscuri. A treia lecție este asumarea riscului. A patra lecție este să știi când să te oprești. Ultima lecție este folosirea bazei de clienți existente.

Un target asumat și în special în public îi cresc șansele de succes. Suportul poate veni chiar din interiorul companiilor.

Gabriel Ciuloaică a deschis la prânz seria prezentărilor tehnice , cu prezentarea având subiectul reactive programming. În programarea reactivă, de ori câte ori apare o schimbare în model, aceasta se reflectă în view. Până acum o aplicație era specificată prin cerințe cum ar fi capacitate de procesare până la gigabiți de date, rulare pe câteva sute de servere sau mică perioadă de

downtime. În ziua de astăzi aceste specificații nu mai sunt valide. Acum toate trebuie să ruleze pe sute de mașini, să fie elastice, să proceseze date de ordinul terrabytes-ilor și să nu aibă perioade de downtime. Abordarea nouă a specificațiilor este de altfel sintetizată în Manifestul reactive programming. Prezentarea sa subliniază într-o manieră elocventă avantajele aplicării reactive programming.

În numerele următoare vom continua seria de impresii IT Days. Înregistrările video vor fi disponibile pe canalul TSM de Youtube: www.youtube.com/todaysoftmag, iar slide-urile prezentate au fost publicate pe www.issuu.com/todaysoftmag. Pentru a fi la curent cu ultimele noutăți, vă invităm să accesați pagina comunității IT Days: www.facebook.com/itdays.ro.

IT Days 2013 (I)


TODAY SOFTWARE MAGAZINE evenimente

Startup Weekend – Aici şi Acolo startups

(de adaugat) Visul american a creat anumite așteptări și asupra evenimentelor organizate. Așa s-a întâmplat de exemplu cu Startup Weekend. Deși niciodată vocife-rată, ideea că Startup Weekend în Cluj nu va fi la fel de cool era cumva în spatele tuturor observaţiilor auzite în timpul prezentări-lor făcute. De’! Nu suntem în America și evenimentul va fi “mișto”, numai că va fi și românesc în același timp. I-am crezut... până la proba contrarie.

Am avut norocul să fiu implicată în echipa de organizare a Startup Weekend Montreal. Deși “norocul” meu nu a fost deloc noroc, a fost în primul rând dovada conceptului de “comunitate” pe care sus-ţinătorii Startup Weekend îl plasează în topul valorilor promovate.

Ajunsă acolo am avut și eu anumite așteptări de la colegii mei școliţi în stil american și cu abordare occidentală. Așteptările mele s-au spulberat rapid însă, când pe parcursul întâlnirilor organiza-torice și a evenimentului în sine dădeam exemple de ce făcusem noi la Cluj și feţele lor se întorceau uimite spre mine “Serios? Ce tare!”. Așa mi-am dat eu seama despre faptul că naţionalitatea noastră, ampla-sarea geografică, perioada comunistă și multe alte motive care sunt “de vină” nu sunt decât scuze. Spiritul creativ, ingeni-ozitatea, inteligenţa și motivarea noastră sunt de multe ori net superioare calităţilor americanilor atât de mult lăudaţi. Probabil, diferenţa este lenea sau timiditatea.

Desigur evenimentul organizat sub franciză respecta valorile care l-au impus în lumea antreprenorilor de peste totEducaţia

și posibilitatea de a valida ideea, ajuto-rul primit de la oameni cu experienţă și energia care aproape explodează la fiecare eveniment sunt la fel, indiferent de poziţia de pe hartă.

Energia și atmosfera evenimente-lor cred că merită un loc aparte. Pornind de la prejudecăţile anterior menţionate, aveam așteptări și aici. Spre surprinderea mea, când la întrebarea unui voluntar dacă există diferenţe între evenimentele la care am participat, răspunsul meu a fost nega-tiv – oamenii pasionaţi sunt peste tot la fel, plini de viaţă, cu idei trăznite, cu poftă de lucru și dornici de a schimba status quo-ul în care se află.

Datorită evenimentului am avut ocazia să vorbesc și cu oameni implicaţi pe partea de finanţare de startup-uri. Tinerii antre-prenori au fost la fel de reticenţi ca și cei de aici – e greu să obţii investiţii și suport pentru proiectul și ideea ta. Investitorii au fost și ei sceptici – calculele făcute înainte de a face următorii pași într-o companie sunt multe și amănunţite.

Cred că am ajuns şi la diferenţe…Unul dintre aspectele pe care le-am

menţionat imediat în timpul discuţiilor cu antreprenorii de acolo a fost nivelul de cunoaștere a conceptelor implicate. Hustler, hacker, customer validation, business plan: sunt lucruri despre care ei par să fie mai documentaţi.

Partea legală prosperă în America. Dacă în Cluj pașii urmăriţi în momentul în care zici că faci un startup sunt în primul rând materializarea ideii iar apoi planul de

monetizare, în Montreal al doilea pas este vizita la avocat. Nimic și niciodată nu se face fără un consult legal, iar avocaţii sunt și ei interesaţi să susţină activ dezvoltarea mediului antreprenorial – ei chiar cred în conceptul de win-win situation.

Desigur că mulţi vor spune că diferența este legată de continuitatea proiectelor după eveniment. Dacă vorbim din punct de vedere statistic, Montreal o duce mai rău. Acolo doar două echipe (Crowdmedia, Dashboard) din cele participante au reușit să ajungă în incubatoare și să continue proiectele. În Cluj sunt 3 după doar 2 ediţii (Usetogether, Doitfor, Omnipaste) și recent am aflat că după doi ani unul dintre proiec-tele din prima ediţie urmează să fie lansat (Evolso).

În momentul de faţă, când pregătirile-pentru următorea ediţie Startup Weekend Cluj au început, sunt mai optimistă ca altadată. Pe lângă notorietatea și succe-sul recunoscut ale evenimentului pe plan local, m-am convins din propria experienţă că putem și noi să fim cool și să venim cu mind-blowing ideas la care americanii nici măcar nu visează.

Nu știu cum sunt alţii, însă eu de mic copil am perceput America precum ţara tuturor posibilităţilor și realizărilor. În viziunea mea, America ar cuprinde întreg continentul nord american, dacă aș lua în considerare orașele canadiene care au obţinut în lumea inovaţiilor o greutate similară cu cele din SUA. Pentru confirmare căutaţi povestea centrului Mars din Toronto.

Irina [email protected]

HR@ Skobbler


De aceea, inovația a trebuit să își găsească casă bună între miile de lacuri reci ale Finlandei. Este motivul principal pentru care economia acestei țări nordice se situ-ează în mod constant între primele cinci cele mai competitive din lume.

România este situată pe penultimul loc într-un clasament al prezenței inovației în rândul țărilor membre UE, în fața doar a Bulgariei (un loc obișnuit pentru noi), conform raportului European Innovation Scoreboard pentru anul 2013. Figura de mai jos arată, elocvent, distanța dintre sta-tul nostru și cele mai inovative țări din UE. Provocarea este, într-adevăr, formidabilă.

Sursa: Innovation Union Scoreboard

2013, Comisia Europeană

De ce este totuși important ca o țară în general, organizații și indivizi, în parti-cular, să producă inovație? Este ceva spre

care trebuie să tindem? Pentru un posibil răspuns ar trebui să ne uităm la câteva date. Vom folosi ca punct de plecare figura de mai sus.

Cel mai inovativ stat membru al UE este Suedia, o țară a cărei economie este considerată a 4-a cea mai competitivă din lume din cele144 care au fost auditate 1. Un singur alt stat membru UE este mai com-petitiv: Finlanda deja menționată. PIB-ul Suediei este de 56.956$ în timp ce venitul mediu după impozitare este de 26.242$. Aproximativ 74% din persoanele cu vârsta cuprinsă între 15 și 64 de ani din Suedia au o slujbă plătită2. Slovenia, plasată ime-diat sub media europeană în Innovation

Union Scoreboard pentru anul 2013 este cea de-a 56-a economie a lumii din punct de vedere al competitivității, cu un PIB de 24.533$, un venit mediu după impo-zitare de 19.119$ în timp ce populația activă este ocupată în proporție de 64%. Ungaria, țara vecină nouă, este clasată pe locul 22 din cele 27 de state mem-bre ale UE în ceea ce privește prezența

inovației, economia fiind a 60-a din punct de vedere al competitivității. PIB-ul este de 14.050$, venitul mediu după impozitare

1 World Economic Forum’s Global Competitiveness Report for 2012-2013

2 OECD Better Life Index

Voi deschide acest scurt text citându-l pe CEO-ul care a reinventat Nokia. Nu mă refer la Nokia de astăzi , ci la cea din anii ‘80 și care a devenit apoi întreprinderea gigant pe care o știm cu toții. Iată ce spunea J.O. Nieminen, CEO al Nokia Mobira

în 1984: Atunci când un inventator din Sillicon Valley deschide ușa garajului său pentru a face cunoscută ideea nouă pe care a avut-o el are în față 50% din piața lumii. Atunci când un inventator din Finlanda face același lucru, are în față un metru de zăpadă.

Inovația sau despre cum să

influențezi viitorul

business

Andrei [email protected]

Director executiv@ IT Cluster



este de 13.858$ în timp ce rata de ocu-pare a populației active este de 56%. Cred că lucrurile devin suficent de clare: cu cât o țară este mai inovativă cu atât este mai bună viața indivizilor țara respectivă. Mai multe persoane au un loc de muncă și sunt plătite mai bine.

Acum că avem un răspuns la prima întrebare (de ce este importantă inova-rea?), vom arăta ce înseamnă de fapt inovarea. O teorie larg acceptată (subliniez termenul teorie) este că într-un sistem în care inovația este posibilă, regăsim ele-mente cum ar fi cererea pentru inovație (nevoia), condiții externe care stabilesc cadrul (legislație, impozitare), sistemul industrial compus din companii mari, IMM și startup-uri, sistemele educaționale și de cercetare, organizațiile catalizator (sau instituții pentru colaborare), sistemele poli-tice și infrastructura (inclusiv drepturile de PI, capitaluri de risc, business angels și standarde)3 .

Lucrurile par complexe, într-adevăr, însă ținând cont de impactul deosebit al inovației asupra vieții fiecăruia dintre noi, nu putem face abstracție cu ușurință de acest proces. Cluj IT a acceptat această provocare: cel mai important obiectiv al membrilor organizației noastre este să facilităm tranziția de la afacerile bazate pe outsourcing la cele construite pe inovație. Din această perspectivă dorim să creem acel cadru prin care capacitățile de cer-cetare și inovare sunt direcționate către companiile noastre în așa fel încât această tranziție să fie nu numai posibilă, dar și probabilă. Desigur, unii s-ar putea să nu reușească, dar fără această încercare eșecul este garantat.

Întrebarea cum facem aceste lucruri să se întâmple, devine inevitabilă. O parte a răspunsului este că nu trebuie să reinven-tăm roata. Alții, înaintea noastră, au avut în față provocări similare și au pavat drumul cu reușitele și eșecurile lor. O altă parte a răspunsului este să admitem că, deși rețeta este simplă, problema principală o repre-zintă alinierea ingredientelor potrivite. Dacă ne uităm la ceea ce necesită un sis-tem productiv al inovației și dacă facem o analiză, chiar și scurtă, a listei putem identifica acele zone unde noi, ca indus-trie, trebuie să intervenim. În unele situații această intervenție presupune o construcție de la zero, deoarece nu există nimic de la care să pornim. Clusterul Cluj IT conso-lidează, gradual, acest sistem cu intenția

3 Arnold E. and S. Kuhlman (2001). RCN in the Norwegian Research and Innovation System. Background Report no. 12 in the evaluation of the Research Council of Norway. Brighton, Technopolis

ca în 5-7 ani de acum încolo inovația în cadrul companiilor membre să fie o prac-tică comună. Rând pe rând, încercăm să definim, creăm, îmbunătățim, legăm ele-mentele unui sistem de inovare funcțional cu scopul final de a asigura supraviețuirea și dezvoltarea companiilor noastre prin creșterea competitivității la nivel global. Am adus și aducem la aceeași masă per-soane, organizații și industrii din domeniile cele mai diverse.

Citeam zilele trecute un raport recent al Ericsson privind predicțiile în materie de progres tehnologic pentru anul 2014. Fără excepție toate se bazează pe avans în IT, ceea ce nu este în sine o supriză. Remarcabil este totuși faptul că toate aceste tendințe vor avea impact asupra vieții per-

sonale a fiecăruia dintre noi. Tehnologia devine parte integrantă a obiceiurilor noas-tre de zi cu zi, ceea ce înseamnă că există o nevoie confirmată de inovație, de găsire a unor noi soluții de îmbunătățire a vieților noastre și a comunităților din care facem parte. Acest lucru poate duce la acel avan-taj competitiv care departajează afacerea noastră de a altora. Suntem în stare sau nu să facem față provocării de a fi printre cei care influențează viitorul? Răspunsul ne aparține tuturor.



organizatorii IT Camp. Pe cei ce activează în zona de startup-uri, îi invităm să participe la săptămâna de mentorat: Startup Pirates !

Transylvania Java User GroupComunitate dedicată tehnologiilor Java.Website: www.transylvania-jug.orgData înfiinţării: 15.05.2008 / Nr. Membri: 561 / Nr. Evenimente: 44

Comunitatea TSMComunitate construită în jurul revistei Today Software Magazine.Website: www.facebook.com/todaysoftmagData înfiinţării: 06.02.2012/Nr. Membri: 1103 /Nr. Evenimente: 17

Romanian Testing CommunityComunitate dedicata testerilor.Website: www.romaniatesting.roData înfiinţării: 10.05.2011 / Nr. Membri: 690 / Nr. Evenimente: 2

GeekMeet RomâniaComunitate dedicată tehnologiilor web.Website: geekmeet.roData înfiinţării: 10.06.2006 / Nr. Membri: 571 / Nr. Evenimente: 18

Cluj.rbComunitate dedicată tehnologiilor Ruby.Website: www.meetup.com/cluj-rbData înfiinţării: 25.08.2010 / Nr. Membri: 166 / Nr. Evenimente: 36

The Cluj Napoca Agile Software Meetup GroupComunitate dedicată metodelor Agile de dezvoltare software.Website: www.agileworks.roData înfiinţării: 04.10.2010 / Nr. Membri: 379 / Nr. Evenimente: 40

Cluj Semantic WEB MeetupComunitate dedicată tehnologiilor semantice.Website: www.meetup.com/Cluj-Semantic-WEBData înfiinţării: 08.05.2010 / Nr. Membri: 16 2/ Nr. Evenimente: 23

Romanian Association for Better SoftwareComunitate dedicată oamenilor cu experiență din IT indiferent de tehnologie sau specializare.Website: www.rabs.roData înfiinţării: 10.02.2011 / Nr. Membri: 234/ Nr. Evenimente: 14

Tabăra de testareUn proiect care își dorește să strângă cât mai mulți oameni care lucrează ca și testeri.Website: tabaradetestare.roData înfiinţării: 15.01.2012 / Nr. Membri: 491/ Nr. Evenimente: 21

Bine v-am găsit în 2014. Începem anul cu o mulțime de evenimente interesante. Îi invităm pe cei din Cluj să participe la eve-nimentul lunar de lansare a fiecărei reviste. De asemenea, vom încerca în acest an să extindem aria în care se desfășoară evenimentele TSM, încercân să le oferim și celor din alte orașe accesul la desfășurarea evenimentului. Luna aceasta vă reco-

mandăm participarea la CodeCamp-urile organizate în Cluj, Brașov și Sibiu de către vechiul nostru colaborator Radu Vunvulea și

Calendar Ianuarie 17 (Cluj)Lansarea numărului 19 al Today Software Magazinewww.todaysoftmag.ro

Ianuarie 17 (București)TechPeaks Accelerator Presentation in Bucharestit-events.ro/events/techpeaks-accelerator-presentation-bucharest/

Ianuarie 18 (Cluj)Hacaton de GNUhttp://formulare.ceata.org/hgcj201401/

Ianuarie 18 (Cluj) - 24 (Brașov) - 25 (Sibiu)Codecamp de iarnă - recomandare TSMit-events.ro/events/codecamp-de-iarna-la-cluj-napoca/

Ianuarie 23 (Cluj)Let’s meet up and ...Project Management - PMIclujhub.ro/eveniment/project-managers-meetup-4-2/

Ianuarie 25 (Cluj)Drupal Global Sprint Weekendhttp://www.meetup.com/Drupal-Cluj/events/159783472/

Ianuarie 27 (Cluj)Mobile Monday #4clujhub.ro/eveniment/mobile-monday-4/

Ianuarie 29 (Cluj)The javascript timisoara group Meetup 5it-events.ro/events/javascript-timisoara-group-meetup-5/

Ianuarie 29 (București)Agility Path, agile adoption, flawed Scrum adoptionmeetup.com/The-Bucharest-Agile-Software-Meetup-Group/events/146223122/

Februarie 1 (Iași)Integration Cucumber with Seleniumit-events.ro/events/integration-cucumber-selenium-dragos-puscasu/

Februarie 8 (Cluj)Startup Pirates - recomandare TSMcluj.startuppirates.org

Comunităţi IT

comunități

http://www.transylvania-jug.org

http://www.romaniatesting.ro

http://geekmeet.ro

Cluj.rb

http://www.meetup.com/cluj

http://www.agileworks.ro

http://www.meetup.com/Cluj

http://www.rabs.ro


TODAY SOFTWARE MAGAZINE programare

În urmă cu mai bine de patru luni Today Software Magazine a realizat un partene-riat cu 3Pillar Global pentru a implementa o soluție ce facilitează utilizatorilor iPhone/iPad accesul la articolele Today Software Magazine , dar și socializarea în jurul aces-tora prin mijlocirea partajării articolelor, amplificând puterea creativă a tuturor pentru beneficiul comun. Iată că această colaborate continuă cu o soluţie similară dar, de data aceasta, pe o platformă Android

https://play.google.com/store/apps/details?id=com.tpg.tsm.ui&hl=ro

Începutul colaborăriiExistă multe asemănări și diferenţe

între cele două soluţii. Una dintre diferenţe este aceea că clientul realizat pe platformele iPhone/iPad a pornit de la zero în timp ce versiunea Android a avut un model func-ţional la dispoziţie (lucru care nu a fost întotdeauna un avantaj). De asemenea, multitudinea de rezoluţii existente pentru terminalele ce folosesc Android a condus la modificări sau uneori la o regândire com-pletă a interfeţei cu utilizatorul. Nu în ultimul rând, un interesant aspect este poate acela că întreaga echipă de dezvoltare a soluţiei, formată din patru persoane (un Technical Manager, doiprogramatori și un tester), este parte a 3Pillar Global India care în șase săptă-mâni a acoperit tot efortul de implementare necesar demonstrând (dacă mai era nevoie)

că diferenţa de fus orar nu mai reprezintă un factor perturbator în industria IT.

Echipa de dezvoltare a urmat principi-ile enunţate în Adaptive Product Lifecycle Management (un model de dezvoltare uti-lizat intern în 3Pillar Global și care a fost definit în jurul metodologiei Agile Scrum), dezvoltarea fiind segmentată pe trei sprinturi (fiecare având câte o temă specifică) a câte

Fără doar și poate revista Today Software Magazine reprezintă unul dintre elementele ce se afirmă tot mai pregnant în comunitatea IT din Cluj Napoca și nu numai, trans-formându-se într-o portavoce prin care profesioniști în diverse domenii din industria

sofware își etalează expertiza profesională, partajează bune practici din domeniu și caută împreună soluţii la probleme specifice industriei.

Clientul Today Software Magazine pentru Android

3Pillar Global Team India

@ 3Pillar Global





două săptămâni. Ast fe l , l a f ine le

fiecărui sprint a fost prezentat căte un demo util în ajustarea cores-punzătoare a soluţiei pentru a acoperi cât mai bine nevoile de a accesa eficient conţinu-tul seriei Today Software Magazine.

Pentru urmărirea progresului proiectului s-a utilizat Jira, toate task-urile fiind create ca user story-uri și fiind asignate membrilor echipei de dezvoltare. Ca sistem de control al fișierelor s-a utili-zat GIT, fiind creat un branch de dezvoltare la începutul primului sprint. Pentru eliminarea conflictelor, acest branch era inclus în branch-ul master la finalul fiecărui sprint (evident după revizuirea colectivă a codului).

Discuţiile iniţiale s-au concentrat în principal pe respectarea design-ului și a funcţionalităţilor implementate în versiunile pre-cedente de iPhone/iPad ale soluţiei. Au existat, desigur, o serie de adaptări la specificul înterfeţei utilizator Android dar, în același timp, au fost propuse mai multe modificări ce au fost ulterior acceptate. Printre cele mai importante modificări implementate în raport cu versiunea iOS a clientului Today software Magazine amintim:

• Actualizare: S-a propus implementarea a două modalităţi de informare a utilizatorilor despre conţinutul nou ce a apărut între timp în cadrul revistei. O variantă este dată de utilizarea de notificări push ce vor semnala că este conţinut nou, iar utilizato-rii vor putea să facă o actualizare explicită. A doua metodă este prin punerea la dispoziţie a unei funcţionalităţi de actualizare manuală ce va permite utilizatorilor să decidă când doresc să verifice conţinutul. Într-un final s-a optat pentru implementa-rea celei de-a doua variante.

• Partajarea în reţelele de socializare: Partajarea a diferite articole ale revistei pe Facebook sau Twitter s-a realizat prin folosirea unei biblioteci Android proprietare 3Pillar Global, care permite partajarea de conţinut pe reţelele de socializare chiar dacă utilizatorul nu are instalate Facebook sau Twitter pe pro-priul dispozitiv.

• Suport pentru Android GingerBread 2.3.3, deoarece la momentul dezvoltării acesta reprezenta 25% din piaţa de dis-pozitive Android (statistică preluată din Android Market). În plus s-a sugerat portarea aplicaţiei pe tablete de 7’’ din aceleași considerente de popularitate în rândul utilizatorilor Android.

Arhitectura aplicaţiei

Imediat după lansarea în execuţie, aplicaţia afișează un splash screen ce permite selectarea limbii de utilizare: română sau engleză. După alegerea limbii aplicaţia afișează coperta ultimului număr al revistei și lista articolelor acestui număr (preluate de pe web serverul TSM). În background se încarcă datele corespunză-toare articolelor într-o bază de date SQLite și în memoria internă (dacă este cazul).

În partea stângă a ecranului, selectând meniul din action bar se poate consulta lista tuturor numerelor revistei (fiecare fiind repre-zentată de coperta sa), iar în panoul din dreapta este afișată mereu lista articolelor numărului curent selectat.

Selectarea oricărui articol din listă va avea ca efect afișarea conţinutului acestuia precum și detalii despre autor. Prin selec-tarea butonului Share, se poate opta prin intermediul unui meniu pop-up pentru partajarea articolului pe platforme ca Facebook, Twitter sau e-mail.

programare

www.3pillarglobal.com

3Pillar Global, a product development partner creating software that accelerates speed to market in a content rich world, increasingly connected world.

Our core competencies include:

ProductStrategy

ProductDevelopment

ProductSupport

Our offerings are business focused, they drive real, tangible value.



De asemenea, limba selectată pentru afișare poate fi modifi-cată prin selecţia meniului Settings din action bar. La selectarea unei noi limbi aplicaţia va șterge toate datele stocate și va reîncepe încărcarea conţinutului de pe serverul TSM folosind noua limbă selectată.

Bibliotecile şi instrumentele utilizatePentru implementarea soluţiei au fost utilizate următoarele

medii, instrumente și biblioteci:• Eclipse: Eclipse IDE a fost utilizat ca mediu de dezvoltare.• Charles Proxy : a fost utilizat pentru testarea API și pentru

verificarea funcţionării aplicaţiei corespunzătoare iPhone.• SocialAuth Android Library (http://code.google.com/p/

socialauth-android/) : bibliotecă dezvoltată intern ce permite autentificarea unui utilizator și partajarea de informaţii în diferite reţele de socializare ascunzând detalii de conectare. Biblioteca a fost utilizată pentru partajarea articolelor pe diverse reţele sociale și e-mail.

• Android-app-v7-appcompat: Deoarece action bar-ul este implementat doar începând cu Android 4.0, această bibliotecă permite afișarea unui action bar și în versiuni inferioare de Android. Implementare acestui action bar elimină dependenţa de butonul de opţiuni din Android.

• I3P Android: Reprezintă o altă componentă dezvoltată intern în cadrul 3Pillar Labs, utilizat în crearea barei de navi-gare din partea stângă.

ProvocăriUrmătoarele secţiuni prezintă câteva dintre provocările rezol-

vate cu succes de echipa de dezvoltare. În fiecare caz este descrisă problema și modul în care a fost rezovată.

Optimizarea imaginilor

ProblemaÎn ecranul principal al aplicaţiei este prezentată lista articole-

lor numărului selectat împreună cu pozele autorilor. Dimensiunea imaginilor originale aflate pe server trebuia redusă pentru a evita erori de tipul OutOfMemory ce conduceau la întreruperea aplica-ţiei pentru anumite scenarii particulare.

SoluţiePentru a soluţiona eficient problema s-a utilizat metoda bitmap

sampling care reprezintă un procedeu prin care se reduce dimensi-unea unei imagini. Provocarea în acest caz a constat în menţinerea raportului de aspect al imaginii originale, nealterându-se calitatea imaginii redimensionate. În continuare, este prezentat un frag-ment de cod care calculeze dimensiunea imaginii reduse:

Calcul dimesiune imagine redusă

public int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) { finalintheight=options.outHeight; finalintwidth=options.outWidth; if(height<0||width<0) return-1; intinSampleSize=1; finalintheightRatio=Math.round((float)height/(float)reqHeight); finalintwidthRatio=Math.round((float)width/(float)reqWidth); inSampleSize=heightRatio<widthRatio?heightRa-tio:widthRatio; returninSampleSize;}

Crearea noii imagini

public Bitmap sampleBitmap(BitmapFactory.Options options,int reqWidth, intreqHeight,TSMBaseActivityactivity,Stringid,InputStreamimageR-esponse,StringimagePath)throwsIOException{intsampleSize=calculateInSampleSize(options,reqWidth,reqHeight);if(sampleSize>=0){ options.inJustDecodeBounds=false; options.inSampleSize=sampleSize; if(haveNetworkConnection(activity.getBaseContext())){ try{ imageResponse=newHttpRequest(activity.getBaseContext()).getHttpInputStream(imagePath);//FileNotFoundExcep-tion,MalformedUrlException }catch(IOExceptione){ e.printStackTrace(); if(einstanceofSocketException||einstanceofSocketTimeoutException){ } returnnull; } if(imageResponse!=null){ Bitmapbmp=BitmapFactory.decodeStream(imageResponse,null,options); if(bmp==null) returnnull; saveToInternalSorage(bmp,activity,id); returnbmp; } }}returnnull;}

Redarea filmelor Youtube

ProblemaO serie de articole de pe serverul TSM conţin filme Youtube

inserate. Redarea acestor filme în componenta de vizualizare a paginii web reprezintă o provocare deoarece nu avem control asupra acesteia. De asemenea, implementarea variază în funcţie de dispozitiv (Gingerbread și ICS). De exemplu, pe dispozitivele Gingerbread filmele Youtube se redau automat în varianta full screen, în timp ce pe dispozitive ICS sau mai vechi utilizatorii tre-buie să selecteze manual opţiunea de full screen.

SoluţieS-au implementat abordări distincte pentru dispozitivele

Gingerbread și ICS. Pentru Gingerbread s-a utilizat controlul Android implicit Videoview în timp ce pentru dispozitive ICS (sau mai vechi) s-a utilizat Java Reflection API pentru redarea similară



programare

a filmelor. Utilizând Reflection API se obţine referinţa la HTML5VideoFullScreen$VideoSurfaceView din webkit și este redat filmul în full screen. Pentru ambele versiuni sunt redate mai jos exemple de cod:

YouTube video in Android 2.3.3VideoViewcustomVideoView=(VideoView)customViewContainer.getFocused-Child();FieldmUriField=VideoView.class.getDeclaredField(“mUri”);mUriField.setAccessible(true);Uriuri=(Uri)mUriField.get(customVideoView);

YouTube video in Android 4.0Class_VideoSurfaceView_Class_=Class.forName(“android.webkit.HTML5VideoFullScreen$VideoSurfaceView”);java.lang.reflect.Field_HTML5VideoFullScreen_Field_=_VideoSurfaceView_Class_.getDeclaredField(“this$0”);_HTML5VideoFullScreen_Field_.setAccessible(true);Object_HTML5VideoFullScreen_Instance_=_HTML5VideoFullScreen_Field_.get(((FrameLayout)view).getFocusedChild());

Îmbunătăţirea performanţelor aplicaţiei

ProblemaÎntr-o primă fază transferul asincron al datelor TSM și pre-

zentarea acestora în interfaţa utilizator dura aproximativ 20-25 minute. Pentru a reduce din timpul de transfer au fost create mai multe procese care transferau datele în paralel de pe server, crescând astfel viteza de download. Provocarea în acest context a constat din sincronizarea datelor între procese și evitarea oricărui conflict (de exemplu, pozele autorilor nu puteau fi transferate până când nu se transferau informaţiile despre autori, deoarece calea imaginii de transferat era conţinută în aceste informaţii). Prin urmare, provocarea a constat în optimizarea timpului de transfer al datele și în îmbunătăţirea performanţei generale a aplicaţiei.

SoluţieCa soluţie s-a implementat ThreadPoolExecutor și toate task-

urile au fost atașate executorului. Iniţial s-au creeat 2 thread-uri care se executau în paralel. După ce execuţia acestora se finaliza, următoarele thread-uri erau extrase din coadă pentru transferul datelor în funcţie de acţiunile de navigare ale utilizatorului.

ThreadPoolExecutorexecutorPool=newThreadPoolExecutor(2,2,60,TimeU-nit.SECONDS,newArrayBlockingQueue<Runnable>(2),threadFactory);executorPool.execute(newLoadIssueImages(handler,language,getBaseContext()));executorPool.execute(newLoadIssueArticles(handler,language,getBaseContext()));executorPool.execute(newLoadAuthorInformation(handler,language,get-BaseContext()));executorPool.execute(newLoadAuthorImages(handler,language,getBaseContext(),this));

TestareaAplicaţia a fost testată pe următoarele dispozitive: Nexus 4

(Android 4.3) , Nexus 7(Android 4.1, 7’’ Tablet) , HTC Desire (Android 2.3.3 , 480x800) și Samsung Tab(7”,10”) , Galaxy Y(240x320).

Selecţia dispozitivelor s-a făcut pentru a acoperi un număr cât mai mare de potenţiali utilizatori de telefoane/tablete Android. Aplicaţia a fost testată în următoarele contexte:

• Testarea lansării în execuţie pentur prima dată: După instala-rea cu succes a aplicaţiei se crează un icon, la selectarea acestuia fiind lansată aplicaţia în execuţie prin afișarea unui splash screen iniţial.

• Testare API: S-a verificat și validat funcţionarea similară a soluţiei Android cu soluţia pentru iPhone/iPad pentru a se garanta furnizarea unei experienţe similare.

• Testarea reţelei și a conexiunii la Internet: S-a verificat apli-caţia în condiţiile unor probleme de conectare la internet în momentul în care se dorește transferarea datelor.Utilizatorii vor

primi mesajul de eroare “Network error. Please try again later” • Stress testing reprezintă un mod de a asigura stabilitatea

soluţiei dezvoltate prin apăsarea în secvenţa rapidă a diverse butoate/link-uri/imagini etc. . Astfel, aflându-se în situaţia de a servi mai multe cereri în același timp au fost detectate mai multe defecţiuni.

• Testare cu diterite tipuri de reţea: Aplicaţia a fost testată pe mai multe tipuri de reţele, cum ar fi: 2G, 3G și Wi-Fi.

• Testarea pe dispozitive cu rezoluţii diferite: Aplicaţia s-a testat pe o diversitate de rezoluţii în intervalul 240x320 și 1280x800 asigurându-se faptul că aplicaţia funcţionează corespunzător pe diferite rezoluţii.



TODAY SOFTWARE MAGAZINE business

Despre respectarea valorilor companieiAșa cum respectarea unor reguli susține

un comportament continuu (gândiți-vă la regulile de circulație care, prin impunerea respectării lor, urmăresc evitarea accidente-lor), în același mod și respectarea unor valori, în contextul unei companii IT, urmărește susținerea unui ritm de maturizare. Valorile sunt relevante mai ales pentru o companie care se află în continuă dezvoltare, existența și asumarea acestora având impact atât pentru angajați, cât și pentru companie.

Departe de a exista doar pe o secțiune de pe site-ul companiei denumite „Valori”, aces-tea au, în realitate, o relevanță crescută mai ales pentru companiile furnizoare de ser-vicii, în cazul cărora validarea calității fiind preponderant mijlocită. Ce înseamnă acest lucru? - Acțiunile, procesele, modurile de organizare și comunicare, atitudinea în rezol-varea problemelor – demonstrează calitatea serviciilor și au întâietate „calității codului”. Mai mult, acestea sunt elemente care contri-buie la crearea unei percepții mai clare și mai ample asupra calității pe care o poate livra o companie de IT – la nivel de servicii și nu doar de software development.

De altfel, referitor la o piață externă, asumarea unor valori presupune abilitatea de a răspunde prin intermediul modului de

lucru exigențelor culturale impuse de valorile respective. Un bun exemplu este punctuali-tatea. Este o valoare cel mai des regăsită în cultura germană. Odată asumată în relația cu un client de naționalitate germană, e o asumare a faptului că înțelegem exact ce pre-supune „punctualitatea germană”.

Când devin valorile resurse strategice? • Înainte de toate, atunci când sunt for-

mulate astfel încât să poată fi asumate atât la nivel individual, cât și la nivel de echipă. Specific pentru domeniul IT, valorile devin strategice în măsura în care acestea au un impact pozitiv în colaborarea cu ceilalți membri ai echipei, dar și cu membrii echi-pei din partea clientului.

• Dacă deja există, dar nu au fost stabi-lite decât sumar la început, acestea pot fi identificate drept resurse strategice când pot fi corelate cu acțiuni și comporta-mente ale angajaților. Întrebări precum: - Ce apreciază clienții în colaborarea cu membrii echipei? - Care sunt tipurile de comportamente cel mai des întâlnite în cadrul echipelor? - Care sunt dinamicile de învățare și formare a unei echipei? – vă pot ajuta să le identificați și definiți mai ușor.

• Atunci când sunt cunoscute și asu-mate de către membri ai organizației.

Deși ați putea spune că „valoarea ca strategie” ar putea fi aplicabilă pentru orice tip de companie, principiul de dezvoltare strategic din spatele acestei sintagme lasă suficient loc pentru detalierea unor oportunități care nu sunt de ignorat – mai

ales pentru companiile IT. „Valoarea ca strategie” înseamnă folosirea valorilor companiei drept pârghii pentru a controla și defini procese, mod de lucru, direcții de dezvoltare și comunicare.

Valoarea ca strategieValorile companiei ca factor de dezvoltare și

recunoaștere pe piețele externe

Cornelia [email protected]

Communications Officer@ Accesa



businessValoarea ca strategie

Simplu – atunci când valorile reușesc să ghideze direcții de acțiune și comporta-ment vorbim deja despre asumare. Un bun exemplu este acela în care recruta-rea noilor colegi are loc ținând cont de valorile companiei. Un alt bun exemplu este acela în care valorile sunt definite cu sprijinul întregii echipe, asigurând astfel transparența și buna înțelegere a acestora la nivel intern.

Impactul valorilor pentru angajați și companie

Din perspectiva dezvoltării, putem trece în revistă câteva perspective asupra valorilor:

• Existența și respectarea valorilor companiei sunt un indiciu pentru atenția acordată angajaților, la nivel individual.

• Valorile pot servi drept fundament creșterii și susținerii active a calității ser-viciilor IT furnizate.

• În funcție de valorile asumate de companie, oricare dintre acestea pot constitui criterii pentru evaluarea calității serviciilor, dar și a randamentu-lui angajaților.

• Valorile pot fi o sursă care, încă din stagiul recrutării, contribuie la păstrarea coeziunii echipei.

• Valorile pot fi o sursă de motivare a angajaților. Acestea pot fi valorificate la nivel intern punându-le în practică prin intermediul unor proiecte inovative,

inițiative ale angajaților pe care compa-nia le poate sprijini.

PhönixPreis, valorile companiei și recunoașterea pe plan european

PhönixPreis este distincția oferită companiilor străine care își desfășoară acti-vitatea în Germania și care s-au remarcat prin angajamentul social al creării de locuri de muncă și prin performanța de business. Aceasta este oferită de către Departamentul de Muncă și Economie, împreună cu Primăria orașului Munich.

Accesa se numără printre com-paniile care, la finele anului 2013, au acceptat distincția PhönixPreis la catego-ria „Established Company”. Premiul a fost acceptat în cadrul galei de decernare care a avut loc pe 4 decembrie în sala de banchet a Primăriei orașului Munich.

Valorile susținute de Accesa: pasiune, curaj, proactivitate, modestie și respect - au stat la baza acordării premiului de către juriu, fiind un fundament pentru dezvol-tarea companiei. Iulian Iuga, managerul

general Accesa, afirmă că „înscrierea în competiția PhönixPreis și acceptarea pre-miului au constituit oportunități de a-mi întări misiunea de dezvoltare a companiei.” Pentru Accesa, premiul PhönixPreis este o recunoaștere a perfomanței demonstrate de fiecare angajat, acum și de către comunita-tea din orașul Munich.

Din perspectiva dezvoltării de busi-ness, un astfel de premiu este reprezentativ pentru rolul managerilor de a fi vizionari dincolo de granițele propriei țări,de a inova și de a contribui la creșterea competitivității mediului extern în care își desfășoară activi-tatea. Astfel, includerea valorilor companiei în strategia de dezvoltare impune ca acestea să fie luate în considerare ca resurse pe ter-men lung, contribuind la diferențiere și la consolidarea punctelor forte ale companiei.



Un avantaj major adus de această nouă caracterist ică este portabi l ita-tea aplicațiilor, spre exemplu ușurința cu care o aplicație multithreading specifică Windows se poate transfera pe o platform iPhone sau Android. Un avantaj pentru cei familiarizați cu librăria boost threads este că multe concepte din librăria standard C++11 păstrează aceeași denumire și struc-tură ca și clasele din boost threads library. Librăria standard C++ Threads conține clase pentru manipularea thread-urilor, proteja-rea datelor comune, operații de sincronizare între thread-uri și operații atomice de nivel scăzut. În continuare, vom exemplifica și vom descrie în linii mari modul în care aceste con-cepte sunt prezente în standardul C++11.

Lansarea unui thread Declararea și lansarea unui nou thread în

C++11 este la fel de simplă precum declararea și intanțierea unui nou obiect. Vom analiza o aplicație simplă de multithreading pentru a exemplifica modul în care se pot folosi thread-urile din librăria standard C++. Spre exemplu:

#include <iostream>#include<thread>//--(1)

voidexecute(){ std::cout<<”HelloConcurentWorld”<<std::endl;}

int main(){ std::threadworker_thread(execute);//--(2) worker_thread().join();//--(3)}

Prima diferență este includerea header-ului #include<thread> (1). Acesta conține funcții și clase pentru managementul firelor de execuție. Thread-urile sunt lansate prin declararea unui obiect std::thread, care specifică în constructor o metodă inițială, în cazul nostru fiind metoda execute(), care reprezintă locul de unde noul thread își va porni execuția (2). După ce thread-ul a fost lansat și înainte ca obiectul std::thread să fie distrus, prin ieșirea din funcția main, trebuie specificat explicit dacă se dorește ca thread-ul principal să aștepte până când thread-ul secundar își încheie execuția, prin apelarea funcției join() (3), sau dacă thread-ul secundar va rula independent de ciclul de viață al thread-ului principal, prin apelarea metodei detached(). În acest caz thread-ul va rula în background, fără niciun mijloc de a comunica cu el. Thread-urile detașate se mai numesc și daemon threads, după conceptul din sistemele UNIX, în care un dae-mon process rulează în background fără a avea o interfață specifică.

Transmiterea parametrilor către funcția unui thread

Transmiterea parametrilor către un nou thread în C++11 este la fel de simplă precum transmiterea parametrilor unui obiect apelabil. Important este de reținut faptul că parametrii transmiși sunt copiați local în stiva thread-ului, de unde pot fi accesați de către thread-ul în execuție, chiar dacă parametrii corespun-zători din funcție așteaptă o referință. Spre exemplu:

După treisprezece ani de la publicarea primului standard C++, membrii comitetu-lui de standardizare au decis să ofere, odată cu publicarea noului standard C++11 sau C++0x, o schimbare majoră în ceea ce privește programarea multithreading.

Pentru prima dată, limbajul C++ oferă suport, independent de platforma de dezvoltare, pen-tru implementarea aplicațiilor ce presupun programarea concurentă. Înainte de standardul C++11, aplicațiile multithreading se bazau pe extensii specifice platformei, spre exemplu Intel TBB, OpenMP, Pthreads, etc. .

Multithreading în standardul C++11 (partea I)

programare

Dumitrița [email protected]

Software engineer@ Arobs


voidexecute(const std::string&filename);

std::threadworker_thread(execute,”input.dat”);

În acest caz se creează un nou thread, asociat variabilei wor-ker_thread, care apelează funcția execute(“input.dat”). Atenție, însă, la parametrul transmis. Chiar dacă funcția execute primește ca parametru o referință std::string, string-ul este transmis drept const char* și convertit numai în contextul noului thread către un std::string. Acest mecanism de funcționare a funcției std::thread poate conduce la două posibile probleme.

Primul caz ar fi cel în care parametrul transmis este un pointer către o variabilă locală. Spre exemplu:

voidexecute(const std::string&filename); voidoops(const char* parameter) { char buffer[50]; sprintf(buffer,“%s”,parameter); std::thread worker_thread(execute,buffer); //--(1) worker_thread.detach();

}

În acest exemplu, un pointer către variabila locală buffer este transmis către noul thread, care așteaptă în schimb un para-metru de tip std::string. Este foarte posibil ca funcția oops să își încheie execuția înainte de momentul în care conversia de la char* la std::string să aibă loc. Pointer-ul transmis devine un dangling pointer (1),iar comportamentul firului de execuție va fi nedefinit.

În această s ituaț ie ,soluț ia ar f i conversia expl i-cită a variabilei buffer către un std::string, înainte ca parametrul să fie transmis către constructorul noului thread:

std::thread worker_thread(do_work,std::string(buffer));

Al doilea caz ar fi cel în care parametrul transmis este copiat, chiar dacă intenția era de a se transmite o referință a obiectului a cărui valoare trebuia modificată de către thread. Spre exemplu:

voidexecute(std::string& str) //--(1) { str.assign(“HalloWelt!”); }voidoops(const char* parameter) { std::string greeting(“HelloWorld!”); std::thread worker_thread(execute,greeting);//--(2) worker_thread.join(); std::cout<< greeting << std::endl;//--(3) }

Chiar dacă funcția execute (1) așteaptă o referință ca parame-tru, constructorul noului thread nu știe acest lucru, motiv pentru care pur și simplu copiază intern variabila my_string. Când thread-ul apelează funcția execute (2), acesta va transmite ca parametru o referință la copia internă a variabilei greeting. În consecință, atunci când noul thread își va încheia execuția, variabila my_string , cu noua valoare“Hallo Welt”, va fi distrusă odată cu distrugerea copii-lor interne ale parametrilor transmiși în constructorul thread-ului. Din acest motiv, valoarea variabilei greeting va rămâne nemodifi-cată, afișând valoarea inițială “Hello World!” (3).

Soluția în acest caz ar fi transmiterea parametrilor, care trebuie să fie o referință, folosind funcția std::ref.

std::thread worker_thread(execute,std::ref(greeting));

Și această funcție std::ref este disponibilă doar odată cu standardul C++11, fiind o metodă folosită pentru a simula funcționalitatea unei referințe, astfel încât, în final varia-bila my_string (3) va avea valoarea modificată “Hallo Welt!”. Pentru cei familiarizați cu funcția std::bind, semantica transmiterii unui pointer către o funcție membră a unui obiect, ca parametru pentru constructorului unui std::thread, va fi surprinzătoare. Spre exemplu:

class Test { public: voidexecute(); }; Testcustom_test;std::thread worker_thread(&Test::execute,&custom_test);//-- (1)

Acest cod (1) va lansa un thread care va rula metoda custom_test.execute(). În cazul în care metoda execute() ar primi parame-tri, aceștia s-ar transmite în aceeași manieră, fiind al treilea, al patrulea ș.a.m.d parametru pentru constructorul thread-ului curent.

Transferarea posesiei unui threadSă presupunem că se dorește o funcție std::thread create_

thread() care să creeze un thread ce rulează în background dar care, în loc să aștepte ca noul thread să își termine execuția, returnează

programareMultithreading în standardul C++11 (partea I)



noul thread funcției din care a fost apelată. Sau putem presupune că funcția creează un thread și transmite proprietatea acestuia unei funcții oarecare, care trebuie să aștepte ca thread-ul nou creat să își încheie execuția. În ambele cazuri este necesară transferarea posesiei unui std::thread care, la fel ca un std::ifstream sau std::unique_ptr, poate fi transferat, dar nu copiat. Spre exemplu:

voidsome_function(int n);

std::threadcreate_thread() { std::thread my_thread(some_function,24); return my_thread; } std::thread first_thread(some_func-tion,25); //-- (1)std::thread second_thread= std::move(t1);//-- (2)first_thread=create_thread();//-- (3)

Mai întâi este lansat un nou thread (1) și asociat cu variabila first_thread. Posesia acestui thread este apoi transferată către variabila second_thread (2). Următorul transfer de posesie (3) nu necesită un apel către funcția std::move, deoarece posesorul curent este un obiect temporar, iar transfe-rul este automat și implicit.

Mecanisme de sincronizarePentru sincronizarea între thread-

uri, standardul C++11 pune la dispoziție reprezentări ale mecanismelor cla-sice de sincronizare precum mutex-uri (std::mutex, std::recursive_mutex, etc.), variabile condiționale (std::contition_vari-able, std::condition_variable_any), ce pot fi acceste prin intremediul unor RAII locks (resource acquisition is initialization, std::lock_quard si std::unique_lock), precum și mecanisme numite futures and promises, utilizate pentru transmiterea rezultatelor între thread-uri sau std::package_task pen-tru a “ambala” un apel către o funcție care poate genera un astfel de rezultat.

MutexÎn exemplele anterioare am văzut

cum se poate lansa și cum se pot trans-mite parametrii către funcția unui thread. Acest mecanism nu este însă suficient atunci când se dorește ca anumite resurse să poată fi utilizate (modificate) de mai multe thread-uri care rulează simultan. În această situație este necesară utilizarea unui mecanism de excludere mutuală, care să asigure integritatea datelor atunci când există posibilitatea ca mai multe thread-uri să modifice aceeași resursă, în același timp.

Cea mai utilizată primitivă de sincro-nizare este un mutex. Înainte de a accesa resurse care pot fi modificate simultan de către thread-uri diferite, un thread tre-buie să blocheze mutex-ul asociat resursei comune ,iar când thread-ul nu mai ope-rează asupra datelor comune, acesta trebuie deblocat. În cazul în care un mutex este deja blocat și un alt thread încearcă să îl blocheze din nou, acesta trebuie să aștepte până când thread-ul care a blocat cu succes mutex-ul, îl deblochează.

Standardul C++11 oferă primitiva std::mutex, care poate fi folosită prin includerea header-ului #include <mutex>. Un obiect std::mutex pune la dispoziție și funcții membre, lock() și unlock(), pentru a bloca sau debloca explicit un mutex. Cel mai frecvent caz de utilizare a mutex-ului este atunci când se dorește protejarea unui anumit bloc de cod. În acest sens este oferit de către librăria stan-dard C++ și template-ul std::lock_guard<>, al cărui mecanism se bazează pe principiul RAII (resource aquisition is initialization). În constructorul obiectului std::lock_quard, mutex-ul este blocat, iar în destructor mutex-ul este automat deblocat. Spre exemplu:

std::mutexmy_mutex;unsigned intcounter=0;

unsigned int increment(){ std::lock_quard<std::mutex>

lock_counter(my_mutex); return++counter;}unsigned int query(){ std::lock_quard<std::mutex> lock_counter(m); returncounter;}

În acest exemplu, accesul la variabila counter este serializat. Dacă mai mult de un thread apelează concurent metoda query(), atunci acestea vor fi blocate, până când singurul thread care a blocat cu succes mutex-ul îl va debloca. Deoarece ambele funcții blochează același mutex, dacă un thread apelează query() iar altul incre-ment(), în același timp, atunci doar unul dintre ele va reuși să blocheze mutex-ul și să acceseze variabila counter.

Atunci când este pusă în discuție tratarea excepțiilor, o variabilă de tip std::lock_quard<> aduce beneficii supli-mentare comparativ cu deblocarea manuală, prin apelarea directă a metode-lor lock() și unlock() asupra unui mutex. Atunci când se folosește blocarea manu-ală, trebuie asigurat faptul că mutex-ul este deblocat la fiecare punct de ieșire din regiunea protejată de către mutex, inclusiv în regiunile care își termină execuția pre-matur, din cauza lansării unei excepții. Prin folosirea unui obiect std::lock_quard, acest lucru este asigurat deoarece, în cazul lan-sării unei excepții, destructorul obiectului std::lock_quard va fi automat apelat dato-rită mecanismului de stack unwind.


10. Touch typingMașinile de Formula 1 au multe secrete;

cel mai bine păstrat este cel al anvelopelor. Motivul este simplu: oricât de eficient ar fi motorul și pilotul, anvelopele sunt cele care conectează mașina cu solul.

Tastatura este modul prin care creierul programatorului se conectează cu codul. Ideile sale, oricât de bune ar fi, trebuie în final transferate în cod cât de repede cu putință. Touch typing este abilitatea de a scrie la tas-tatură fără a o privi. Touch typing permite scrierea rapidă și concentrarea completă pe rezolvarea problemei. Mai mult, permite reducerea timpului de scris e-mail-uri sau documentație.

Ca orice abilitate, touch typing poate fi antrenat. http://www.typingstudy.com/ , http://www.typingclub.com/typing-qwerty-en.html sau http://play.typeracer.com/ sunt site-uri unde puteți învăța touch typing sau intra în competiție cu colegi sau prieteni la viteza de scris la tastatură. Utilizarea aces-tor site-uri poate deveni și o activitate foarte amuzantă, prin natura competitivă a lor.

9. Editorul (IDE-ul) folositEditoarele moderne de cod au sute

de funcționalități. Câteva dintre ele sunt extrem de folositoare și nu îndeajuns folosite. Stăpânirea lor permite editarea, navigarea și modificarea rapidă a codului, chiar și dacă este necunoscut sau nu este bine structurat.

De exemplu:• Editare avansată :

• Ștergerea unei linii (Ctrl+D în Eclipse, Shift+Ctrl+L în Visual Studio).

• Mutarea unei linii mai sus sau mai jos. Funcționează și pentru mai multe linii.

• Selecția oricărui bloc de cod între acolade sau paranteze (Ctrl + W în ReSharper).

• Navigare :• Găsirea tuturor referințelor către o

variabilă sau clasă;• Navigarea la implementarea unei

metode;• Refactoring

• Redenumirea unei variabile, metode sau clase (Alt + Shift + R în Eclipse, Ctrl + R, Ctrl +R în Visual Studio);

• Extragerea unei metode (Alt + Shift + M în Eclipse, Ctrl + R, M în Visual Studio);

• Extragerea unei interfețe;• Promovarea unei metode dintr-o

clasă în interfață sau clasa de bază;• Extragerea unei clase.

Multe alte funcționalități utile sunt docu-mentate în cheatsheets disponibile online.

8. Reducerea timpului de compilareOrice modificare a codului necesită

validare. Pentru cei care folosesc un limbaj compilat, timpul necesar pentru validare depinde de timpul de compilare. Nu este

Începutul de an este un moment bun pentru a medita la viitor. Cum putem crește în cari-eră? Cum putem avea o slujba (mai) stabilă? Cum putem deveni mai căutați într-o piață competitivă? Acest articol conține zece abilități tehnice care pot ajuta un programator să

se facă remarcat de către colegi sau de către manageri pentru eficiență.

Ce să înveți în 2014

arhitectură

Alexandru [email protected]

Agile Coach and Trainer, with a focus on technical practices@Mozaic Works

Adrian [email protected]

Programmer. Organizational and Technical Trainer and Coach@Mozaic Works

management


TODAY SOFTWARE MAGAZINEarhitectură

niciodată plăcut să aștepți ca programul să se compileze. În plus, concentrarea se pierde în acest timp.

IDE-urile Java, precum Eclipse și IntelliJ Idea oferă compilare continuă cu prețul timpului de procesor și memoriei. .NET Daemon de la RedGate (http://www.red-gate.com/products/dotnet-develop-ment/dotnet-demon/) oferă același lucru pentru programatorii .NET.

Chiar și fără aceste unelte, este posibil să scazi semnificativ timpul de compilare al unui program, oricât de mare ar fi, folosind câteva tehnici:

• Hard-uri SSD. Deși încă par scumpe, prețul lor este rapid absorbit de timpul câștigat de programatorii care nu vor mai aștepta după compilări;

• Crearea de soluții/proiecte temporare (sau unități de compilare în C++) care pot fi modificate, compilate și validate mult mai rapid decât întreg proiectul;

• Cunoașterea opțiunilor de compilare. De exemplu: compilarea incrementală și folosirea tuturor procesoarelor dis-ponibile sunt opțiuni comune pentru compilatoare.

7. Limbajul de programare și tehnologia principală folosită

O funcționalitate poate fi implemen-tată în nenumărate moduri. Doar câteva din aceste moduri sunt atât corecte cât și simple și ușor de extins.

Una dintre metodele de simplificare este de a folosi la maxim ceea ce este deja implementat în tehnologia folosită. Construcțiile de limbaj permit de aseme-nea simplificarea la maxim a codului.

O metodă contraintuitivă de a învăța foarte bine o tehnologie este de a încerca alte tehnologii și de a face comparații între ele. Cea mai simplă metodă de a încerca altă tehnologie este prin colaborarea cu un programator care o cunoaște, fie prin discuții pe cod existent sau scrierea de cod nou folosind pair programming (vezi 2).

6. Principii pentru design modificabilPrincipala problemă din software în

ziua de azi este faptul că trebuie sa modi-ficăm mereu cod existent. Se observă în viața unui proiect cum la început, codul este ușor și rapid de modificat. Pe măsură ce proiectul avansează și tot mai mult cod este creat, modificările devin tot mai difi-cile. De aceea design-ul aplicației trebuie să fie optimizat pentru modificabilitate.

Principiile SOLID și design patterns au apărut acum mai mult de zece ani ca soluții la aceste nevoi. Orice echipă care are

probleme cu modificarea codului ar trebui să investească timp în înțelegerea profundă și aplicarea acestor tehnici.

5. Refactorizare eficientăCodul greu de modificat poate fi

transformat în cod ușor de modificat prin refactorizare. Refactorizarea este o investiție în viitor; codul la care ajungem „opune” mai puțină rezistență, costurile de implementare ale funcționalităților noi scăzând.

Pentru o refactorizare reușită e nevoie de două elemente: cunoașterea și aplicarea principiilor de design modificabil (vezi 6) și scăderea timpului de refactorizare.

Există câteva secrete ale refactorizării eficiente:

• Folosirea refactorizărilor automate. IDE-urile moderne (Eclipse, Visual Studio + ReSharper sau IntelliJ Idea) au asemenea facilități. Editoarele populare printre programatori, precum vim, oferă posibilitatea de a înregistra macrouri sau de a scrie scripturi de refactorizare. Indiferent de soluție, refactorizările auto-mate economisesc mult timp.

• Cunoașterea refactorizărilor manu-ale. Uneori editorul nu are automatizate anumite tipuri de refactorizare. Cartea „Refactoring” de Martin Fowler descrie în detaliu modul de a face refactorizări manuale sigure și rapide.

• Refactorizarea continuă. Cu cât refactorizarea așteaptă mai mult, cu atât design-ul codului devine mai greu de modificat și va fi nevoie de o investiție mai mare. Refactorizarea continuă per-mite eliminarea problemelor de design din fașă, dar necesită cunoștințe solide de design și colaborarea cu colegii de echipă pentru revizuirea deciziilor luate.

• Automatizarea prin scripting a refac-torizărilor complicate dar comune. Majoritatea IDE-urilor pot fi exersate prin scripturi, ceea ce permite auto-matizarea unor refactorizări specifice aplicației.

4. Automatizarea eficientă a testării aplicațiilor mari

Pe măsură ce funcționalități noi sunt adăugate la o aplicație, timpul de testare tinde să crească. Modularizarea, adăuga-rea de noi testeri și/sau testarea automată sunt soluții posibile ale acestei probleme. Echipele care aleg testarea automată întâm-pină dificultăți în fața testelor care devin complicate și dificil de menținut. Soluția este structurarea testelor automate folosind piramida testelor.

Piramida testelor este o abordare struc-turată a testării automate prin împărțirea testelor în mai multe categorii:

• Teste unitare: validează comporta-mentele așteptate de la o clasă sau mai multe clase. Sunt rapide, simple, folo-sesc duble de testare (mocks și stubs) și sunt rulate de programatori după fie-care modificare a codului. Sunt cele mai multe și pot acoperi 90+% din compor-tamentele aplicațiilor.

• Teste de integrare: validează integra-rea claselor din aplicație cu orice sistem extern (librării, framework-uri, servicii externe, servicii ale sistemului de ope-rare). Sunt mai lente, mai dificil de scris și trebuie rulate atunci când se modifică versiunile de librării folosite sau la build-ul automat.

• Teste de contract: validează con-tractele de colaborare între două clase, adesea din module diferite.

• Teste end to end: validează cele mai importante funcționalități din modul sau aplicație, prin exersarea sistemului real. Sunt de obicei complicate, lente și fragile, deoarece necesită crearea și con-figurarea unui mediu de testare similar cu cel de producție. Nu folosesc interfața utilizator.

• Teste de sistem: validează sistemul folosind interfața utilizator. Pot fi manu-ale sau automatizate folosind tool-uri speciale (ex. Selenium)

• Teste de explorare: sunt executate manual de un tester care explorează aplicația căutând activ posibile erori de programare. Foarte utile pentru prinde-rea problemelor ascunse.

• Teste de acceptanță: scopul lor este de a crea specificații executabile care pot fi ușor citite de către Business Analysts, Product Manager, Product Owner, Business Stakeholders și alte persoane care nu sunt tehnice dar cunosc produsul și business-ul aplicației.

O strategie eficientă de testare se bazează pe o combinație între multe teste unitare, îndeajuns de multe teste din cele-lalte categorii și teste de explorare pentru prevenția majorității bug-urilor ce pot să apară. Această strategie poate acoperi o întreagă aplicație (în cazul celor business sau life critical) sau părțile cele mai riscante din aplicație. Un arhitect sau CTO poate defini această strategie și poate veghea la implementarea ei.

3. Lucrul rapid și eficient cu cod existentMajoritatea programatorilor lucrează



cu cod existent. Adesea, codul este vechi de 2-3 ani, uneori are 10 ani sau mai mult. Cei care l-au scris inițial nu mai sunt în echipă sau nu pot răspunde la întrebări legate de cod. Este așadar treaba progra-matorilor să înțeleagă codul existent și să-l modifice fără a-l strica atunci când adaugă o funcționalitate sau rezolvă un bug. Dacă testarea unei funcționalități noi este ușoară, validarea faptului ca nu am stricat nimic din funcționalitățile existente este mult mai dificilă. În același timp, am dori să îmbunătățim design-ul pentru a optimiza adăugarea de funcționalități noi în viitor (vezi 5). Dar cum, atunci când codul exis-tent este de neînțeles?

Tehnici speciale de a înțelege și modi-fica cod neinteligibil au fost create în timp. Dintre ele putem enumera:

• Golden master: scrierea de teste automate care la prima rulare stochează ieșirile și la rulările ulterioare compară ieșirile cu cele inițiale. Asigura un prim nivel de siguranță împotriva modificări-lor nedorite.

• Teste de caracterizare: scrierea de teste automate cu scopul de a descoperi comportamentele existente în cod. O dată ce o bucată din cod a fost acoperită de asemenea teste, poate fi extrasă în metode sau clase separate, ca prim pas spre simplificarea design-ului.

• Extract and override: o metodă care permite concentrarea pe o bucată mică atunci când încercăm să înțelegem codul. Este compusă din extragerea unei bucăți complicate de cod pe care nu vrem încă să ne concentrăm într-o metodă care apoi este suprascrisă cu o metodă folosită în scopuri de testare (crearea unui mock

parțial).• Refactorizare a explor atorie :

Refactorizarea cu scopul de a descoperi alternative de design. Atunci când refac-torizările sunt automatizate cu scripturi, ele devin Metoda Mikado.

Multe alte tehnici există, majoritatea descrise în cartea „Working Effectively with Legacy Code” de Michael Feathers și tra-tate în cursul „Working FAST and Safe with Existing Code” (http://www.mozaicworks.com/workshops/working-fast-and-safe-with-existing-code/) .

2. Învățarea mai rapidăTehnologiile și industria software se

schimbă continuu. Programatorii trebuie să învețe mereu lucruri noi, ceea ce înseamnă că optimizarea învățării este utilă oricui lucrează în acest mediu.

Câteva metode există pentru a învăța mai repede, dintre care enumerăm:

• Implicarea altor programatori în învățare (social learning),

• Pregătirea unei prezentări pentru o audiență prietenoasă,

• Exersare deliberată (deliberate practice),

• Coaching sau sesiuni facilitate,• Experimentare.

Pentru mai multe detalii citiți arti-colul „5 Trick to Amplify Learning” ( h t t p : / / w w w. m o z a i c w o r k s . c o m /blog/5-tricks-to-amplify-learning/).

1. Amintiți-vă să vă distrați!Cel mai important lucru este să vă

placă ceea ce faceți. Vor fi momente dificile,

probleme sau neînțelegeri în orice echipă. Important este să vă amintiți că progra-marea este o meserie frumoasă, că lucrați cu oameni inteligenți și că puteți adesea să ușurați viețile utilizatorilor.

Celebrarea succeselor în echipă, eve-nimente precum „code and beer” sau code retreat, lucrul cu programatori necunoscuți la întâlniri de comunitate sunt câteva moduri prin care vă puteți bucura de crearea de cod și să vă reamintiți cât de dis-tractiv este.

La Multe Împliniri în 2014!

managementCe să înveți în 2014


TODAY SOFTWARE MAGAZINE management

A fost prima lor călătorie în România, constând într-o întâlnire cu ingineri talentați dintr-o țară pe care o cunoscuseră inițial doar prin intermediul mass-media și a conversaților purtate cu români întâlniți în călătoriile lor internaționale. Tom și Kai au petrecut o zi întreagă în ISDC și au interacționat cu ingineri ISDC, manageri de proiect, testeri și alte roluri într-o ”expediție cognitivă” despre cum se poate crea și oferi calitate. Mai mult de opt ore de workshop-uri intensive, sesiuni deschise și conversații ‘’Myth-buster” au fost dedicate unor teme cum ar fi: „Managementul arhitecturii, cerințelor, și al proiectului”, „Atribute non-funcționale ale cerințelor / de calitate”, „Îmbunătățirea continuă”, „Zece principii cheie ale metodologiei Agile”. Interacțiunea a fost intensă și provocatoare de ambele părți ale mesei. Concluzia lui Tom a fost că a cunoscut un grup de oameni inteligenți, deschiși, receptivi, totodată curioși, care sunt dovada vie a unei industrii inovatoare, care are viitorul în față.

De fapt, oamenii sunt cei care

determină pragul de valoare. Când vine vorba de diferențierea pe piață, mulți oameni se referă la Agile ca la noul leac miraculos pentru un timp mai rapid de lansare pe piață, mai multă apropriere față de client, mai mult feedback asimilat în procesul de dezvoltare și mai multă colaborare între mediul de afaceri și mediul IT. Destul de surprinzător, Tom este de acord că Agile continuă să fie un diferențiator pe piață, cu o singură condiție: dacă este bine aplicat. Dar, la fel ca și în cazul celor mai multe metode de pe piață, Agile este prost practicat. Deci, în cele din urmă, atunci când vine vorba de organizații compe-titive, diferențiatorul cheie este - ca de obicei - calitatea.

De ce atunci calitatea este încă un țel atât de greu de atins? Tom a folosit o analo-gie, care pentru mulți dintre noi, din lumea outsourcing sună, probabil, prea familiar. Când firmele de outsourcing din India, Tata Consultancy, etc. și-au început activitatea, nu au luat în considerare factorul calitate, ci doar factorul preț. Tom i-a sfătuit să se profilleze

28 noiembrie, Cluj-Napoca, ISDC. Tom Gilb și fiul său, Kai, au vizitat recent Clujul. Cu această ocazie, Tom si Kai au avut șansa să-și formeze propriile impresii despre România și talentele IT, într-un cadru informal, prin interacțiune directă. Scopul vizitei

lor a fost de a împărtăși din experiența lor despre cum putem furniza calitate stakeholder-ilor noștri și despre cum anume putem oferi o experiență de succes clienților folosind metodolo-gia “Agile” în dezvoltarea soluțiilor software

Alexandra Beșe [email protected]

Marketing Assistant @ ISDC

Tom Gilb. De ce furnizarea calității către client îți face afacerea

durabilă și de succes


pe o calitate superioară în primul rând. Ei au făcut acest lucru folosindu-se de nivelele CMMI. „Știi, în copilăria mea, prin anii ‚40, japonezii au încercat să intre pe piața ame-ricană și tot ce construiau ei era de o calitate proastă. Apoi cineva i-a trezit printr-o sim-plă întrebare – Cum rămâne cu calitatea? În zilele actuale, produsele japoneze înseamnă calitate excepțional de înaltă. Le-am spus, de asemenea, și clienților mei indieni că americanii nu vor cumpăra serviciile lor doar pentru că acestea sunt ieftine; vor avea o șansă cu ei, dacă acestea au o calitate net superioară celor din producția internă și, poate, un preț de nișă! „

Tom continuă: „Ei au făcut asta și au adoptat următoarea strategie: vom obține certificare CMMI. Fiecare companie din India are acum un nivel CMMI 4 sau 5, în timp ce americanii pot ajunge cu greu la nivelul 2. Deci, americanii au înțeles mesa-jul: indienii sunt superiori, prin urmare, aceștia sunt și mai ieftini așadar, de ce să nu cumpărăm de la indieni? Și așa a început aventura indiană de outsourcing. „

Un alt exemplu oferit de Tom pentru a sprijini ideea lui legată de filozofia centrată pe calitate a fost NASSCOM, o organizație indiană de servicii la care urma să prezi-deze o conferință. Și de această dată, Tom a susținut puternic conceptul de a pune accent pe calitate. Pentru companiile indiene în special, acest lucru a însemnat o schimbare sau reorientare spre „nici o soluție, nici un contract de plată.” Oamenii vor plăti pentru calitatea livrată și nu pen-tru orele de muncă.

Deci, ce se va întâmpla cu Agile în acest context extrem de transformator? În ce direcție va merge Agile peste 10 ani?

Tom prezice un viitor sumbru. „Agile va fi învins, dezonorat. Nu pentru că Agile nu este bun, ci pentru că este prost practicat la fel ca aproape toate celelalte tendințe din software. Sunt aici de 55 ani: noi tendințe apar, există poate câteva idei bune, dar oamenii caută căi rapide, practici simplifi-cate și apoi dau vina pe metodologie - Ah, e din cauza metodei - Agile, nu e bună, nu e pentru noi. Deci, soluția este de a adopta o metodă mai bună pe care o vom practica prost și apoi vom da vina pe metodă. Așa se întâmplă de 55 de ani. Este o glumă bună! „

„Vezi că se întâmplă continuu pe par-cursul vieții, oamenii adoptă o metodă bună, o practică prost, dau vina pe metodă și trec la o alta nouă. Oamenii nu au o cul-tură de a face lucrurile foarte bine. Există culturi ca, de exemplu, în muzică sau pic-tură, unde, dacă nu ești foarte bun, nu o să ajungi niciodată în top. Noi, în industria de software, nu avem o astfel de cultură, o filozofie de a face lucrurile foarte bine. Avem un concept de „oamenii sunt destul de proști să ne plătească o mulțime de bani pentru a face ceva prost, așa că haideți să ne distrăm cât timp încă mai merge”. Este foarte trist dar se întâmplă la nivel mondial. Orice organizație, cum ar fi propria voas-tră organizație, poate schimba lucrurile cel puțin pentru ei înșiși, și de acolo poate influența comunitatea prin învățarea altora cum să facă lucrurile foarte bine. „

ConcluziiOrganizațiile depun eforturi, în gene-

ral, de a învăța și de a excela. Viteza cu care lucrurile se fac determină succesul. Când vine vorba de sfaturi și trucuri pentru succes, încercați să definiți atributele care

sunt pivotabile. De exemplu, pivotați de la „Noi lucrăm Agile” la „Noi livrăm cali-tate.” Aceasta

e s t e o

schimbare majoră de mentalitate. „Dacă faceți asta, eu prezic că veți obține un avantaj competitiv pentru că orice client ar dori să obțină valoare, nu doar software-ul care ei cred că le va aduce valoare. Vorbim aici despre posibilitățile de reorientare în livrarea de valoare stakeholder-ilor și clienților de business – acolo este locul în care acțiunea trebuie să se petreacă. Când ați reușit să faceți asta, veți descoperi că toți concurenții dumneavoastră sunt ocupați încă să scrie cod în pofida livrării calității și voi veți fi cei care vor arăta foarte bine! Veți avea posibilitatea de a avea un model de contractare diferit pentru că veți taxa calitatea livrată și veți putea spune clien-tilor voștri - Nu riscați nimic cu noi. Nu trebuie să plătiți nimic în cazul în care cali-tatea nu este livrată. „

Câteva sfaturi practice oferite de către Tom, ce pot fi aplicate de către fiecare din-tre noi:

• puneți accent pe furnizarea de calitate;

• faceți lucrurile foarte bine, astfel încât să puteți ajunge în top;

• bună implementare a software-ului

Tom Gilb. De ce furnizarea calității către client îți face afacerea durabilă și de succes

Tom Gilb

management



este un diferențiator, așa că nu da vina pe metode în cazul unor practici proaste;

• cunoașteți-vă trecutul, altfel sunteți sortiți să-l repetați.

Tom & Kai Gilb“Cei doi Gilb nu sunt ‘academicieni’ –

ci sunt accesibili, dar concentrat și intens de practici.”

Tom Gilb și Kai Gilb au reușit, împre-ună cu mai mulți prieteni profesioniști și clienți, să dezvolte personal metodele pe care le predau. Acestea au fost dezvoltate în zeci de ani de practică în toată lumea, în companii și proiecte mici, precum și în altele mai mari.

Tom este autorul a nouă cărți și sute de documente cu privire la aceste subiecte și altele conexe. Ultima sa carte, „Inginerie competitivă” este o definiție substanțială a cerințelor. Ideile sale cu privire la cerințe sunt o bază recunoscută pentru nivelul CMMI 4 (cuantificare, așa cum a fost dez-voltată inițial la IBM in 1980). Tom a fost invitat să predea la universități din Marea

Britanie, Europa, China, India, Statele Unite ale Americii, Coreea - și a fost invita-tul principal la zeci de conferințe tehnice la nivel internațional.

Kai Gilb a fost alături de Tom în decur-sul dezvoltării acestor idei, ținând cursuri și punându-le în practică cu clienții lor încă din anul 1992 . El pregătește manageri și product owners, scrie lucrări , dezvoltă cursuri, și își scrie propria carte, „ Evo – Evolutionary Project Management & Product Development.”

Există foarte multe organizații și persoane care folosesc o parte sau toate metodele lor. IBM și HP au fost doi adop-tatori corporatiști timpurii. Recent, peste 15.000 (și încă în creștere) de ingineri de la Intel au adoptat metodele pentru cerințe „Planguage”. Ericsson , Nokia și, recent, Nordea, Statoil și un grup financiar multinațional de top utilizează părți din metodele lor la scară largă . De asemenea, multe companii mai mici folosesc metodele lor.

Acest interviu a fost realizat la sediul ISDC împreună cu Tom Gilb.


BPMN – util în modelarea proceselor

de business

Un management eficient al proce-selor de business într-un produs software este esențial atât pentru succesul acestuia pe piață cât și pentru cel al relației din-tre client și compania prestatoare, relație intermediată de analistul de business. Știm cu toții că beneficiarii și/sau sponso-rii produselor software nu sunt familiari cu terminologia specifică domeniului IT, apărând astfel numeroase probleme de comunicare între aceștia și echipele de livrare. Pentru a facilita această comuni-care și pentru a aduce un plus de claritate cerințelor funcționale obținute, procesele de business trebuie modelate într-o mani-eră cât mai elocventă, folosind un limbaj standardizat și pe înțelesul tuturor.

Pentru crearea diagramelor BPMN se pot avea în vedere utilitare precum: MS Visio, Sparx Systems Enterprise Architect sau variante gratuite cum ar fi BonitaSoft, Intalio sau ProcessMaker.

Procese de business și BPD Putem defini un proces de business ca

o succesiune de activități de business rea-lizate de către participanți, cu scopul de a-și atinge obiectivele și de a livra valoare. Aceste procese pot fi modelate pe trei nivele de detail, iar BPMN le suportă pe toate:

• Harta procesului (engl. Process map) – este o diagramă simplă de activități.

• Descrierea procesului – este o dia-gramă de activități extinsă cu informații adiționale.

• Modelul procesului – este o dia-gramă de activități extinsă cu suficiente informații, astfel încât procesul să poată

fi analizat, simulat sau executat folo-sind BPEL – Business Process Execution Language.

În analiza de business, procesele – independent de tipul lor (de management, operaționale sau de suport) trebuie mode-late pentru a beneficia de următoarele avantaje:

• Asimilare – procesele, dacă sunt împărțite în activități atomice, pot fi mai bine înțelese de către toți participanții la livrare.

• Monitorizare și evaluare – pro-cesele, dacă sunt reprezentate clar și concis pot fi mai bine monitorizate și evaluate și li se pot aplica anumiți indi-catori de performanță (engl. KPI – Key Performance Indicators).

• Optimizare – procesele, dacă sunt descompuse în activități independente și interconectate, pot pune în evidență blo-caje (engl. bottlenecks), căi duplicate, căi alternative și bucle, putând fi astfel candi-date la îmbunătățiri.

• Creare de procese noi – procesele, dacă sunt corect modelate, reflectând starea actuală a sistemului (engl. as-is system), sunt un punct solid de pornire pentru modificări funcționale (engl. change requests) sau extensii ulterioare (engl. to-be system).

• Automatizare – procesele, dacă sunt reprezentate pas cu pas, pot fi ușor automatizate, reducând astfel costu-rile asociate cu dezvoltarea și testarea, îmbunătățind calitatea produsului și opti-mizând etapele de mentenanță și suport.

Business Process Model and Notation sau pe scurt BPMN este unul dintre cele mai cunoscute standarde de modelare și management al proceselor de business, fiind extrem de util în etapele de definire și aliniere a produselor software. Obiectivul

BPMN este acela de a furniza un set unificat de elemente și de notații care să fie ușor de înțeles și de folosit de către toți participanții la procesul de livrare.

management programare

Anita Pă[email protected]

Senior Business Analyst@ Endava



Diagramele oferite de BPMN, numite BPD – Business Process Diagrams sunt similare diagramelor de activitate, fiind însă cu mult mai expresive și ușor de asi-milat și putând fi totodată executate de utilitarele BPEL.

Pentru a crea BPD-ul, analistul de business identifică și modelează evenimen-tul de început al procesului, apoi celelalte evenimente, în ordinea în care se petrec până la evenimentul care încheie procesul. Deciziile de business și căile alternative se modelează folosind blocuri de decizie (engl. gateways). Dacă procesul de business este unul complex, el poate fi descompus în sub-procese, fiecare dintre acestea fiind modelat printr-o BPD aferentă, iar rezulta-tele obținute vor fi interconectate, pentru a obține vederea de ansamblu.

De ce să folosim BPMN?Prezentarea sintetică a avantajelor

acestui standard, care vine atât în ajutorul analiștilor de business cât și al clienților, poate lua următoarea formă:

• Simplitatea – elementele și notațiile puse la dispoziție de BPMN sunt intu-itive, nefiind nevoie de cunoștințe prealabile de nivel tehnic. Astfel, ana-listului de business îi este ușor să creeze diagrame BPMN, care sunt foarte simplu de urmărit de către partea de business.

• Expresivitatea – standardul este expresiv și adaptabil în ceea ce privește modelarea proceselor, permițând aplica-rea unei game largi de constrângeri. Spre deosebire de alte standarde ca de exem-plu UML, BPMN este mult mai versatil și

poate reprezenta fluxuri mult mai com-plexe de business.

• Standardizarea – BPMN este un standard guvernat și menținut de către OMG – Object Management Group.

• Aplicabilitate în IT – având în vedere că IT-ul este o orizontală care deservește verticale precum sectorul financiar sau cel bancar, necesitatea de a avea suport IT este foarte mare și în continuă expan-siune iar majoritatea proceselor de business trebuie modelate într-un limbaj clar, obiectiv și elocvent, pentru a putea fi livrate la calitate ridicată și pentru a asigura satisfacția și încrederea clienților.

Elementele BPMNUn model BPMN poate fi descris ca o

succesiune de noduri, conectate prin flu-xuri paralele sau secvențiale. Pentru a putea folosi BPMN în analiza de business, trebuie să cunoaștem câteva elemente cheie ale limbajului, care sunt folosite la descrierea majorității proceselor. Mai întâi trebuie să știm că există patru categorii de elemente, după cum putem vedea mai jos:

Obiecte de flux (engl. flow objects)• Activități - acțiuni care se întâmplă

în cadrul procesului de business, fiind reprezentate grafic sub formă de drept-unghiuri cu colțurile rotunjite. Putem vorbi aici despre task-uri , sub-procese și task-uri recurente .

• Evenimente - acțiuni care pot da startul unui proces, se pot întâmpla într-un proces sau pot opri un proces și sunt reprezentate sub formă de cercuri, tipul de contur al cercului determinând tipul

de eveniment. Putem vorbi astfel des-pre evenimente de start - contur simplu, intermediare - contur dublu și de stop - contur boldat.

• Porți (engl. gateways) - elemente care modelează interacțiunile dintre fluxurile unui proces și deciziile de business, fiind reprezentate grafic prin romburi.

Conectori• Fluxuri secvență (engl. sequence

flows) - sunt reprezentate prin săgeți cu linie continuă și indică ordinea activităților într-un proces de business.

• Fluxuri mesaj- sunt reprezentate prin săgeți cu linie întreruptă și indică un schimb de mesaje între două swimlane-uri diferite dintr-un proces de business.

• Asocieri - sunt reprezentate prin săgeți cu linie punctată și se folosesc pen-tru a asocia date, informații și artefacte la obiecte.

Swim lanes• Po ols - ajut ă l a c l as i f i care a

activităților și a participanților în cadrul unui proces de business interactiv.

• Lanes – reprezintă sub-partițiile unui pool și pun în evidență de regulă rolu-rile implicate în procesul de business și acțiunile asociate fiecăruia.

Artefacte• Obiecte – prezintă modul în care

datele și documentele sunt folosite într-un proces și definesc intrări și ieșiri din activități. Obiectele pot primi și ‘stări’ care prezintă modul în care documentele pot fi modificate în cadrul procesului.

programare

http://en.wikipedia.org/wiki/Swim_lane



• Grupuri – pun în evidență anumite secțiuni din BPD fără a adăuga con-strângeri de performanță. Pot fi folosite pentru a clasifica elemente pentru rapor-tare și nu se supun restricțiilor impuse de pools sau lanes.

• Adnotări (engl. annotations) – furni-zează informații suplimentare despre un proces și pot fi conectate cu un anumit obiect din BPD folosind asocieri.

Bune practici în modelarea BPMNChiar dacă limbajul BPMN este flexi-

bil și nu ne impune constrângeri în ceea ce privește modelarea, este bine să respectăm câteva bune practici stabilite în prealabil la nivelul echipei de proiect, al departamentu-lui sau al organizației:

• Activitățile procesului de business trebuie modelate în ordine cronologică, pe o cronologie de la stânga la dreapta.

• Procesele de business încep de regulă cu un eveniment declanșator și continuă până la obținerea de rezultate.

• Task-urile și activitățile din cardul unui proces trebuie asociate la roluri relevante din punctul de vedere al business-ului.

• Un model complet al procesului de business ar trebui să prezinte modul în care obiectele și/sau datele sunt transferate.

• Procesele de business trebuie mode-late ierarhic, descriindu-se sub-procesele componente, în cazul în care acestea există.

• Este recomandată stabilirea și folo-sirea convențiilor de nume pentru modelarea proceselor de business, ca de exemplu: i) numele elementelor trebuie să fie scurte și concise; ii) este redundant să repetăm cuvinte precum ‘task’ sau ‘proces’ în numele unui task respectiv proces; iii) activitățile trebuie să aibă ca nume un verb; iv) în numele complexe, fiecare cuvânt trebuie scris cu literă mare – de exemplu, vom denumi o activitate ‚SolicitareAbsență’ nu ‚solicitareabsență’ sau ‚Solicitareabsență’.

• Dacă procesul de business evoluează în timp, este recomandat să versionăm BPD-urile create, pentru a putea fi urmă-rite schimbările.

Studiu de cazÎn cele ce urmează vom analiza un

exemplu scurt și intuitiv pentru a evidenția modul în care se aplică analiza BPMN în cazul unui scenariu de business concret precum și pașii necesari pentru crearea

BPD-ului.S ă s t u d i e m

procesul prin care u n ang aj at d i n departamentul IT al unei companii solicită concediu iar superiorul său ierarhic, după o evaluare prealabilă, aprobă sau nu cere-rea sa. Vom adăuga și cazul în care superiorul ierarhic nu răspunde în timp util la cerere, caz în care se va opta pentru o rută alternativă, cu răspuns automat, trimis de către sistem în numele acestuia.

În situația de față, în primul rând tre-buie să punem în evidență actorii implicați în proces și anume angajatul, superiorul ierarhic și sistemul.

La pasul al doilea vom identifica setul de activități desfășurate de fiecare dintre cei trei actori în cadrul procesului, ca de exemplu:

Angajatul: solicită absența - activitate urmată de notificarea superiorului său ierarhic.

Superiorul ierarhic: procesează cererea de absență,iar apoi decide dacă o aprobă sau o respinge. Ambele decizii sunt însoțite de trimiterea unui mesaj de notificare îna-poi către angajat.

Sistemul: pune la dispoziție fluxul alter-nativ care constă în respingerea automată a cererii de concediu, în cazul în care supe-riorul ierarhic nu răspunde afirmativ sau negativ în timp de o zi (acțiune urmată de trimiterea unui mesaj automat de respin-gere către angajat).

La pasul al treilea trebuie să decidem tipurile de elemente cu care vom crea BPD-ul. Hotărâm că vom folosi un pool cu două lane-uri, unul pentru angajat și celălalt pentru superiorul său ierarhic. Tot pe lane-ul superiorului vom reprezenta și acțiunile făcute de sistem, care în situația de față îl impersonalizează. Mai avem nevoie și de activități, blocuri de decizie și evenimente de start, intermediare și de stop. Cu rol de conectori utilizăm fluxuri secvență și fluxuri mesaj.

La pasul patru, începem să plasăm elementele BPMN pe BPD și anume - pe lane-ul angajatului vom avea următoarele: evenimentul de start, activitatea de solici-tare absență, evenimentul intermediar de notificare a superiorului ierarhic și eveni-mentul de stop.

Pe lane-ul superiorului ierarhic mode-lăm evenimentul de start – care constă în primirea notificării trimise de angajat, activitatea de procesare a absenței, blocul de decizie în urma căruia rezultă apro-barea sau respingerea cererii - însoțite de evenimentele intermediare de notificare a angajatului cu rezultatul procesării și din ambele cazuri, evenimentul de stop.

Tot pe lane-ul superiorului ierarhic, la activitatea de procesare a cererii, plasăm un eveniment intermediar de timeout (cu valoarea de o zi) după expirarea căruia se declanșează evenimentul intermediar de notificare a angajatului de respingerea cere-rii, urmat de evenimentul de stop.

ConcluziiExistența unui standard pentru mode-

larea proceselor de business, cunoscut și înțeles de către analiștii de business, client și echipele tehnice este de un real folos nu numai în analiza de business ci și în între-gul proces de livrare, cu atât mai mult cu cât este vorba despre un standard simplu, intuitiv și care nu presupune cunoștințe tehnice anterioare. Beneficiile majore ale acestuia sunt reprezentate de înțelegerea și comunicarea proceselor de business între părțile implicate și capacitatea modelelor rezultate de a fi executate de BPEL.

managementBPMN – util în modelarea proceselor de business

Fig. 1 Diagrama BPMN a procesului de solicitare absență


TODAY SOFTWARE MAGAZINE HR

În această ultimă întâlnire am extras o serie de concluzii legate de subiectul gene-ros al industriei de IT din Cluj. În prima parte, împreună cu participanţii am stabilit care ar fi principalele subiecte care preo-cupă și provoacă specialiștii din Resurse Umane din organizaţiile de IT – revizuind lucrurile discutate în workshop-urile ante-rioare. În cea de-a doua parte a întâlnirii am creionat conturul comunității de IT ideale pentru Cluj și am realizat o selecție a acţiunilor concrete din 2013 care pot apro-pia grupul de firme din Cluj de idealul de comunitate.

Principalele provocări din 2013 în com-paniile de IT

Revizuind subiectele principale dis-cutate în workshop-urile anterioare, am constatat că principalele provocări pentru specialiștii de Resurse Umane din compa-niile de IT enunţate la începutul anului nu s-au modificat semnificativ în 2013.

Atragerea şi menținerea oamenilor în com-paniile de IT

Acţiunea de recrutare și menținerea oamenilor în organizaţie reprezintă în continuare provocări. Situația va persista atât timp cât raportul între cantitatea pro-iectelor aduse în Cluj și disponibilitatea de specialiști de pe piaţă va fi în continuare unul supraunitar, deci dezechilibrat. În acest sens, mai mulţi sunt factorii care con-tribuie la acest dezechilibru: de exemplu, universităţile tehnice nu au deocamdată capacitatea de a „furniza” mai repede și mai mulţi angajaţi bine pregătiţi; marea majori-tate a companiilor de IT din Cluj lucrează în acest moment pe proiecte de outsourcing ceea ce presupune o infuzie mare și rapidă de proiecte și deci, un necesar mare de mână de lucru; beneficiile oferite angajaţi-lor sunt deja mari și comparabile de la o firmă la alta, etc. . În același timp, situaţia

aceasta reprezintă un „dat” care, la rândul lui generează o serie de efecte posibil pozi-tive pe termen scurt, însă posibil negative pe termen mediu sau lung. Dar aceste opi-nii ale noastre le vom prezenta în partea finală a acestui articol.

Activitatea de dezvoltare profesională şi personală a angajaţilor din aceste companii

În ceea ce privește activitatea de dez-voltare a oamenilor din IT, specialiștii de Resurse Umane au de-a face cu o situaţie oarecum paradoxală.Atunci când recru-tează noi angajaţi, marea majoritate declară că doresc să aibă cât mai multe oportuni-tăţi de învăţare, training-uri, forme de dezvoltare. După angajare, interesul pro-priu pentru astfel de acţiuni de dezvoltare organizate la nivel de companie sau comu-nitate scade vertiginos la marea majoritate a angajaţilor și, din păcate, și la nivel de management.

Pentru categoria de cursuri din dome-niul „soft-skills” interesul este și mai scăzut decât pentru domeniul „cursuri tehnice” – dar, paradoxal, și la această categorie, rata de participare este redusă faţă de numărul posibil de participanţi. De cele mai multe ori, chiar cei care ar trebui să fie model în direcţia învăţării continue, a atitudinii pro-active faţă de dezvoltare – managerii – sunt cei care împiedică într-o mare măsură pro-cesul de dezvoltare. Diversitatea cauzelor poatet fi justificată. De exemplu, în unele companii, cheltuielile cu training-urile (dintre care cele tehnice sunt semnificativ mai mari) se deduc din bugetul departa-mentului participanţilor și, de multe ori, managerii care ar trebui să aprobe parti-ciparea oamenilor lor, se ghidează după interese de business imediat (ex. profitul să rămână cât mai mare). În alte situaţii, managerii care conduc un anume proiect se gândesc punctual la nevoile actuale de dezvoltare ale oamenilor lui, neglijând

răspunsul la întrebări precum : „ce ar tre-bui să știe oamenii mei pe viitor, pentru a asigura o mai mare flexibilitate și profesi-onalism în eventualele noi proiecte?”. În plus, din cauza situaţiei descrise la punc-tul 1 – lipsă de resurse umane suficiente – managerii sunt uneori nevoiţi să refuze participarea oamenilor la training, chiar și pentru câteva ore, deoarece nu au cum să susțină faze ale proiectului, în timpul cerut, cu resurse limitate. Cu toate aceste reticenţe care vin de la manageri, angajaţii nu mai manifestă în mod semnificativ iniţiative, cereri de participare la forme de dezvol-tare. Chiar și atunci când participă, rata de aplicare în mod real în munca de zi cu zi a achiziţiilor dobândite este scăzută.

Din păcate, chiar dacă beneficiul la nivel individual este mai mult decât evi-dent – diploma, certificarea, cunoștinţele, abilităţile rămân persoanei oriunde s-ar duce în viitor – acest argument nu este suficient valorizat de angajaţii din IT. Este adevărat că, datorită specificului muncii, există acţiuni de autodidacticism care se practică în rândul IT-iștilor, făcând parte din comportamentul lor profesional. Deși ajută la realizarea unei performanţe imedi-ate, acestea pot avea dezavantajul de a crea și iluzii de tipul: „dar noi învăţăm în fiecare zi!”. Ceea ce oamenii de Resurse Umane nu au reușit încă să convingă pe marea parte a angajaţilor din IT este faptul că dezvol-tarea continuă, sistematică și strategică îi va ajuta nu doar în realizarea unei perfor-manţe „aici și acum” ci și în construirea unei cariere. Dacă peste câţiva ani compe-tiţia pentru profesionalism pe această piaţă va deveni o competiţie veritabilă, atunci, cei care au crescut temeinic și strategic vor fi cei care vor avea de câștigat.

Dorim să precizăm că aceste concluzii se referă la o medie a angajaţilor din IT și, bineînţeles, cazurile punctuale de oameni pasionaţi, dedicaţi care participă la orice

SPRE COMUNITATEA IT – via HR (4)

În 2013 ne-am propus să adunăm și să sintetizăm cât mai multe păreri despre companiile de IT de pe piaţa Clujului și despre ideea de „comunitate de IT”. Pentru aceasta, anul trecut am derulat patru întâlniri cu specialiști de Resurse Umane din companiile de IT și am consemnat părerile lor în articole publicate în revista Today Software Magazine – trei dintre aceste articole au apărut în

numerele 11, 13 și 16, cel de-al patrulea fiind articolul de faţă.


training sau conferinţă sunt excluse din aceste afirmaţii.

***Pornind de la această stare de fapt

prezentă în companiile de IT clujene, vă propunem la început de an, un exerciţiu de imaginație prin încercarea de a răspunde la una din întrebările: „Ce s-ar întâmpla dacă de mâine outsourcing-ul din Cluj ar dispărea / s-ar muta în altă parte? Ce s-ar întâmpla cu mine, cu colegii mei? Ce pot face eu azi ca să preîntâmpin un astfel de scenariu?” În teoriile gândirii strategice, astfel de analize, procese se numesc analize de risc…

Și totuși… ce facem cu ideea de „comu-nitate IT clujeană”?

O parte din răspunsul la această între-bare a fost dat de participanţii la acest proiect în workshop-ul trecut și vă invităm să (re-)citiţi articolul din numărul 16 al TSM în care se prezintă motivele pentru care o comunitate (nu doar o mulţime) este necesară la nivelul industriei IT clujene. Tot aici se prezintă și câteva idei punctuale care pot contribui la creșterea unei astfel de comunităţi.

În această ultimă întâlnire am dorit să conducem discuţia la un alt nivel de generalitate și am cerut participanţilor în primul rând să definească ce înseamnă o comunitate ideală de IT la Cluj. Apoi, în funcţie de acest benchmark să evalueze, din perspectiva lor, care au fost pașii care s-au făcut în 2013 spre această direcţie dorită.

Astfel, o comunitate ideală, dorită de IT la Cluj ar însemna (Atenţie! Acest para-graf reprezintă un vis… Fără curajul de a visa, nu va putea exista progres! Oricine este binevenit să adauge elemente punctuale în acest vis descris în acest moment de specia-liștii de Resurse Umane.):

• O majoritate de „actori locali” în rolul de antreprenori / acţionari în com-panii IT – pentru a avea interes real de dezvoltare la nivel local.Vânzarea com-paniilor locale către multinaţionale îngreunează formarea unei comunităţi locale, crescând instabilitatea pieţei de IT.

• Un procent majoritar din busine-ssul IT de la nivelul Clujului să fie „de produs”, iar businessul de outsourcing să scadă semnificativ.

• La nivel de comunitate, există un număr semnificativ de proiecte mari, la care lucrează, în colaborare, consorţii de firme, freelancer-i profesioniști.

• Clienţii internaţionali importanţi sunt hotărâţi și atrași să facă proiecte

mari pe piaţa Clujului pentru că au încre-dere că aici găsesc priceperea necesară pentru a-și duce proiectele la bun sfârșit.În exterior se promovează o imagine uni-tară, pozitivă a comunităţii IT din Cluj ce reflectă un potenţial de lucru profesi-onist, inovativ și de încredere.

• Comunitatea IT din Cluj este sprijinită prin acţiuni concrete de admi-nistraţia locală și primește susţinere și de la nivel naţional.

• Clujul oferă potenţialilor clienţi mari dovezi palpabile a capacităţii inovative și a potenţialului creativ de la nivelul specialiștilor de aici. Există, de exemplu, centre de instruire performante la nivelul Clujului, instituţii de educaţie speciali-zată private, un mediu universitar flexibil și ancorat în realitate, grupuri de cerce-tare cu rezultate concrete, etc. .

• Oamenii care lucrează în IT-ul clujean (incluzând și antreprenorii, managerii, etc.) au anumite particulari-tăţi care îi fac să fie extrem de valoroși fiecare individual, dar și în echipă: sunt pasionaţi de domeniul lor, sunt dedicaţi inovării, au o mentalitate de vizionari (fiind dispuși să câștige mai puţin pe moment, pentru a clădi ceva durabil), au curaj să-și asume unele riscuri, sunt pro-activi și flexibili.

O astfel de comunitate funcţională ar asigura o „poveste de succes” în economia locală și naţională și ar reprezenta un sector semnificativ mai stabil de business.

Dacă aceasta este ţinta unde se dorește să se ajungă, care au fost acţiunile concrete întreprinse în 2013 pentru ca organizaţi-ile de IT din Cluj să se apropie de acest deziderat? – deziderat a cărui îndeplinire este preconizată de specialiștii din Resurse Umane într-un viitor relativ îndepărtat.

Din păcate, pentru cei prezenţi la work-shop nu au fost foarte vizibile acţiuni clare în această direcţie. Există totuși o serie de iniţiative – care însă produc efecte puţin vizibile la nivelul comunităţii din Cluj. Spre exemplu:

• Organizaţia cu cel mai mare posibil impact pozitiv în direcţia creării acestei comunităţi ideale este IT Cluster – des-pre care însă nu sunt vizibile informaţii concrete de avansare în direcţia unor rezultate palpabile. Se știe că au fost ini-ţiate o serie de demersuri cu universităţi și cu autorităţi naţionale, însă, în acest moment nu se cunosc rezultate concrete.

• S-au desfășurat pe piaţă o serie de evenimente tehnice cu scop de dezvol-tare profesională și împărtășire de bune

practici – ceea ce reprezintă un bun început! Din păcate rata de participare la aceste eveniment nu a atins o masa critică care să ajute la crearea unei men-talităţi pro-comunitate profesionistă de IT. La astfel de evenimente, conferinţe, participă, de regulă, acea minoritate de oameni ultra-pasionaţi … dar care sunt o minoritate.

Dacă ar fi să sintetizăm într-un singur paragraf opiniile exprimate pe parcursul întregului an în cadrul acestei cercetări, am putea spune că opinia HR-ului din IT-ul clujean este: în acest moment, suntem o industrie „pe val”; ne merge bine, avem ce lucra, lucrăm destul de bine calitativ; avem provocări legate de numărul de specialişti în domeniu şi de dezvoltarea angajaţilor – însă nu sunt „dureri” prea mari; visăm frumos la o comunitate IT în Cluj despre care ştim că ar avea destul de multe beneficii, însă în acest moment, nu există suficient imbold către această formă de lucru strategică.

O părere din exterior • La finalul acestei iniţiative derulată

de echipa noastră – Danis Consulting – am considerat oportun să ne exprimăm și noi o serie de opinii legate de toate aceste radiografii făcute pieţei IT din Cluj. Opiniile pe care le veţi regăsi mai jos nu sunt neapărat și ale participan-ţilor la workshop-urile noastre sau ale oamenilor din IT cu care am colaborat în ultimul an. Credem că orice perspectivă sau punct de vedere poate fi de ajutor în luarea unor decizii strategice.

• Părerile de mai jos se bazează pe mai multe situaţii în care am avut ocazia să observăm mediul IT în diferite ipostaze: discuţiile derulate în cadrul acestei cer-cetări, discuţii purtate cu manageri / antreprenori din domeniul IT clujean, participări la diverse evenimente de pe piaţa IT clujeană (ex. : lansările lunare ale TSM, conferinţa IT Days), colaborări directe pe anumite programe cu diverse companii de IT, etc. .

Așadar, cum vedem noi anumite aspecte din industria IT clujeană:

• În rândul oamenilor IT din Cluj am observat un foarte mare potenţial creativ și de profesionalism. Credem că IT-iștii clujeni sunt extrem de inteligenţi și capabili de rezultate de bună calitate pe această piaţă globală a tehnologiei, inovaţiei.

• În acest moment, situaţia resurselor

SPRE COMUNITATEA IT – via HR (4)

HR



umane limitate de pe piaţa Clujului gene-rează o serie de efecte negative pe termen mediu și lung (pe lângă stresul recrutării) – pe care actorii decizionali importanţi ar merita să le aibă în vedere și să conceapă încă de pe acum o strategie pentru a le preîntâmpina.Poate că deja se lucrează la astfel de strategii; însă noi nu am văzut rezultate concrete în această direcţie. Recomandarea noastră ar fi să se ia în calcul posibilele riscuri care ar putea să apară în curând și să se creeze strategii de prevenire a lor. Câteva dintre aceste efecte negative potenţiale ale faptului că există dezechilibrul pozitiv între cerinţă și ofertă pe piaţa forţei de muncă ar putea fi (pe termen mediu și lung):

• crearea unui sistem de beneficii și remuneraţii exagerat de mare – care să nu mai poată fi susţinut de clienţi în vii-tor, cu pericolul ca aceștia să se orienteze spre resurse mai ieftine;

• lipsa aplicării unor standarde de per-formanţă reale care să forţeze realizarea calităţii proiectelor livrate către clienţi. Pe scurt, în acest moment, dacă oamenii nu performează la o anumită calitate (chiar și după atenţionări, ajutor în dezvoltare), din cauza lipsei de resurse, probabilitatea să fie daţi afară și să se aplice un standard unitar de calitate care să menţină o ima-gine bună în faţa clienţilor este redusă. Pe termen mediu, acest lucru este periculos, pentru că se vor promova valori scăzute ale calităţii.

• pe o piaţă de forţă de muncă în care, din punctul de vedere al candidaţilor, nu există concurenţă aproape deloc, mecanismele de reglare naturale a non-valorilor nu funcţionează, ceea ce poate duce din nou la scăderea performanţei.

• Am observat că, la nivelul marii majorităţi a angajaţilor, există o ten-dinţă de a se complace în stadiul actual de dezvoltare – care este de înţeles în contextul dat. Orice om ar face la fel: primește venituri foarte bune încă de la primul job, nu are riscuri de a rămâne fără serviciu, „nu se fac valuri” în jurul lui pentru a nu-l supăra ca să plece – atunci, de ce și-ar bate capul acum să se dezvolte personal? Înţelegem perfect această atitudine, însă credem că este o capcană foarte periculoasă în care intră angajaţii din IT și credem că ar fi foarte util ca liderii companiilor să mute accen-tul pe creșterea calitativă în interiorul businessului pe care-l conduc acum și mai puţin pe creștere cantitativă a afa-cerii. Această strategie poate include și mutarea de pe afacerea de outsourcing pe

afacere de produs care presupune iniţial investiţii, poate chiar pierderi financiare până când produce rezultate. Altfel, ce se va întâmpla cu această mare de oameni peste câţiva ani, dacă afacerea de outso-urcing nu va supravieţui la Cluj? Vor fi o mare de șomeri care vor suferi un declin grav în standardul de viaţă, cu abilităţi reduse de adaptare la alte standarde (mai dure), fără un plan de carieră. Sau vor emigra …

Referitor la crearea unei comunităţi IT la Cluj – fapt despre care suntem convinși că ar fi cel mai bun lucru care s-ar putea întâmpla economiei locale și fiecărei com-panii în parte– considerăm că principalele obstacole nu țin de absența facilităților eco-nomice sau a susținerii autorităților, ci de mentalitate: în acest moment, fiecărei com-panii îi merge suficient de bine, încât îi vine foarte greu să se gândească „cum să facem ca și pe viitor să ne meargă la TOŢI bine”? De asemenea, credem că este nevoie de un grup semnificativ de lideri locali (nu ne referim la reprezentanți de multinaţionale care au cumpărat firme locale) cu adevă-rat dedicaţi ideii de comunitate IT clujeană și dornici să creeze rapid o viziune strate-gică pentru această idee.După ce s-ar face primii pași, imboldul pozitiv s-ar propaga destul de repede, deoarece am observat că și în industria IT liderii puternici sunt apre-ciaţi și urmaţi fără probleme.

Suntem conștienţi că unele păreri ale noastre pot stârni controverse – lucru de care ne-am bucura! Mai bine să existe dez-bateri și schimb de opinii, decât o stare de lâncezeală de tipul: „nu ne batem capul cu nimic”.

În concluzie: se cam știe cum ar putea arăta comunitatea IT clujeană (ca ben-chmark). În 2013 pașii concreţi făcuţi în această direcţie au fost, din păcate, extrem de anemici, eventual câteva aprecieri festi-viste. La un moment dat cineva ne poate întreba de ce nu s-a făcut mai mult. Nu vrem? Nu putem?

***Dorim să mulţumim tuturor persoane-

lor care, pe parcursul anului, ne-au onorat cu prezenţa la această iniţiativă de discuţii – fără a avea vreun beneficiu direct, fiind motivaţi doar de dorinţa de a contribui constructiv!

***Sperăm că întreg demersul nostru – cu

toate informaţiile publicate, la vedere, pen-tru oricine este interesat – va fi de ajutor celor care au putere de decizie pe această

piaţă a IT-ului clujean și celor care vor fi interesaţi să transforme o oportunitate fericită într-o poveste economică de succes pentru Cluj și pentru România, arătând astfel că „și la noi se poate!” !

Participanţi la workshop 4

Cosmin Molnar (iQuest) psiholog de profesie, are o experienţă de șapte ani în domeniul Resurselor Umane, trecând prin aproape toate tipurile de companii: auto-motive, producţie, distribuţie, HR și acum, IT. Având aceste experienţe în industrii diferite poate să analizeze foarte obiectiv profilul angajatului din IT și diferenţele specifice. În iQuest este responsabil de pro-vocarea cea mai grea a oamenilor de HR din IT: recrutarea și selecţia de personal… îi dorim succes!

Andrea Tiutiu (Recognos Romania) este o angajată fidelă – din 2007 – a compa-niei cu tradiţie în Cluj: Recognos, trecând prin diverse poziţii în organizaţie: tehnice, administrative și acum resurse umane – completând, în această ultimă poziţie expertiza printr-un masterat de specialitate. A trecut, odată cu compania Recognos, prin schimbările specifice datorate creșterii de la o companie mică la una din ce în ce mai mare. Având aceste experienţe directe în companie poate să înţeleagă mai multe puncte de vedere și nevoile colegilor ei.

Ioana Mihaela Cramba (Recognos Romania) – și-a început activitatea în cadrul firmei în anul 2010, ocupându-se de diverse proiecte de operare și cercetare, cea mai recentă inclinaţie fiind spre cunoaș-terea cât mai bună a departamentului de resurse umane. Dorinţa cea mai mare a ei este de a cunoaște nevoile angajaţilor, de a crea un mediu de lucru competitiv și inovativ și de a aduce valoare adăugată fir-mei. Se ghidează după principiul: “Human Resources aren’t a thing we do. It’s the thing that runs our business.”

Dan [email protected]

Executive director@ Danis Consulting

Cristina [email protected]

Consultant@ Danis Consulting


Deep learning

În decembrie 2013, Facebook a des-chis un laborator de cercetare în domeniul inteligenței artificiale, condus de Yann LeCunn de la Universitatea din New York, unul dintre principalii cercetători în dome-niul „deep learning”.

Deep learning-ul reprezintă o categorie de algoritmi de învățare automată care se remarcă prin faptul că într-o primă etapă învață cum să se prelucreze datele de intrare și ulterior funcția dorită. Până acum, pen-tru recunoașterea de obiecte în imagini, cercetătorii trebuiau să găsească tot felul de trăsături specifice obiectelor, să le extragă din imagini și apoi să aplice un algoritm de clasificare cum ar fi SVM sau Random Forest pentru a determina ce conține fie-care imagine. Pentru unele obiecte s-au găsit trăsături bune (recunoașterea fețelor funcționează destul de bine), pentru altele nu chiar (un tocător de hârtie este greu de descris și recunoscut chiar și de către oameni)3. În contrast, algoritmii de deep learning nu necesită extragerea de trăsături despre categorii în prealabil, deoarece ele învață să facă aceasta în mod automat.

Partea de „deep” din nume provine din faptul că în loc de a avea un singur nivel care primește datele de intrare și ne dă rezultatul dorit, avem o serie de nivele care procesează datele primite de la nivele ante-rioare, extrăgând trăsături de nivel tot mai înalt. Ultimul nivel este cel care se ocupă

1 Microsoft Research shows a promising new breakthrough in speech translation technology

2 Building High-level Features Using Large Scale Unsupervised Learning

3 ht tp : / / w w w. t h e re g i s te r. c o. u k / 2 0 1 3 / 1 1 / 1 5 /google_thinking_machines/

de obținerea rezultatului, după ce datele au fost deja transformate și comprimate.

Filtre învățate de un Restricted

Boltzmann Machine pe MNIST

Începuturile „deep learning”-uluiMarea partea a algoritmilor de deep

learning este reprezentată de diferite forme de rețele neuronale. Prima variantă a aces-tora a fost perceptronul, propus în 1958 de către Frank Rosenblatt, bazându-se pe cercetările lui Warren McCulloch și Walter Pitts. Aceștia au propus în 1943 un model matematic pentru funcționarea neuronilor din creierul animal.

Perceptronul este un model foarte sim-plu: intrarea este înmulțită cu o pondere și apoi toate rezultatele sunt adunate. Dacă rezultatul este mai mare decât o valoare predefinită, atunci rezultatul este 1, altfel este 0. Ponderile acestea trebuie adaptate pentru fiecare set de date în parte. Există un algoritm prin care se pot calcula.

Însă acestui model simplu i s-a des-coperit o problemă majoră: nu funcționa decât pentru date linear separabile. De

În ultimii doi -trei ani a apărut un nou buzzword: deep learning. În 2012 Microsoft a prezentat un demo destul de impresionant care recunoaștea vorbitul în limba engleză, traducea în chineză, apoi reda, cu vocea originală, în chineză, traducerea1.

Tot atunci, Google a realizat un sistem care, din 10 milioane de imagini alese din clipuri de pe YouTube, a învățat singur să recunoască fețe de pisici și alte 22.000 de categorii de obiecte 2.

Roland [email protected]

Junior Python Developer@ 3 Pillar Global

programare



exemplu: în plan, dacă toate punctele care au clasa pozitivă se pot separa cu o dreaptă de punctele cu clasa negativă. Aceasta este o limitare mare, ceea ce a dus la abandona-rea pentru o vreme a rețelelor neuronale .

În 1975, Paul Werbos a descoperit algoritmul „backpropagation”, care permi-tea folosirea mai multor straturi în rețelele neuronale. Dacă în perceptron intrările erau folosite pentru a calcula imediat rezultatul, acum se puteau folosi mai multe straturi, care efectau o prelucrare a datelor din stratul anterior, și se puteau folosi alte funcții de activare (rezultatul nu mai trece brusc de la negativ la pozitiv, ci are o trecere continuă). Hornik a demonstrat teoretic că o rețea neuronală cu un strat ascuns, cu un număr suficient de mare de neuroni, putea să aproximeze orice funcție compu-tabilă, cu o precizie arbitrară4. Algoritmul funcționează în felul următor: inițializezi aleatoriu toate ponderile dintre neuroni și începi să vezi ce valori s-ar obține pentru datele tale de intrare. Calculezi diferența față de valoarea care trebuie să fie obținută și aceasta o „propagi înapoi” pe penul-timul strat, împărțind eroarea în mod proporțional la fiecare neuron, în funcție de ce pondere avea. Această propagare îna-poi se repetă până se ajunge la primul strat și apoi se calculează noile valori obținute. Acest ciclu de corectare se repetă până când eroarea obținută pe datele noastre este sufi-cient de mică (sau până ne-am plictisit să mai așteptăm).

Deci am rezolvat problema, avem algo-ritmul perfect pentru învățare automată? Nu chiar. S-au descoperit alte două pro-bleme. Prima era că numărul de neuroni necesar pentru a aproxima funcții creștea exponențial cu numărul de intrări. O altă problemă era că s-a demonstrat că antre-narea rețelelor neuronale aparține clasei de probleme NP-Complete5, despre care se presupune că nu poate fi rezolvată în timp polinomial.

Din cauza acestor două probleme și a utilizării altor tehnici mai rapide precum arborii de decizie (1986), SVM (1996)sau random forests (1995), rețelele neuronale au fost iarăși neglijate pentru o vreme de marea parte a cercetătorilor. Totuși, unii au obținut rezultate bune cu ele, cum ar fi Yann LeCun cu LeNet (1998). Le Net este un sistem de recunoaștere a cifrelor scrise de mână, folosit la multe bănci, bazat pe rețele neuronale convoluționale.

4 http://www.sciencedirect.com/science/article/pii/0893608089900208

5 http://dl.acm.org/citation.cfm?id=93033

Marea descoperireO schimbare majoră de paradigmă a

apărut în 2006, când Geoffrey Hinton a publicat două articole care conțineau idei noi și revoluționare: „Reducing the dimen-sionality of data with neural networks” și „A fast learning algorithm for deep belief nets”, bazate pe Restricted Boltzmann Machines. Acești algoritmi noi pornesc căutarea pentru parametrii rețelelor neu-ronale din locuri care sunt mai aproape de valorile optimale. Rețelele neuronale se antrenau strat cu strat în mod nesuper-vizat, pentru a găsi structura din spatele datelor, pentru ca la sfârșit să se efectueze corecții fine folosind algoritmul clasic de backpropagation.

Unul dintre testele standard pentru tehnici de învățare automată este MNIST6, care este un set de 70.000 de imagini conținând fiecare câte o cifră. Datele sunt împărțite în două, 60.000 de imagini fiind folosite pentru antrenare, iar 10.000 pentru testare .Se evită astfel situația în care algo-ritmul de învățare automată pur și simplu memorează valorile cu care a fost antrenat, verificându-se dacă este capabil de a gene-raliza și la valori noi. Pe acest set de date, o rețea antrenată în prealabil cu RBM-uri a obținut o eroare de 1%, care la vremea respectivă era printre cinci cele mai bune rezultate.

Structura unui Deep Belief Network,

fomat dintr-o serie de RBM-uri suprapuse.

În 2007 Yoshua Bengio a introdus auto-encodere în locul RBM7-urilor, care au fost apoi dezvoltate și au apărut tot felul de variații, cum ar fi denoising autoencoder8,

6 http://yann.lecun.com/exdb/mnist/7 http://machinelearning.wustl.edu/mlpapers/paper_

files/NIPS2006_739.pdf8 http://www.iro.umontreal.ca/~lisa/publications2/

index.php/attachments/single/176

sparse autoencoder. S-au făcut multe progrese în acest

domeniu de învățare prealabilă, până când în 2010 James Martens a publicat un arti-col în care prezenta un alt algoritm pentru găsirea parametrilor, folosind derivate de ordinul 2 și fără a folosi învățarea nesuper-vizată prealabilă, care obținea rezultate mai bune decât rezultatele de până atunci9.

Tot în același an, Dan Cireșan a ară-tat că nici măcar acest algoritm nu este necesar, ci, folosind algoritmul clasic de backpropagare, cu o rețea adâncă și lată, pe GPU, folosind deformări elastice pe imagini, se pot obține rezultate excelente pe MNIST: 0.35% eroare10. În 2012, același grup a stabilit recordul curent pe MNIST, de 0.23%, care este o eroare mai mică decât cea făcută de oameni în urma clasificării11. De data aceasta au folosit rețele neuronale convoluționale și max-pooling, dar tot fără antrenare prealabilă.

Unde suntem aziC ercul s -a închis ș i am reve-

nit de unde am „început”: ultimele rezultate nu mai folosesc antrenarea pre-alabilă nesupervizată, ci doar algoritmul de backpropagation. Îmbunătățirile se aduc în domeniul funcțiilor de activare ( care se referă la cum se trec datele de la un strat la altul), unde acum sunt la modă „Rectified Linear Units”12, precum și în cel al tehnicilor de regularizare (care ajută la generalizare și previn memorarea intră-rilor) precum maxout13 și dropout14 și la alternarea straturilor convoluționale și a celor de max-pooling.

În articolele următoare se vor pre-zenta avantajele și dezavantajele tehnicilor menționate lor, respectiv cum se pot imple-menta folosind diverse framework-uri de învățare automată.

9 http://machinelearning.wustl.edu/mlpapers/paper_files/icml2010_Martens10.pdf

10 http://arxiv.org/pdf/1003.0358v1.pdf11 http://arxiv.org/pdf/1202.2745v1.pdf12 http://machinelearning.wustl.edu/mlpapers/paper_

files/icml2010_NairH10.pdf13 http://arxiv.org/abs/1302.438914 http://arxiv.org/abs/1207.0580

Schemă a straturilor din LeNet


startups

Nivelul de Monitorizare a Alimentației va colecta date privind activitățile de hrănire a persoanelor în vârstă, precum și date privind contextul în care au avut loc aceste activități (de exemplu: momentul din zi, locația, etc.), folosind noi tipuri de sen-zori cum ar fi:

• Carduri inteligente sau taguri și cititoare RFID (Radio-frequency iden-tification) pentru a detecta alimentele consumate;

• Containere și farfurii inteligente pentru a detecta cantitatea de alimente consumate;

• Senzori inerțiali și de poziție pen-tru a detecta mișcările de ingerare a mâncării;

• Senzori acustici pentru detectarea problemelor de mestecare și înghițire a mâncării;

• Senzori pentru captarea ritmului

cardiac și a presiunii sângelui pentru detectarea reacției psihologice în fața mâncării, etc. .

Nivelul de Evaluare a Alimentației va avea drept scop: (i) identificarea în timp real a activităților și obiceiurilor alimen-tare a persoanelor în vârstă, (ii) construirea unei diagrame de activități în care se va reprezenta comportamentul alimentar al persoanei în vârsta și (iii) identificarea ace-lor comportamente alimentare care sunt nesănătoase. Tehnici de raționare în timp real vor fi dezvoltate și folosite pentru a indentifica activități și obiceiuri alimentare nesănătoase și acele situații critice ce pot pune în pericol viața bătrânului (de exem-plu nu există mâncare în casă, ingerare de alimente incompatibile cu medicamen-tele prescrise, înecare, etc.) și pentru care este necesară alarmarea și intervenția

Detectarea și corectarea obiceiurilor alimentare

nesănătoase la persoanele în vârstă

Studii recente au arătat că, în Europa, mai mult de 15% din populația în vârstă este afectată de malnutriție cauzată în principal de probleme asociate cu procesul de îmbătrânire cum ar fi scăderea sensibilității olfactive și gustative, dificultăți în mes-

tecarea și înghițirea mâncării, dificultăți fizice, uitare, etc.. Totodată problemele de nutriție pot contribui la instaurarea sau exacerbarea bolilor cronice sau acute ale oamenilor în vârstă, accelerarea dezvoltării bolilor degenerative, creșterea timpului de recuperare din boală și pot provoca chiar moartea. În acest context, proiectul DIET4Elders (Dynamic nutrItion bEhavior awareness sysTem FOR the ELDERS), are ca scop dezvoltarea unui sis-tem bazat pe tehnologii inovatoare, care va sprijini și va ajuta oamenii în vârsta în timpul activităților de hrănire zilnice, va detecta timpuriu și va preveni instaurarea malnutriției. Figura 1 prezintă arhitectura conceptuală a sistemului DIET4Elders.

Tudor Cioară[email protected]

Asistent Doctor Inginer@UTCN

cercetare


TODAY SOFTWARE MAGAZINEstartups

asistenților sociali. Tehnici bazate pe predicție și ingineria cunoștințelor vor fi utilizate offline pentru a detecta și infera în mod proactiv acele comportamente alimentare nesănătoase ce pot duce la instaurarea malnutriției.

Nivelul de Servicii Suport va furniza servicii specializate pen-tru: (i) asistarea persoanelor în vârstă și a asistenților sociali asociați în procesul de hrănire vizând detectarea și prevenirea instaurării malnutriției, (ii) sprijinirea nutriționiștilor în stabilirea măsurii în care persoanele în vârstă urmează o dietă prescrisă și totodată în ajustarea dinamică a dietei și (iii) va permite selectarea în mod dinamic, în funcție de dieta prescrisă, a furnizorului de mâncare și comandarea automată a mâncării (Serviciul de Comandă a Mâncării Orientat pe Dietă). Serviciul de Comandă a Mâncării Orientat pe Dietă va agrega serviciile de comandă și livrare a mâncării de la diferiți furnizori și va ghida persoanele în vârstă și asistenții sociali asociați pentru a comanda produsele alimentare care respectă dieta recomandată de către nutriționiști. Selecția de servicii de comandă a mâncării care îndeplinesc criterii complexe, cum ar fi dieta recomandată de nutriționist sau preferințele unei persoane în vârstă nu este o sarcină ușoară și nu poate fi abordată folosind tehnici convenționale, deoarece există o varietate mare de servicii de comandă și livrare a mâncării disponibile online. În acest context, vom modela problema selectării și agregării acestor servicii ca o problemă de optimizare combinațională, cu scopul de a găsi combinația optimă a serviciilor astfel încât crite-riile de căutare specifice să fie luate în considerare. O astfel de problemă de optimizare necesită strategii de căutare inovative, capabile de a identifica soluțiile optime sau apropiate de optim cu un overhead spațial și temporal mic. Pentru ca aceste tehnici să funcționeze eficient, sistemul va crea o piață electronică virtuală bazată pe îmbogățirea descrierii serviciilor de comandă și livrare a mâncării cu informații nutritive, în care furnizorii de produse ali-mentare pot înregistra serviciile lor. Toate serviciile înregistrate și

disponibile pe această piață se vor conforma unui nou model de descriere a serviciilor bazat pe adnotări semantice.

Pentru a aborda obiectivele ambițioase ale proiectului DIET4Elders, consorțiul reunește parteneri cu expertiză specifică în următoarele domenii: telehealthcare (Tunstall Healthcare - cel mai mare furnizor mondial de soluții de telehealthcare), calculatoare și tehnologia informației (Kings College London și Laboratorul de Cercetare Sisteme Distribuite din cadrul Universității Tehnice din Cluj-Napoca), dezvoltare de software (ISOIN) și furnizarea / livrarea de alimente pentru bătrâni (COESCO).

Succesul proiectului va ajuta ulterior la reducerea cos-turilor legate de îngrijirea la domiciliu, asistența medicală, precum și cheltuieli legate de tratarea bolilor de nutriție, care în Europa sunt în prezent estimate la aproximativ 170 de mili-arde de euro pe an.

Figura 1. Arhitectura sistemului DIET4Elders


Tratarea separată a celor două tipuri de reponsabilităţi ar trebui implementată în două nivele (engl. layere) diferite ale aplicaţiei.

Fig. 1 – O posibilă abordare a CQRS

ArgumentareŞablonul recunoaşte că interogarea şi procesarea comenzilor

sunt fundamental diferite.• Procesarea comenzilor respectă reguli de business (engl.

business rules) uneori extrem de complexe care dictează setul de combinaţii valide pentru manipularea datelor. Pentru pro-cesarea comenzilor, considerentele de consistenţă și integritate sunt esenţiale.

• Presupunând folosirea unei baze de date SQL pentru sto-care, normalizarea este foarte importantă pentru procesarea comenzilor.

• Procesarea comenzilor depinde de consistenţa tranzacţio-nală a datelor.

• Procesarea comenzilor poate fi asincronă , ceea ce reprezintă câteodată un beneficiu important de obţinut.

• Interogările nu au cerinţe de integritate, deci nu este nevoie nici de normalizare. Bazele de date denormalizate sunt o alegere

excelentă, pentru că au interogările mai rapide.• Interogările necesită filtre complexe şi agregări de date

în beneficiul interfeţei grafice (engl. GUI - Graphical User Interface).

Având în vedere cele spuse mai sus, are sens să folosim două modele diferite, unul pentru asigurarea regulilor de business şi unul pentru prezentarea informaţiei.

Un aspect important de menţionat este faptul că nivelului de procesare a comenzilor NU îi este interzis să citească date. Citirea datelor este aproape întotdeauna necesară pentru implemen-tarea nivelului de comandă! Este important totuşi de subliniat că cerinţele de citire ale nivelului de procesare a comenzilor sunt fundamental diferite de cele ale nivelului de interogare. De exem-plu, citirile făcute de nivelul de comandă sunt în general legate de cheia primară (engl. primary key) a entităţilor şi logica de citire este implementată direct în nivelul de procesare a comenzilor. În schimb, nivelul de interogare trebuie să furnizeze un mecanism de filtrare pentru a permite utilizatorilor să găsească datele de care au nevoie.

Ca indicii pentru implementare, la folosirea bazelor de date SQL pentru stocare, indecşii bazei de date de procesare a comen-zilor sunt probabil complet diferiţi de indecşii bazei de date de interogare. Pe de o parte, baza de date de procesare a comenzilor nu are nevoie de date istorice, care pot fi şterse în siguranţă, pen-tru a creşte performanţa, iar pe de altă parte, baza de date pentru interogare va păstra probabil datele istorice, pentru un interval rezonabil de timp.

Mergând mai departe pe această idee, există probabilitatea ca baza de date pentru interogare să nu menţină toate datele istorice, ci doar pe cele mai des folosite. Ce înseamnă date istorice folosite des şi pentru cât timp sunt stocate acestea, sunt întrebări al căror răspuns depinde integral de aplicaţie. Referitor la datele istorice cu adevărat vechi, care pot apărea din când în când în anumite rapoarte, acestea trebuie să fie stocate într-o bază de date dedicată raportării, accesată mai rar.

Ceea ce interzice cu adevărat CQRS, este ca nivelul de interogare să facă modificări în date (acces de scriere)! Reţineţi baza de date denormalizată şi asumpţia că nivelul de interogare nu implică considerente de integritate şi nu necesită consistenţă tranzacţională.

Alt argument în favoarea şablonului CQRS este observaţia că frecvenţa de citire este diferită de frecvenţa de scriere. Utilizatorii au de regulă mai multe solicitări de citire pentru fiecare comandă

CQRS este un şablon arhitectural care recomandă separarea responsabilităţilor între procesarea comenzilor (engl. command processing responsibility) şi interogare (engl. query responsibility). Prin urmare, şablonul spune că nu este necesară aceeaşi sursă de stocare de date şi nici măcar aceeaşi tehnologie pentru mecanismele de scriere şi citire.

Command Query Responsibility SegregationCe înseamnă CQRS şi de ce ne interesează?

arhitectură



de scriere (în caz că există). Prin urmare este simplu de înţeles că partea de citire a aplicaţiei are nevoie de scalare mai mult decât cea de scriere.

Mai mult decât atât, nu este nevoie să prezentăm datele din aceeaşi bază de date folosită pentru scriere, deoarece acestea nu trebuie neapărat să fie actualizate instantaneu şi de regulă nici nu sunt. Chiar dacă datele curente sunt citite din baza de date, odată prezentate pe ecran, ele devin deja vechi şi potenţial irelevante.

Aplicaţiile cu încărcare (engl. load) ridicată folosesc ori-cum caching,dar doar ca o optimizare ulterioară nu ca o decizie arhitecturală. Aşa că nu ne rămâne decât să acceptăm cache-ul şi faptul că datele prezentate pot fi vechi, şi să încorporăm aceste realităţi în arhitectura noastră. Astfel aplicaţia s-ar simplifica mult şi ar creşte performanţa, după cum va fi descris în cele ce urmează.

De ce să folosim CQRS? Pe lângă acela de a putea controla scalarea între accesul de

scriere și de citire, CQRS are și alte beneficii, după cum puteţi vedea mai jos:

• Partea de procesare a comenzilor este simplă şi specializată în executarea regulilor de business, fără a fi influenţată de GUI.

• Partea de interogare este simplă și specializată în filtrarea şi agregarea datelor, în beneficiul GUI-ului, fără restricţii referi-toare la modelul folosit pentru scriere.

• Permite ca dezvoltarea GUI-ului şi a părţii de interogare să fie făcute în paralel cu dezvoltarea părţii de procesare a comenzilor.

• Permite nivelelor de interogare și procesare a comenzilor să evolueze diferit în timp.

• Permite fiecărui nivel să utilizeze tehnologii specializate. De exemplu, nivelul de procesare a comenzilor ar putea folosi un ORM (Objct-Relational Mapper), precum Entity Framework, pe când nivelul de interogare nu necesită un ORM complet – ar putea fi suficientă utilizarea unui micro-ORM precum Dapper sau chiar neutilizarea unui ORM. Aceasta este din cauză că nive-lul de interogare nu necesită un identity map (nume de şablon de proiectare) sau gestiunea modificărilor (engl. change tracking), iar aceste facilităţi nu fac decât să reducă viteza interogărilor! Deoarece impune segregarea responsabilităţilor de interogare şi procesare a comenzilor, arhitectura devine mai simplu de migrat către multi-tier, prin înlocuirea, de exemplu, a nivelului de procesare a comenzilor cu un serviciu.

• Datorită acestei separări, este posibil ca programatorii seni-ori să lucreze la domain model-ul pentru procesarea comenzilor, în timp ce juniorii lucrează la achiziţia de date pentru GUI (nivelul de interogare).

• Folosirea CQRS va face aplicaţia mai compatibilă cu teh-nologia Azure, deoarece se pot folosi Table Storage pentru procesarea comenzilor și SQL Database pentru nivelul de inte-rogare. Table Storage nu e foarte potrivit pentru scenarii de raportare ca de exemplu GUI-ul, dar e foarte util (şi are costuri reduse) pentru procesarea comenzilor. În general, presupun că ar fi suficientă utilizarea cheilor de partiţie şi de rând (engl. partition key and row key) pentru accesarea datelor în interesul procesării de comenzi.

Deci, când să nu folosiţi CQRS ?Probabil că nu veţi folosi CQRS la implementarea unor

aplicaţii foarte simple sau în care modelul de scriere e similar celui de citire sau foarte uşor adaptabil. Mai mult decât atât, şi cel mai important, este să nu vă aşteptaţi la schimbări pe viitor, care să

crească complexitatea nivelului de business aşa încât menţinerea ambelor modele (citire şi scriere) în aceleaşi clase să devină greoaie – deşi, în practică, cum aţi putea prezice aşa ceva într-un mediu agil?

În orice caz, cu excepţia aplicaţiilor cu complexitate redusă la nivel de business, care evoluează lent (sau nu evoluează deloc), ar fi recomandat să se planifice şi să se separe cele două mod-ele şi cele două responsabilităţi, chiar dacă nu se vor folosi două baze de date.Din experiența noastră vă putem oferi câteva detalii. Am folosit această strategie şi am implementat două modele: un domain model deplin - pentru partea de procesare a comenzilor, şi un model de citire (de fapt un view-model în limbajul MVC) pentru partea de interogare, folosind aceeaşi bază de date. Am procedat aşa pentru că am simţit că CQRS se referă mai mult la separa-rea responsabilităţilor între procesarea comenzilor şi interogare decât la separarea mediilor fizice de stocare de date. Nivelul de interogare a folosit vederi (engl. views) în timp ce nivelul de pro-cesare a comenzilor a folosit tabele. Avem toate beneficiile CQRS, exceptând scalarea diferenţiată între citire şi scriere, dar totodată şi fără efortul de a sincroniza baza de date de interogare cu cea de procesare a comenzilor. Dacă ar trebui scalare, s-ar putea crea uşor o bază de date de interogare cu tabelele identice cu veder-ile implementate şi doar s-ar adăuga un mecanism ETL (Extract, Transform and Load) pentru sincronizarea cu baza de date de pro-cesare a comenzilor. Totuşi trebuie evidenţiat faptul că schimbarea de la vederile din aceeaşi bază de date, la tabele în baze de date diferite, menţinute în sincronizare prin ETL asincron, ar însemna că aplicaţia nu mai poate presupune că datele modificate sunt dis-ponibile sincron cu executarea comenzilor.

Fig. 2 – Implementarea noastră dedicată de CQRS

CQRS şi practicile AgileSuccesul practicilor Agile în dezvoltarea unui produs nu e doar

o problemă de a implementa corect metodologia aleasă (SCRUM, Kanban, etc.) ci este necesar ca şi arhitectura să permită produsu-lui să evolueze .

Arhitectura rigidă, cuplajul mare, coeziunea scăzută sau complexitatea ridicată contribuie la ceea ce putem numi inerţia aplicaţiei. Ca şi în fizică, inerţia reprezintă rezistenţa aplicaţiei la

startups



arhitectură

schimbare. Evident că astfel s-ar învinge orice încercare de utilizare a proceselor agile în dezvoltarea software, ducând doar la o aplicare superficială a acestora. Prin urmare, CQRS ajută enorm şi chiar şi acest fapt în sine îi justifică utilitatea.

CQRS e benefic şi prin faptul că ne per-mite să avem două modele deconectate în aceeaşi aplicaţie:

• Un domain model care asigură regu-lile de business.

• Un model pentru citire care e optimi-zat pentru ceea ce aplicaţia are nevoie să prezinte pe GUI.

Este important de menţionat că aceste două modele, fiecare gestionat de nivelul corespunzător (cel de procesare a comen-zilor şi respectiv cel de interogare), pot evolua independent, fără a fi conectate. Prin urmare nu există cuplaj între ele, fiecare fiind interesat doar de propriul său scop, având astfel coeziune ridicată - esenţial pentru ca aplicaţia să poată evolua în mod agil.

Prin urmare, dacă ar apărea cerinţe noi referitor la regulile de business, cel mai probabil doar domain model-ul de pe partea de procesare a comenzilor va fi afec-tat. Similar, dacă apar cerinţe noi pe partea de prezentare,poate apărea probabilitatea ca doar modelul de citire de pe partea de interogare să fie afectat. Dar, chiar şi dacă apar cerinţe care ating ambele modele din ambele nivele, fiecare nivel evoluează independent pentru a le face faţă. Această abordare este totuşi mai bună decât schim-barea unui model foarte complex care conţine cele două responsabilităţi.

Mai mult decât atât, agilitatea nu se referă doar la gestionarea cerinţelor funcţionale pe un produs existent, ci şi la felul în care dezvoltăm un produs nou. Ei bine, CQRS ne ajută şi aici, deoarece ne permite să simulăm partea de procesare a comenzilor, permiţând totuşi crearea unui model pentru citire cu un model de interogare simulat. Aplicaţia permite extin-derea framework-ului pe măsură ce noi cerinţe funcţionale apar.

În cele din urmă, abilitatea de a face uşor simulări (engl. mocks) pentru anu-mite componente din aplicaţie este o condiţie importantă pentru a avea aco-perire adecvată cu teste unitare (engl. unit tests). Astfel se permite implementarea TDD (Test-Driven Development) sau a BDD (Behavior-Driven Development) care asigură o fundaţie bună (dacă nu esenţială) pentru orice metodologie agilă

de dezvoltare.

Despre securitateMă bucur că pot spune pe scurt - secu-

ritatea nu este responsabilitatea directă a niciunuia dintre nivele - de interogare sau de procesare a comenzilor.

Securitatea, cu referire la informaţia afişată, poate fi de regulă implementată ca o serie de filtre impuse.Decizia de a impune filtre pe date nu e facută de nivelul de interogare ci mai degrabă de un nivel superior.

Cu privire la securitatea în ceea ce priveşte manipularea datelor de către un actor, aceasta pare mai degraba o problemă de scenarii de utilizare (engl. use cases), deoarece fiecare actor va fi încadrat în unul din rolurile predefinite ale aplicaţiei. Prin urmare, nivelul de comandă nu e respon-sabil cu asigurarea securităţii ci doar cu execuţia comenzilor. A valida dacă un rol dat ar trebui să aibă dreptul să execute o comandă - dependent de rol, de comandă şi de parametrii săi - este sarcina unui nivel superior nivelului de procesare a comenzilor.

Aşadar, decizia de a utiliza CQRS nu are un impact foarte mare asupra consider-entelor de securitate.

RiscuriCa la orice nou şablon, concept sau

tehnologie, şi la CQRS există anumite riscuri în aplicare, cu atât mai mult cu cât el presupune o schimbare de paradigmă. În acest caz, faptul că baza de date pentru citire poate fi diferită de baza de date pen-tru scriere, şi existența a două modele, unul pentru interogare şi unul pentru procesarea comenzilor, reprezintă o schimbări de paradigmă ce implică timp de acomodare până va putea fi aplicată corespunzător.

Totodată, complexitatea aplicației se accentuează pentru că datele modificate nu sunt imediat disponibile pentru prezentare odată ce comanda s-a executat.

ConcluziiCQRS este un şablon puternic datorită

motivelor mai sus menţionate, pe care le vom reitera în cele ce urmează:

• Permite scalabilităţi diferite pentru componentele de scriere şi citire.

• Se bazează pe observaţii solide care arată că citirile sunt mult mai frecvente decât scrierile.

• Permite paralelizarea efortului de dezvoltare pe două nivele.

• Permite menţinerea unui domain

model corect şi pur pe partea de proce-sare a comenzilor, care să nu fie afectat de cerinţele de interogare (acestea s-ar putea schimba relativ frecvent atât în timpul cât şi după implementarea aplicaţiei).

• Permite folosirea tehnologiilor adec-vate pentru procesarea comenzilor şi interogărilor, reducând astfel complexi-tatea aplicaţiei şi durata de dezvoltare şi îmbunătăţindu-i performanţa.

• Reduce complexitatea aplicaţiei prin separarea responsabilităţilor la nivel macro.

• În anumite circumstanţe potenţează aplicarea şablonului domain-driven design (care este în sine un aspect foarte important).

• Permite folosirea diferitelor meca-nisme de persistenţă precum event sourcing , care este foarte potrivit în anu-mite cazuri.

Beneficiul maxim adus de CQRS apare atunci când aplicaţia este complexă şi ar avea nevoie de scalare dar, oricum, CQRS are avantaje chiar şi în cazurile care nu implică scalabilitate.

Recomandăm ca detaliile specifice aplicaţiei să fie analizate înainte de adop-tarea CQRS, dar considerăm că în general utilizarea acestui şablon ar fi o idee bună!

Andrei Pă[email protected]

Software arhitect@ Endava

Command Query Responsibility Segregation


TODAY SOFTWARE MAGAZINE startups

Naţiunea Startup-urilor

Câteva succese răsunătoare de profil au ajuns în titlurile presei și au inspirat alte valuri de antreprenori și investitori să se avânte în apele riscante și totuși, potenţial profitabile, ale startup-urilor. Câteva dintre exemplele recente includ: Waze, o aplicaţie de navigare, cumpărată de Google pentru 1 miliard $ anul trecut; NDS, o companie de software TV pentru care Cisco a plătit 5 miliarde $ în 2012; PrimeSense, pionie-rul senzorilor 3D, cumpărat în toamnă de către Apple, pentru 360 milioane $; Onavo, un startup de analiză mobile, procurat de Facebook contra sumei de 150 milioane $; Trusteer, un startup pentru siguranţa web, ai cărui fondatori și investitori au primit aproximativ 900 milioane $ de la IBM, vara trecută.

În anumite cazuri, succesul mare pre-supune relocarea echipei locale în SUA, dar mulţi dintre acești cumpărători americani transformă startup-urile israeliene în cen-trele lor R&D, expunându-le la pieţe mai mari și dezvoltare ulterioară a mediului hi-tech local. Chiar și atunci când startup-urile eșuează, ceea ce se întâmplă destul de des, profesioniștii căutaţi și antrepre-norii care au relaţii adesea se alătură unor noi companii sau încep afaceri noi, profi-tând de experienţa și contactele lor, având șanse mai mari de succes în afacerile lor ulterioare.

Trăind într-o ţară mică, acoperind o suprafaţă mai mică de 10% din cea a României, Israelienii păstrează legături strânse unii cu alţii. Rar se întâmplă să dureze mai mult de o oră să ajungi la o întâlnire oriunde în ţară. Cultura locală este caracterizată prin putere mică la dis-tanţă; indivizii tind să conteste autoritatea, iar organizaţiile sunt mai orizontale, pre-zentând diferenţe de putere relativ mici între management și angajaţi. Acest lucru facilitează contactul cu aproape oricine, de la un ministru din guvern la președintele unei mari corporaţii. De asemenea, înles-nește găsirea de parteneri și investitori.

Antreprenorii de succes sunt mai mult decât fericiţi să împărtășească poveștile lor și să îi inspire și pe alţii să le urmeze exemplul. Mulţi devin investitori și își pun banii pe care i-au făcut înapoi în economia startup-urilor. Unii devin mentori pentru începătorii promiţători, ghidându-i prin apele tulburi și permiţăndu-le accesul la propria lor agendă rolodex cu contacte de afaceri și capital de risc.

Este necesar un anumit tip de curaj, cunoscut drept „Chutzpah” și pronunţat huuts-pah, pentru a lua o simplă idee și a o transforma într-o afacere mondială. Mai este nevoie de asemenea și de inspiraţie, mentorat cu experienţă și un mediu priel-nic. Din acest motiv, eu ajut la organizarea

primului eveniment „Piraţii Startup” în Cluj, în februarie. Această experienţă inten-sivă care va dura o săptămână este destinată oamenilor talentaţi, cu vise, care sunt dis-puși să își încerce norocul în a le face să devină realitate.

Cum de te-ai mutat din Israel în Cluj? este una dintre primele întrebări pe care le aud de obicei atunci când întâlnesc oameni noi în România. Răspunsul meu este aproape de fiecare dată: „Ei bine, am vrut să dezvolt un startup.”

Puţini oameni iau în serios acest răspuns, având în minte imaginea Israelului drept un rai al startup-urilor. Potrivit rapor-tului Startup Genome, cele mai bune ecosisteme din lume pentru startup-uri sunt: Silicon Valley, Tel Aviv, LA, Seattle, NYC, Boston și Londra, în această ordine. Statisticile oficiale susţin această imagine, arătând aproape 5.000 de startup-uri Israeliene, care atrag investiţii de 2 miliarde $ anual, în cea mai mare parte de la investitori străini.

Dhyan [email protected]

CEO & Co-fondator @ Social ReHub


De ce code metrics?Folosind code metrics, orice membru

din echipă își poate da seama care este sta-rea codului din punct de vedere a calități acestuia. Teoretic acesta poate să detecteze zonele de cod care ar putea să fie problema-tice și să le analizeze.

Pe lângă acest lucru, folosind code metrics, echipa poate să înțeleagă sta-rea proiectului în momentul respectiv, să măsoare într-o formă sau alta cum s-au modificat metricele în timp și să identifice potențialele riscuri.

Cele mai importante metriceExistă destul de multe metrice care for-

mează code metrics. Din punctul meu de vedere, cele mai cunoscute sunt:

• C o m p l e x i t a t e c i c l o m a t i c ă (Cyclomatic complexity) ,

• I n d e x u l d e m e nt e n a b i l i t a t e (Maintainability index) ,

• Adâncimea de moștenire (Depth of inheritance) ,

• Nivelul de cuplare a claselor (Class coupling) ,

• Numărul de linii de cod (Lines of code) .

Definirea și explicarea fiecăreia dintre metrice vă sunt oferite de Bing, economia de spațiu a articolului nu își permite și dezvoltarea acestor aspecte.Ceea ce este cel mai interesant la fiecare metrică este că avem valori “magice” care ne pot spune

dacă valoarea unei metrici este în parame-tri corespunzători sau nu.

De exemplu, când calculăm indexul de mentenabilitate, o valoare între 0 și 9 ne va indica că va fi dificil să facem mentenanță pe codul curent. În schimb o valoare între 10 și 19 ne va indica o zona favorabilă, unde nivelul de mentenabilitate este acceptabil. Orice valoare peste 20 ne va crește încrede-rea în posibilitatea modificării și întreținerii cu ușurință a codului.Dar aceste valori nu sunt bătute în cuie !Pentru că în funcție de proiect, putem să avem în unele zone valori sub 9, dar care nu mai pot fi îmbunătățite din cauza sistemului însuși. Toate metricele ne ajută să identificăm zonele de risc, dar decizia finală doar noi o putem lua.

Avantajul analizării metricelorUn exemplu sugestiv al importanței

metricelor este legat de proiectele noi. Clientul (stakeholder-ul) va forța în fie-care versiune nouă implicarea a cât mai multe funcționalități noi, fără să țină cont că technical dept crește la fiecare iterație. În schimb, acesta observă la fiecare nouă iterație că schimbările necesită mai mult timp și că oamenii noi pe proiect înțeleg codul din ce în ce mai greu. Totodată oamenii care până acum erau deschiși să integreze funcționalități noi sau să modi-fice funcționalități deja existente încep să trimită înapoi orice cerință nouă. Dacă echipa și stakeholder-ul ar fi apelat la

analiza metricelor, ar fi putut detecta din timp problemele și ar fi investit resurse pentru a îmbunătăți calitatea codului.

SonarSonar este o platformă care ne ajută

să facem management la calitatea codului unui proiect. Acesta este un proiect open source pe care oricine îl poate folosi fără nici un fel de restricție.

Ca platformă, Sonar ne aduce o multi-tudine de metrice la distanța unui click. Pe baza analizei codului, putem să generăm diferite rapoarte și să identificăm posibilele defecte pe care le putem avea în cod.

Puncte forteCeea ce face Sonar extrem de bine este

să transmită toată această informație într-un mod simplu și accesibil tuturor. Orice membru din echipă poate să acceseze aceste metrici, să identifice exact metoda sau linia de cod care a generat problema fără să fie nevoie să ruleze tool-uri com-plexe sau să facă analize greoaie.

În acest moment este foarte important de menționat că informația și rapoartele pe care Sonar le generează sunt utile atât dez-voltatorilor cât și managementului. Acesta poate foarte ușor să își dea seama care este starea codului, a proiectului și ce s-a întâm-plat cu acesta în ultima perioadă de timp.

În lumea IT, code metrics sunt cunoscute și apreciate ca fiind foarte importante. Articolul de față își propune să analizeze code metrics din perspectiva unui dezvoltator sau a unui project leader.

Sonar

programare



Cele 7 AxeMetricele pe care le analizează Sonar

acoperă șapte axe importante:1. Cod duplicat – detectarea automată a

codului duplicat.2. Standarde de cod – respectarea stan-

dardelor de cod care există la nivel de proiect.

3. Unit teste – nivelul de cod care este acoperit de unit teste.

4. Complexitatea codului .5. Potențiale bug-uri – detectarea auto-

mată a codului care poate să genereze probleme.

6. Comentarii la cod – nerespectarea standardelor din punct de vederea a comentariilor (nu doar ce se comen-tează și cum, ci și detectarea codului comentat care a fost împins în source control) .

7. Arhitectură și design – validarea arhitecturi și designului pe care pro-iectul îl are.

Pe lângă aceste șapte axe există și șapte “death sins” pe care un dezvoltator le poate face :

1. Să introducă cod duplicat.2. Să nu respecte best practice și stan-

dardele de cod de pe proiect.3. Să nu comenteze codul și API public

expus de aplicație.4. Să creeze componente complexe,

greu de înțeles și care sunt greu de menținut.

5. Să nu aibă codul (în special cel com-plex) acoperit de teste.

6. Să introducă cod care poate să gene-reze posibile bug-uri.

7. Să aibă un design sub forma unor spaghete, unde fiecare componentă acce-sează orice altă componentă.

MetriceSonar ne permite să facem manage-

ment la diferite metrici – așa numitele profile de calitate. Fiecare profil de acest fel poate să fie activat sau dezactivat în funcție de ce necesități avem. Prin acest mod putem să personalizăm rapoartele care se generează doar cu informația de care noi avem nevoie.

În următoarea parte a articolului vom analiza dashboad-urile pe care le avem la dispoziție. Fiecare din acestea se regăsesc în cele șapte axe pe care Sonar le are.

Cod duplicatSonar poate să identifice codul dupli-

cat pe care aplicația noastă îl are. Acesta ne

oferă posibilitatea să navigăm de la nivel de pachet până la nivel de linie de cod și să identificăm codul duplicat. Acesta ne evidențiază toate zonele din cod care conțin codul duplicat pe care noi îl analizăm.

Așadar este foarte ușor să identificăm codul duplicat dar să-l evidențiem și pe cel care a introdus codul duplicat și în ce zone din cod.

Standarde de cod și Potențiale bug-uriAcestea nu se referă doar la modul în

care denumit o metodă ci și ce trebuie să facem cu o resursă unmanaged, manipula-rea unei excepții, detectarea și tratarea unei valori null și așa mai departe.

Prin acest dashborad ne este foarte ușor să facem îmbunătățiri de cod, fără să anali-zăm fiecare linie din cod.

Unit testeAvem posibilitatea să detectăm care

este nivelul de acoperire cu teste a codu-lui pe care îl avem la toate nivele (pachete, clase, metode) și dacă testele au trecut cu succes.

În plus, Sonar ne permite să vedem dacă pentru codul nou adăugat s-au adău-gat test. Cu toți știm că dezvoltatorii spun despre codul vechi că nu era acoperit teste, dar cu acest instrument putem să identi-ficăm codul nou care nu este acoperit de teste.

Complexitatea codului Sonar permite să vizualizăm com-

plexitatea codului din punct de vedere a metodelor, claselor și a fișierelor. Sonar ne permite în orice moment să adăugăm metrice noi. Vă invit să vă jucați cu aceste metrici și să vedeți ce însemnă fiecare din-tre aceste metrici.

Comentarii la cod Acesta detectează modul în care codul

a fost comentat (dacă a fost comentat) și validează aceste comentarii. Sonar separă acest capitol în doua părți. Detectează automat API care este public și gradul de documentație la nivelul acestuia. Totodată focalizează codul și analizează dacă acest cod este comentat precum și calitatea acestuia (dacă comentariile conțin cod comentat).

Arhitectură și design În următoarele rânduri vom prezenta

succint cele mai relevante valori pe care Sonar le detectează.

Package Tangle Index – prin acest

indice detectăm dependințele (circulare și non-circulare) care pot să existe între diferite componente ale aplicației noastre. Acesta ne va indicat cât de ușor putem să facem modificări asupra unui anumit pachet.

Dependencies to cut – este o metrică care ne indică numărul dependințelor care trebuie tăiate. Nu doar atât, dar putem să navigăm la pachetele și fișierele unde avem aceste dependințe.

O altă metrică care este foarte relevantă este Technical Dept. Acest indice ne spune în zile (și financiar) care este costul pen-tru a face mentenanță sau dacă trebuie să modificăm codul. Teoretic, această valoare trebuie să fie ținută cât mai mică. În cadrul acestei metrici intră în proporții diferite: nivelul de cod duplicat, acoperirea cu teste, complexitatea codului, nivelul de comenta-rii și numărul de violări a code standards.

Să nu uităm că …Un alt punct forte a Sonar este extensi-

bilitatea. Pe lângă numărul mare de extensii care există pe piață, acesta ne permite foarte ușor să creăm o extensie nouă sau să adă-ugăm sau să modificăm o metrică deja existentă. Rulând ca o aplicație web, Sonar poate să fie accesat de către orice membru al echipei. Mai este nevoie să menționăm că din fiecare dashboard putem să navigăm în cod foarte ușor. Pornind de la o metrică la nivel de pachet, putem să ajungem la nivel de clasă, metodă și chiar linie de cod, putem să asignăm diferite probleme la colegi și să generăm issues-uri în diferite sisteme în care suntem integrați.

ConcluzieÎn concluzie, Sonar sau un tool asemă-

nător cu acesta nu ar trebui să lipsească din nici un proiect. Sonar ne permite să detec-tăm schimbarea calității codului în timp și zonele din proiect unde calitatea codului scade.

Vă invit să vă jucați cu următorul demo pentru a descoperi lumea Sonar: http://nemo.sonarqube.org/dashboard/

Radu [email protected]

Senior Software Engineer@iQuest

http://nemo.sonarqube.org/dashboard/

http://nemo.sonarqube.org/dashboard/


HR

Cu toate acestea, dacă ne uităm mai atent, Amazon nu este doar un serviciu on-line sau un model de un retailer tradi-ţional, ci o tehnologie intensivă, mai exact o fabrică de inovare – obsedată de crearea noilor tehnologii sau de dezvoltarea de noi modele de afaceri.

Cu peste 180 de brevete acordate numai în 2011, Amazon are un portofoliu de pro-prietate intelectuală ce concurează cu mulţi giganţi ai tehnologiei. CEO-ului Amazon, Jeff Bezos, în ședinţele cu acţionarii, nu vor-bește despre produse sau cumpărături, ci de cum se pot îmbunătăţi serviciile furnizate de către Amazon: fluxul de lucru, sistemele de așteptare, arhitectura orientată spre ser-vicii și analize de date. Aparent o companie de software, cu capacitate de distribuţie Amazon a devenit un simbol tocmai pentru că este dispus să investească într-o continuă dezvoltare și îmbunătăţire a serviciilor, în conformitate cu tendinţele de pe piaţă.

Liderul inovator al Amazon le suge-rează căteva secrete liderilor preocupați de crearea unei culturi a inovaţiei în compa-niile lor :

1. Să nu alergăm după maximizarea profitului pe termen scurt, ci mai degrabă să construim ceva sustenabil și pe termen lung. Bezos spune că el este indiferent la

tunurile pe care le dă piaţa de capital, deoarece investiţiile de pe urma cărora câștigăm cel mai mult sunt acelea în care investim răbdare.

2. Conform acestuia, inovaţia nu are nevoie de un buget ridicat, de un departament R&D, ci mai degrabă de o cultură axată pe satisfacerea nevoilor consumatorului.

3. Regula celor două pizza: Bezos sus-ţine că trebuie să construim echipele așa încât acestea să poată fi hrănite cu două pizza, adică 5 – 7 persoane. Aceasta, pen-tru că echipele mici sunt mai agile, se mobilizează mai repede și fac lucrurile să se miște.

4. Pentru Bezos a face greșeli este necesar, el susţine că la Amazon fiecare angajat este un inventator și că doar prin greșeli se pot perfecţiona serviciile.

5. Companiei care își dorește a fi ino-vatoare, Bezos îi recomandă angajarea pionierilor cu dorinţă de explorare și a celor care își doresc să servească clienţii în moduri noi.

Când vine vorba de leadership-ul inova-tiv aflăm că cei care se încadrează în această categorie sunt un grup restrâns de oameni care mizează întotdeauna pe satisfacerea

Leadership-ul inovativ şi construirea

sistemelor sustenabile

Primele lucruri ce ne vin în minte atunci când auzim de Amazon sunt imprimante, cărţi, jocuri, produse alimentare, jucării, haine, piese auto și multe altele. Amazon a devenit un retailer la nivel mondial,iar pentru Amazon cuvântul caracteristic

este on-line. De la lansarea sa în 1994, misiunea Amazon a fost să devină compania cea mai centrată pe nevoile clientului din lume, unde oamenii pot găsi orice îşi doresc să cumpere, on-line.

programare

Monica [email protected]

Manager@ Artwin



nevoilor consumatorului, fiind convinși că ceea ce produc astăzi nu este un produs perfect pentru tendinţele de mâine.

Animat de îmbunătăţirea constantă a serviciilor furnizate consumatorului, lide-rul inovativ iese de multe ori atât din zona de confort personală cât și a business-ului pe care îl conduce. Pentru că este intere-sat de aplicabilitatea ultimelor tehnologii sau de ultimele trenduri, acesta permite oamenilor să eșueze, deoarece încurajează creativitatea și găsirea de noi soluţii.

Liderul inovativ conduce asertiv, concentrându-se pe crearea unui sistem sustenabil, care este pregătit să răspundă la toate nevoile venite din partea consu-matorului. Acesta construiește un sistem rezistent în fața ambiguității, fiind mai puţin interesat de rezultate financiare imediate.

Deși pare ușor să vorbim despre o cultură a inovaţiei, construirea, costurile și implicaţiile unei astfel de strategii sunt foarte ridicate. În primul rând, oamenii capabili de a implementa aceste strate-gii sunt greu de găsit, iar managementul schimbării este greu și anevoios în orice business.

Vorbim despre o strategie a inova-ţiei atunci când o companie apreciază ca importantă motivarea executivului, atunci când ambiguităţii i se recunosc valențe pozitive,iar angajaţii sunt încurajaţi să pri-vească situaţia și din alte unghiuri decât cele încercate până atunci.

Compania cu un leadership inovativ preţuiește puncte de vedere opuse, apelând deseori la instrumente precum brainstor-ming-ul pentru soluţionarea problemelor și

le oferă angajaţilor spaţiu și libertate pentru creaţie. Psihologii susţin că în urma unor studii aplicate în câteva companii, oameni-lor le este mai ușor să își ceară scuze pentru greșeala pentru care au facut-o decât să își ceară voie de fiecare dată când vor să încerce ceva nou.

Fără a ţine cont de nivelul de mana-gement, liderii care vor să evolueze sau să îşi ajute businessul să supraveţuiască trendurilor în continuă schimare trebuie să se aplece asupra unor tehnici eficiente de stimulare a leadership-ului inovativ. Aceștia pot începe de la flexibilitate și de la dorinţa de a găzdui mai multe opţiuni în soluţionarea problemelor. Implementarea unui set de instrumente ce stimulează ino-vaţia nu doar în departamentele de creaţie ci la toate nivele de activitate, poate dez-volta îmbunătăţiri ale produselor. Liderul inovativ este în permanenţă conectat la noutăţile tehnologice, convins că există o soluţie mai bună, un serviciu mai rapid sau un proces mai puţin costisitor. Cu o per-cepţie realistă a mediului exterior, aceștia adaptează inovaţia la cererea reală a pieţei, încercând să îmbunătăţească constant sta-rea actuală a procesului tehnologic sau a serviciului pe care îl livrează.

Când cultura inovaţiei se dovedește a fi un succes, liderul trebuie să se concentreze și să îşi perfecţioneze abilităţi precum:

• Atenţia: Prima impresie sau presu-punerile nu sunt întotdeauna oglinda imaginii întregi, așadar acestea nu ne duc la o soluţie clară sau bună. Abilitatea de a observa ceea ce nu a fost observat, este prioritară. Ideea este să analizeze ceea ce se întâmplă, să perceapă detaliile și să

creeze noi direcţii.• Importarea: Liderul inovativ trebuie

să fie capabil de a valorifica informaţii din diferite arii de activitate cum ar fi sporturi sau activităţi conexe domeniu-lui de activitate.

• Im a g i n aţ i a ș i v i z u a l i z a r e a : Imaginaţia este un proces care îi ajută pe cei care au nevoie să proceseze infor-maţiile preluate din mediul extern. Acest instrument ajută liderii pentru a răs-punde la întrebări precum: ce ar fi dacă?

• Deschiderea spre opoziţie: Inovaţiile sunt deseori făcute de către lupi singura-tici, dar liderii care încurajează schimbul de idei vor câștiga obţinerea unei imagini mult mai clare a situaţiei .

În concluzie, afirmația frecventă con-form căreia liderul este unul înnăscut nu se verifică întotdeauna. Mai degrabă leaders-hip-ul inovativ presupune o permanentă restructurare, deschidere spre exterior și capacitate de a intui înaintea altora impac-tul revoluționar pe care unele decizii le pot avea asupra pieței.

programare


legal

Claudia [email protected]

Avocat & Consilier în domeniul mărcilor @ IP Boutique

programare

O astfel de relație de outsourcing presu-pune ca Dezvoltatorul să creeze programul/aplicația software în mod personalizat, pe baza instrucțiunilor și cerințelor Clientului, adaptată nevoilor acestuia; iar Clientul, la rândul său, să achite o suma de bani pentru serviciile pe care i le-a prestat Dezvoltatorul.

Fără a-și propune să fie exhaustiv, articolul de față abordează, în principal, perspectiva Clientului și modul în care acesta se poate asigura că drepturile de IP rămân ale sale în contextul outsourcing-ului către Dezvoltator. Așadar, când decideți să externalizați, vă recomand să urmați câțiva pași:

1. Inventar al IP-ului deja existentPrimul pas este să identificați ce ele-

mente de IP dețineți, în ce mod sunt protejate și care dintre ele trebuie dezvăluite pentru scopurile outsourcing-ului (dacă nu este necesar, IP-ul nu ar trebui dezvăluit). Apoi, să verificați dacă contractele pe care le-ați încheiat cu alte persoane (și care vizează atât IP licențiat/cedat de Client către terți, cât și IP licențiat/cedat Clientului

de către terți) vă interzic să dezvăluiți sau să permiteți utilizarea IP-ului de către Dezvoltator, fără permisiunea celuilalt par-tener contractual.

2. Ați identificat Dezvoltatorul potrivit?După ce ați ales Dezvoltatorul și i-ați

verificat reputația, ar trebui să aflați dacă are resursele și capacitățile corespunzătoare pentru a va proteja IP-ul împotriva utilizării neautorizate, pierderii sau furtului.

În plus, poate fi util să aflați care este cadrul legal aplicabil IP din țara Dezvoltatorului și să identificați măsurile pe care sunteți dispuți să le luați în cazul în care înțelegerea de outsourcing se deteriorează sau eșuează. Pregătiți un exit strategy.

3. Clauze-cheie într-un contract de outsourcing

Un contract prin care se stabilesc pe larg termenii relației de outsourcing poate avea un volum foarte mare și poate fi deseori greu de urmărit. Pentru a proteja dreptu-rile IP, puteți avea în vedere câteva principii relativ simple și ușor de reținut:

Externalizarea dezvoltării software. Cum vă puteți proteja

proprietatea intelectuală?

Atunci când vorbim despre externalizarea procesului de dezvoltare a unui pro-gram/aplicație software de către o companie (Client) către un dezvoltator software (Dezvoltator) - relație de outsourcing -, unul dintre cele mai mari riscuri

juridice este legat de proprietatea intelectuală (IP). IP înseamnă drepturi de autor, mărci, desene industriale, brevete, secrete de comerț, know-how, schițe, etc. și poate îmbrăca cele mai diverse forme (baze de date, coduri-sursă, logo, interfața grafică, notițele dintr-o agendă, etc.).



• Insistați ca legea aplicabilă contrac-tului să fie legea română (dacă legea aplicabilă este o lege străină, atunci reco-mandarile din acest articol ar putea fi neaplicabile din punctul de vedere al ace-lei legi).

• Este necesară o clauză privind confi-dențialitatea IP, a informațiilor furnizate de Client, a proceselor interne de lucru, a componentelor programului/apli-cației software, etc. (bineînțeles, în cazul în care nu s-a încheiat deja un contract de confidențialitate – în engleză Non-Disclosure Agreement - NDA).

• Asigurați-vă că dețineți toate dreptu-rile de IP asupra programului/aplicației software creat(e) de către Dezvoltator pe durata relației de outsourcing. De ce? Pentru ca, la finalul relației contractuale sau chiar în timpul acesteia, să puteți exploata acest IP și chiar să îl furnizați altui dezvoltator, dacă preferați.

• Contractul trebuie să specifice, cu detalii, modul în care Dezvoltatorul va proteja IP-ul: cine va avea acces și în ce condiții, faptul că Dezvoltatorul va păstra toate versiunile programului/aplicației software (de exemplu, in Apache Subversion - SVN) și nu va șterge codul sau datele de care nu mai are nevoie, etc. .

• Dezvoltatorul ar trebui să despăgu-bească Clientul în cazul în care încalcă drepturile de IP ale terților atunci când dezvoltă programul/aplicația software comandat(a) de Client, etc. .

4. Ce se întâmplă în lipsa unui contract scris de outsourcing?

În mod obișnuit, în baza legislației pri-vind dreptul de autor, un program/aplicație software creat(ă) de către Dezvoltator la

comanda Clientului, în baza unei relații de outsourcing, este considerat operă la comandă.

Privind opera la comandă, legislația aplicabilă în România prevede că dreptu-rile aparțin autorului (persoana fizică care creează opera – în cazul de față, programa-torul care dezvoltă programul software) – în cazul în care contractul nu prevede altceva. Însă, potrivit aceleiași legislații, angajatorul va deține drepturile patrimo-niale de autor asupra programelor create de programatorul-angajat în timpul exer-citării atribuțiilor sale de serviciu (cu excepția cazului în care contractul încheiat între angajat și angajatorul său nu prevede altceva).

Totuși, este posibil ca legislațiile aplica-bile în alte state să prevadă ca drepturile de autor asupra unui program software-opera la comandă aparțin celui care l-a comandat (adică Clientului).

De aceea, lipsa unui contract scris prin care să se delimiteze clar drepturile și obli-gațiile Clientului și ale Dezvoltatorului, poate duce la confuzie, în special dacă intervin și alte elemente (cum ar fi: națion-alitatea străină a uneia dintre părți - aspect ce duce la un posibil conflict de legi apli-cabile, existența altor acorduri comerciale încheiate între cele două părți privind alte proiecte, etc.).

Claritatea asupra drepturilor de IP este relevantă mai ales în contextul în care Clientul intenționează să folosească unele componente ale programului software și pentru alte proiecte sau când va dori să-l vândă (cumpărătorul va cere să-i garantați

că dețineți în mod legitim ceea ce vindeți).

Note de finalMultor companii le e teamă că dacă vor

apela la un Dezvoltator, acesta ori va folosi programul software nou-creat, pretinzând că îi aparține, ori va folosi know-how-ul la care a avut acces, în favoarea următorului client.

Pentru a evita asemenea riscuri, este in interesul ambelor părți să încheie un con-tract bine redactat privind modul în care funcționează externalizarea dezvoltării software. Doar abordând toate aspectele de la început, Clientul și Dezvoltatorul pot pune bazele unui proiect de succes și a unui parteneriat de durată. De asemenea, nu trebuie pierdută din vedere protecția Clientului față de riscul ca proprii săi angajați să-i prejudicieze drepturile de IP (aceștia au acces la codul-sursă pe care l-au creat și la informatii valoroase din interio-rul companiei). Și în acest caz, un contract de confidențialitate între angajat și angaja-tor ar trebui să fie un mijloc eficient de protecție.

Despre autoare: Claudia Jelea este avocat specializat pe

aspecte ce implică mediul online, comerțul electronic și IT&C, mărcile, drepturile de autor și protecția datelor cu caracter per-sonal. Membră a Baroului București și a Camerei Naționale a Consilierilor în Proprietate Industrială.

LinkedIn & Twitter: claudiajelea | www.jlaw.ro | Facebook: IPBoutique.Legal

www.avocatnet.ro/claudia_jelea

programare


business legal

Zappos, un magazin online de pantofi deținut de gigantul Amazon, se poate lăuda cu un grad ridicat de satisfacție în rândul clienților săi. Problema cu achiziția de pan-tofi online și, prin urmare, riscul cel mai mare în ceea ce privește satisfacția clienților, este că produsele nu pot fi încercate îna-inte de a fi cumpărate, iar cum nimeni nu dorește să dețină pantofi nepotriviți pe care a dat bani, Zappos a trebuit să găsească o soluție. Soluția identificată este aceea de a livra gratuit produsele și de a oferi clienților posibilitatea de a returna pantofii tot în mod gratuit fără a fi nevoiți să justifice deci-zia (i.e. No Questions Asked Policy). Însă, surprinzător, nu aceasta este sursa gradului ridicat de satisfacție a clienților magazinu-lui online.

Zappos estimează data de livrare a pro-duselor și, în mod consecvent, reușește să livreze înainte de termen. Este o tactică interesantă, fiindcă la fel de bine ar putea prezenta clienților săi faptul că livrează gratuit în regim de curierat rapid. Zappos preferă însă să livreze înainte de termen, depășind astfel în mod constant așteptările, fapt ce contribuie în mod direct la gradul ridicat de satisfacție în rândul clienților săi.

Josh Kaufman, autorul cărții “Personal MBA: Master the Art of Business” și inițiatorul mișcării cu același nume, definește calitatea în termeni de percepție. Relația dintre calitate, așteptări și performanță este descrisă de către acesta sub forma unei cvasi-ecuații:

Calitatea = Performanța Livrării - Așteptările Clienților

Tensiunea apare din cauza faptului că așteptările trebuie să fie suficient de ridi-cate astfel încât clienții să aibă un motiv serios pentru a lua decizia de cumpărare, însă suficient de scăzute pentru a permite celui care livrează serviciul sau produsul cumpărat să depășească așteptările setate. Problema cu cei mai mulți oameni de busi-ness în general și vânzători (i.e. oameni de sales) în particular este că aceștia setează așteptările foarte sus, pentru a putea asi-gura vânzarea, însă eșuează în a livra la nivelul acestora, caz în care vorbim de o percepție negativă asupra calității și impli-cit un grad de satisfacție scăzut.

Implicațiile acestor principii sunt sim-plu de expus, însă experiența arată că sunt

Depășirea Așteptărilor

în Asigurarea Calității

Ce poate învața lumea software

de la un magazin de pantofi?

Publilius Syrus, un aforist latin al secolului întâi, î. Hr., spunea: “Nu promite nici-odată mai mult decât poți duce”. Două milenii mai târziu acest principiu este fundamental în business, cu precădere în procesul de livrare a valorii și în deter-

minarea gradului de satisfacție a clienților.

Mihai Nadăș[email protected]

CTO@ Yonder



greu de stăpânit:1. Setarea așteptărilor este funda-

mentală în garantarea unui grad ridicat de satisfacție în rândul clienților. Așteptările sunt de două feluri: implicite și explicite. De cele mai multe ori în relațiile de business se petrece prea puțin timp în a expli-cita așteptările, motiv pentru care prea multe rămân implicite, deci necunoscute ambelor părți (client și furnizor), caz în care riscul ca acestea să nu fie cel puțin atinse este ridicat;

2. Odată setate, așteptările tre-buie depășite pentru asigurarea unei percepții pozitive asupra calității. O livrare înainte de termen va depăși așteptările, determinând satisfacția clienților însă nu și dacă ceea ce s-a livrat nu corespunde cu așteptările setate (sau nesetate, dar existente) inițial;

Aplicații în lumea softwareYonder monitorizează trimestrial

satisfacția clienților prin sondaje de opinie trimise direct celor cu care interacționează echipele de produs în mod regulat. Această abordare are avantaje nete având în vedere că în furnizarea de servicii cea mai bună măsură a performanței este satisfacția clienților. Acesta este motivul pentru care platforme precum TripAdvisor sunt atât de apreciate și populare. Prin măsurarea con-tinuă a satisfacției clienților într-un mod unitar, care pune bazele unei analize isto-rice, reușim să ne îmbunătățim continuu.

Ceea ce am putut observa încă de la primele rezultate este că au existat diferențe mari între rezultatele pe care echipa le aștepta și ceea ce a obținut în final. Din analiza făcută s-a putut concluzi-ona că așteptările implicite care nu au fost explicitate (setate) de la începutul relației au determinat cele mai mari surprize, în mare parte negative. Privind însă din per-spectiva definițiilor de mai sus cu privire la satisfacția clienților și percepția asupra calității, nu există nicio surpriză.

Pornind de la aceste rezultate, una din acțiunile adoptate este abordarea procesu-lui de setare a așteptărilor într-un mod mai riguros. Astfel, înainte de începutul unui nou trimestru la finalul căruia se vor trimite formularele de evaluare către clienți sau la începutul unei noi colaborări persoanele cu rol de Delivery Manager (cei responsabili în final de satisfacția clienților) intră în sesi-uni de setare a așteptărilor. Aici, întrebarea de bază adresată clienților este “ la ce vă așteptați să facem pentru a ne acorda 4 (pe o scara de la 1 la 5) la finalul următoarei perioade de evaluare?”. La finalul discuției așteptările care conduc la obținerea unui scor bun sunt explicitate și conștientizate de întreaga echipă, astfel încât dacă totul merge conform planului, obținerea notei 4 să fie doar o formalitate.

Odată setate așteptările, pasul urmator este identificarea acelor aspecte care pot surprinde în mod plăcut clientul, depășind așteptările explicit setate și contribuind astfel la garantarea unui scor maxim de 5

din 5, performanță aproape imposibil de realizat în lipsa unei înțelegeri asupra felu-lui în care percepția asupra calității poate fi modelată.

ConcluziiCalitatea este un subiect dificil în indus-

tria de servicii, motivul principal fiind faptul că aceasta se bazează pe percepții și nu pe formule matematice. Privind la cvasi-ecuația calității reiese că pentru a garanta o percepție bună asupra acesteia și, implicit, un grad pozitiv de satisfacție în rândul clienților, cei responsabili pen-tru mulțumirea clienților (e.g. Delivery Managers) trebuie să se ocupe, în primul rând, de setarea așteptărilor prin explicita-rea lor și eliminarea celor implicite. Ultimul pas constă în urmă depășirea lor. Așadar urmând exemplul Zappos se poate garanta un grad de satisfacție ridicat.

legal


George [email protected]

Co-founder @ZA Cloud

Business Consultant @SDL

programare programare

Pe Internet, în fiecare minut sunt generate peste 270.000 de tweets, Google procesează peste două milioane de queries, sunt încărcate peste 72 de ore de material video pe Youtube, sunt trimise peste 100 de milioane de e-mail-uri, Facebook proce-sează 350 GB de date și sunt create 571 de website-uri. În fapt, în 2012 au fost create date însumând 2.5 quintilioane de bytes, peste 90% din datele online fiind gene-rate în ultimii doi ani. În acest context, fenomenul Big Data nu schimbă doar teh-nologiile web, ci și modul în care utilizatorii interacționează cu informația.

Avem de-a face cu o schimbare radi-cală de paradigmă. Deja motoarele de căutare generaliste sunt gradual înlocuite de motoare de căutare axate pe domenii (travel, e-commerce, etc.), însă o nouă suită de tehnologii care utilizeaza machine lear-ning, natural language processing, predictive analysis și semantic intelligence au intro-dus deja conceptul de Discovery, care vor înlocui complet modul în care ne găsim datele în online, prin Search.

Search și Discover y sunt două modalități diferite a aborda consumul din informație în online. Căutarea de informație este potrivită atunci când știm ce căutam, însă dacă dorim să aflăm – într-un mod sintetizat și categorizat – ceea ce se întâmplă, în timp real și contextualizat,

răspunsul este conceptul de Discovery. Să luăm ca exemplu experiența de

search folosind motorul de căutare Google. Din momentul în care facem pri-mul search de pe un device nou, query-urile Google vor fi personalizate în funcție de IP și regiune. Apoi, pe măsură ce facem noi și noi căutări și click-uri pe linkurile rezultate, Google va crea un profil specific fiecărui utilizator, generând ceea ce se numește „Search Bubble” sau „Filter Bubble”. Utilizatorii devin constrânși într-un set limitat de rezultate, pe care îl pot schimba doar prin modificarea setărilor din Google, lucru pe care foarte puțini utilizatori îl fac. Care rezultate sunt favorizate în detrimen-tul altora, care sunt rezultatele care devin

O schimbare de paradigmă în online: Discovery vs. Search

Cât de siguri sunteți că informația pe care o căutați prin intermediul motoarelor de căutare online, de genul Google sau BING, este informația de care aveți cu ade-vărat nevoie? Această întrebare, pe cât de simplă, generează două mari probleme:

una de ordin etic – Sunt utilizatorii online constrânși într-o “search bubble”? – dar și una de ordin tehnic – Cum ar putea informația relevantă să ne găsească pe noi, utilizatorii, în loc să o căutam noi?



demoted, fiind afișate după pagina 1 și cât de aproape suntem de informația cu adevă-rat relevantă pe care o căutam - toate aceste aspecte sunt ascunse în filtrul de sugestii al motorului de căutare. O tentativă de rezol-vare a acestei probleme este realizarea unui motor de căutare nediscriminatoriu, de genul www.duckduckgo.com, care însă nu rezolvă problema cu adevărat importantă: cât timp suntem dispuși să petrecem online căutând informația care ne interesează cu adevărat?

Un studiu realizat de Nielsen Norman Group, un think-tank specializat în domeniul online user experience, arată că utilizatorii citesc cel mult 28% din conținutul unei pagini web în timpul unei vizite, 20% fiind media. Aceste date, core-late cu modul în care utilizatorii caută datele online, sunt dovada că paradig-mele pe care a fost construită experiența online în urmă cu peste 10 ani au devenit învechite, nefiind ajustate în funcție de cantitatea enormă de informație generată în prezent și de nevoia utilizatorilor online de a avea acess la informația relevantă cât mai ușor și rapid.

Conceptul de Discovery vine în întâmpinarea acestor probleme, având avantajul de a genera awareness în locul unor răspunsuri exacte, de a pune la dispoziția utilizatorului conținut în timp real, prin monitorizarea domeniilor de interes, de a pune la dispoziția utilizatorului posibilitatea de a selecta conținutul preferat și relevant, dar și de a oferi conținut neașteptat, nou, care să creeze o nouă arie de interes pentru utilizator.

Cum se construiește un motor de Discovery? Chiar dacă acest domeniu ino-vativ este încă într-o fază incipientă, există deja platforme de Content Curation, în special pentru conținutul online de știri sau pentru rețele sociale. O astfel de platformă inteligență a fost construită de compa-nia clujeană ZA Cloud. MediaServista – www.mediaservista.com – este prima

platformă inteligentă pen-tru conținut online din România, care se bazează pe conceptul Discovery. Platforma MediaServista – un produs cloud Software as a Service accesibil prin REST API, este deja folo-sită de site-ul www.stirili.ro, unul dintre cele mai popu-lare agregatoare de știri din România, pentru a livra conținut personalizat utili-zatorilor folosind peste 350 de surse din presa online, de la ziare quality la blo-guri, știri procesând peste 1 milion de articole de la lan-sarea din mai 2013.

La baza unui motor de Discovery se află procesarea datelor, îmbinată cu învățarea activă a preferințelor utiliza-torilor. Folosind tehnologii de Natural Language Processing (procesare natu-rală de limbaj), conținutul online poate fi categorizat automat, indiferent de limbă, pentru a genera o bază de date seman-tică, unde conținutul are înțeles . Pe de altă parte, interacțiunea utilizatorului cu conținutul, ce citește, cât citește, la ce face share pe rețele sociale și ce pagini web sunt semnalate explicit ca fiind preferate, este folosită pentru a crea un profil unic al fiecărui utilizator, lăsând posibilitatea modificării acestui profil într-un mod ușor și intuitiv. Conținutul livrat utilizatorului va fi atât conținut relevant, pe care engine-ul l-a învățat în timp, dar și conținut nou pentru a se asigura că utilizatorul nu cade în capcana Search Bubble. Modul în care conținutul online, procesat în timp real și profilul fiecărui utilizator sunt potrivite pentru a crea o experiență personalizată de tip Discovery, se realizează prin tehno-logii de analiză predictivă. Ce pagină web să fie servită utilizatorului, cât de relevantă este pentru utilizator și cum să fie servită,

aceste operațiuni sunt fundamentul orică-rui motor de Discovery.

Și pentru a realiza o experiență de procesare a informației mai facilă, în care utilizatorul nu este nevoit să citească prea mult text pentru a ajunge la informația relevantă, se poate genera un rezumat automat, folosind tot tehnologii NLP pre-cum și modificarea paginilor web prin impunerea unor elemente semantice. Eliminarea conținutului adițional și pre-zentarea paginii în format read-able plain text sau generarea unor grafice semantice, care prezintă entitățile și locațiile prezen-tate în material sub forma unui grafic ușor de înțeles sunt de asemenea demersuri care conduc la o procesare mai facilă a informației. Pentru a demonstra avantajele sumarizării automate a textului, platforma MediaServista pune la dispoziție o pagină de test pentru limbile română și engleză:w w w . m e d i a s e r v i s t a . c o m /mediaservista-demo/


HR

să aibă un rol cheie în ceea ce înseamnă strategia de business a fiecărei firme de IT. 2014 este anul în care va fi și mai dificil să atragi talente, să le reții în companie, să le oferi training-urile și dezvoltarea de care au nevoie. Cuvântul cheie în ceea ce înseamnă trend-uri HR în acest an este ”inovație” și ”concentrare” (en: focus).

Studiul realizat de Deloitte prezintă un top al celor mai mari dificultăți pe care departamentul de HR le va întâmpina : 1) leadership-ul și 2) retenția. Deși studiul a fost efectuat la nivel global și nu doar în domeniul IT, lipsa de IT professionals din Cluj, demonstrează că aceste două pro-bleme se pot aplica cu ușurință și pe piața locală.

“The war for talent is over, and the talent won.” (Lupta pentru talente s-a încheiat, talentele au câștigat.) Începând cu anul acesta, angajații au un cuvânt esențial de spus și au o putere pe care o pot exercita în companii, pe care nu au avut-o până acum. Angajații de top (en : top performers și top talents) care dețin abilități cheie sunt din ce în ce mai greu de găsit. Pe de altă parte și companiile se diferențează pe piață prin beneficiile finan-ciare și non-financiare pe care le oferă, prin natura businessului proiectelor, dar și prin tehnologiile cele mai actualizate. În aceste

condiții, angajații au o varietate mare în a alege unde vor să lucreze, iar companiile care nu știu să creeze angajament în rândul acestora vor pierde resurse importante.

10 Trend-uri în 2014 pe piața de IT din Cluj.

1. HR privit ca partener de business și nu ca funcție suport

HR-ul acționează ca un partener stra-tegic de încredere pentru liderii de afaceri și proiecte. Elaborează planuri de colabo-rare cu clienții pentru a traduce provocările și obiectivele de afaceri în obiectivele de resurse umane și planuri de acțiune care să se asigure că organizațiile sunt construite pentru a fi capabile să anticipeze schimbă-rile de pe piață. Oferă soluții strategice și durabile de capital uman aliniate la strate-gia companiei, inclusiv abordarea, atragerea și reținerea celor mai bune talente, eficiența organizației, implicarea angajaților și performanță optimă de locuri de muncă.

2. Atragerea și retenția angajațiilor de topCred că abordarea de genul ”recrutarea

celor mai buni de pe piață în defavoarea competitorilor” nu va mai funcționa în condițiile dinamicii care există. Căutările candidaților ar trebui să se extindă dincolo de piața clujeană și extinderea operațiunilor

Trenduri în HR în 2014

Piața clujeană de IT a evoluat extrem de mult în ultimii cinci ani. Cele mai recente studii efectuate arată că există o penurie de seniori IT care să răspundă nevoilor de proiecte. Conform unei statistici efectuate în vara anului trecut, pe piață erau la

momentul respectiv 11 000 de oportunități și doar 9 000 de persoane care activează în IT. Este împrejurarea în care HR-ul poate să iasă din zona de funcție suport și să înceapă

Andreea Pâ[email protected]

Senior Recruiter@ Endava



pe piețele unde există excendent de candidați. Piețele din vestul Europei și Nordul Americii au avut de câștigat prin abordarea strategiei de a lucra ”de acasă” din diferite alte orașe decât cele unde este compania.

3. Poziționarea companiilor pe piață

Lupta este tot mai acerbă pentru a câștiga reputație pe piață și pentru a convinge candidații să considere compania ca fiind prima opțiune în alegerea mediului de lucru. Numeroase studii au fost efectuate pentru a stabili topuri ale companiilor angajatoare. Criteriile care sunt din ce în ce mai diverse: mediul de lucru, implica-rea în comunitate, beneficiile oferite, toate acestea creează o imagine a companiei ca fiind ”un mediu propice de lucru”. Pentru o poziționare cât mai bună, HR-ul are nevoie de o dezvoltare pe orizontală, fiind nevoit să înțeleagă aspecte de marketing, brand management și asocierea numelui companiei cu diverse evenimente din comunitate.

4. Planuri de dezvoltare a carierei pe temen mediu și lung

Companiile IT din Cluj sunt destul de asemănătoare în ceea ce înseamnă mediul de lucru sau beneficiile pe care le oferă. În ceea ce privește retenția angajaților, se remarcă modul în care aceștia au opor-tunitatea să își consolideze o carieră. Este important ca ei să aibă o direcție înspre care să se îndrepte. Cariera ca definiție repre-zintă ”cursul sau progresul unei persoane în viața profesională ”. Dincolo de training-urile și certificările la care angajații din IT au acces, aceștia au nevoie să vadă progre-sul lor pe temen mediu și lung. Referitor la ”career path ”, tendința este de a merge fie înspre o direcție mai tehnică (ex : software architect, technical lead), fie înspre people management (ex : scrum master, project management), iar cu cât companiile oferă aceste oportunități cu atât este mai ușoară

retenția angajaților.

5. Creșterea angajamentului în cadrul companiei Daniel Pink în cartea sa ”Drive” definește trei elemente semnificative în creșterea angajamentului angajaților în companie. Deja clasicele activități de team building oferite de mai toate companiile din zona de IT nu mai sunt elementul definitoriu în creșterea angajamentului.

Pink vorbește despre : automie, măies-trie și scop. În acest articol le voi prezenta doar succint, urmând ca într-un alt număr al revistei să intru mai mult în detalii.

• Autonomie: ROWE – este un acro-nim presentat in carte, care înseamnă ”Results Only Work Environment” adică fără un program fix de lucru. Angajații nu trebuie să fie la serviciu, nu li se impune un program, tot ce tre-buie să facă este să-și îndeplinească sarcinile. Cum, unde și modul în care le duc la bun sfârșit depinde doar de ei. Companiile din vestul Europei și mai ales cele din America au avut rezultate notabile în urma aplicării acestei prac-tici. Încurajarea autonomiei nu înseamnă descurajarea responsabilității, deoarece în final, angajații sunt responsabili pen-tru acțiunile lor.

• Măiestrie: se referă la capacitatea de a excela într-un domeniu. Daniel Pink, consideră că pe lângă autonomie, mai este nevoie de angajament în activitățile pe care fiecare le întreprinde, precum și capacitatea de a găsi soluții inova-tive. Măiestria devine o stare de spirit și înseamnă capacitatea de a înțelege că abilitățile pe care le deții sunt unice.

• Scop: Pink consideră că persoanele cele mai motivate sunt cele care au un scop, au acea dorință de a excela și de a se regăsi în fiecare acțiune pe care o întreprind.

Acest număr al articolului a pre-zentat doar cinci dintre tendințele identificate. Pentru a vă păstra curiozitatea

le voi enumera pe celelalte cinci, urmând ca acestea să fie prezentate în numărul viitor al Today Software Magazine :

• S u b j e c t M a t t e r E x p e r t i s e (Dezvoltarea centrelor de expertiză) ,

• Workforce planning processes (Dezvoltarea proceselor de planificare a forței de muncă),

• L e a d e r s h i p d e v e l o p m e n t (Dezvoltarea abilităților de leadership),

• Talent Analytics (Analiza datelor si a surselor de obținere a lor),

• Innovation (Inovație în departa-mentul de HR).

Succes și multă putere de muncă în 2014 pentru a atrage și reține talentele de top!


startups

De când am lansat RenderStreet, am făcut mai multe pitch-uri decât în tot restul vieţii mele. Și, de la primul pitch ţinut pe scenă HowToWeb în 2012 până acum, am reușit să identific niște factori care pot schimba în bine recepţia mesajului.

Primul factor, care este probabil şi cel mai greu de implementat: fluența în limba engleză este decisivă. La majoritatea evenimentelor, limba oficială este engleza. În plus, majoritatea surselor de finanţare se află (încă) în afară ţării. Deci persoana care va prezenta trebuie să fie cea care este mai familiară cu limba engleză.

Următorul factor: cunoaşte-ţi audienţa. Acelaşi pitch poate fi structurat diferit în funcţie de componența grupului căruia i se adresează. Şi aici voi da drept exemplu modul în care am adaptat pitch-ul nostru pentru trei evenimente diferite, în scopul de a livra de fiecare dată informaţia cea mai relevantă.

Primul eveniment: HowToWeb. Am gândit structura pitch-ului pentru o audi-enţă general-tehnică, în care se aflau și investitori. Am livrat o prezentare gene-rală a afacerii: propunerea, piaţă, evoluţia de la lansare, milestones, echipa, partea financiară. Pentru că audienţă includea și nespecialiști, am insistat la început pe par-tea care se referă la „Ce face RenderStreet?”.

Următoarea susţinere a pitch-ului: EuroCloud. Aici audienţa a fost formată din manageri de diverse niveluri, care aveau în comun interesul legat de cloud. Prezentarea noastră a avut în acest caz un focus pe partea tehnică și, în principal, pe implementarea multi-cloud. Pentru că astfel

de implementări sunt relativ rare în acest moment, am tratat mai detaliat subiectul: provocările din punct de vedere tehnic, soluţiile pe care le-am găsit, problemele la care încă nu avem răspunsuri, avanta-jele obţinute. Detaliile financiare și cele ale evoluţiei firmei prezentau mai puţin interes în contextul respectiv, deci am trecut rapid peste ele.

A treia variantă: Microsoft. Audienţa la acest eveniment era formată în majoritate din jurnalişti. Am început cu o prezentare mai în detaliu a domeniului de activitate, urmată de o privire de ansamblu asupra pieţei şi de o descriere a aplicaţiilor practice ale tehnologiei noastre. Partea vizuală a fost mai bine reprezentată şi am inclus mai multe cifre pentru a uşura formarea unei imagini cât mai clare asupra afacerii.

Concluzia: Fiecare audienţă are preferinţe şi zone de interes bine stabilite. În măsura în care cunoaşteţi componența audienţei, adaptarea conţinutului poate ajuta la o mai bună înţelegere a mesajului.

Şi ajungem şi la conţinut. Există suficiente surse de documentare care spun ce ar trebui să conţină un pitch, aşa că voi puncta câteva aspecte importante:

• Explicaţi foarte clar cu ce se ocupă startup-ul vostru. Dacă feedback-ul pe care îl primiţi la sfârșit începe cu între-barea „..și voi ce faceţi, de fapt?”, atunci pitch-ul a fost un eșec.

• Sintagma „O imagine valorează 1000 de cuvinte” capătă un nou înţeles în con-diţiile în care ai doar câteva minute (în general sub 5) pentru prezentare.

• Slide-urile cu text trebuie să nu fie

aglomerate. În prezentările mele, nu am avut niciun slide cu mai mult de 4 linii de text.

• Informaţi-vă despre piaţă și inclu-deţi cifre relevante în prezentare. Partea referitoare la piaţă va fi înţeleasă de orice audienţă și, dacă cifrele sunt semnifica-tive, va crește interesul pentru produsul vostru.

• „Seeing is believing”. Dacă aveţi un demo, includeţi cel puţin niște screenshot-uri.

Închei cu un ultim sfat: repetaţi pitch-ul de câteva ori în zilele dinaintea evenimentului. Îmbunătăţeşte fluența şi poate ajuta la depăşirea ezitărilor în exprimarea într-o limbă străină.

Succes!

Despre Marius Iatan : Având un background tehnic, Marius a fondat primul său business în anul 2001, la doar un an după terminarea studiilor. În prezent, Marius este co-fondator şi CEO la RenderStreet – un serviciu de randare online pentru proiecte 3D bazat pe tehnologii cloud.

Pitch design. Cum conceptualizezi şi livrezi prezentarea

unui start-up

We are RenderStreet, the next generation render farm for 3D projects. Un pitch de o linie, cu un mesaj simplu și la obiect. Corect, nu? Aparent, da. Dar când pui respectivul mini-pitch în practică, rezultatele vor varia în funcţie de un număr de factori: cât de familiar e destinatarul pitch-ului cu subiectul, cât de atent e, cât de atrăgătoare i se pare propunerea și cât

de bine livrezi discursul. Dacă ai un start-up, atunci știi deja că pitching-ul este una dintre activităţile importante. Deci – cum facem că să iasă bine ?

Marius [email protected]

CEO & Co-fondator@ RenderStreet

http://render.st/

http://startupspotlight.co/finalists/

http://www.eurocloud.ro/renderstreet-primul-start-up-romanesc-nominalizat-la-premiile-eurocloud-europa-2013/#.UqRprNLeDng

powered by

sponsori

today software magazine n19/2014

Documents