Josip Nadih
Autor:
Josip Nadih

Specijalist za BI rješenja

Veza između organizacijske strukture i kvalitete softverskog proizvoda

Razvoj softvera je kompleksna inženjerska disciplina koja uključuje entitete kao što su ljudi, procesi, alati, te interakcije među njima. Može se reći da je broj entiteta i komunikacijskih putova među njima mjera kompleksnosti nekog projekta.

Klasične studije razvoja programskog proizvoda u želji da odrede pouzdanost sustava, te predvide i preveniraju pojavljivanje grešaka, oslanjale su se uglavnom na metode mjerenja promjena u kôdu, kompleksnosti kôda, testiranja kôda, međuovisnosti pojedinih dijelova u kôdu, i sl. Novija istraživanja sve se više bave organizacijskom strukturom razvojnog okruženja. S obzirom da se tipično razvojno okruženje sastoji od desetak do više tisuća inženjera koji su međusobno raspoređeni u hijerarhiji odgovornosti, logično je da se postavlja pitanje kako kompleksnost organizacijske strukture utječe na konačnu kvalitetu programskog proizvoda.

Conway-ev zakon[1] kaže slijedeće:  „Organizacije koje se bave dizajnom sustava ograničene su na proizvodnju sustava koje su kopije komunikacijskih struktura tih organizacija.“ Ova tvrdnja je univerzalna i ne odnosi se isključivo na sustave koji se bave proizvodnjom softvera. Novija istraživanja su i empirijski dokazala tu tvrdnju[2][3], tako da se organizacijska struktura neke organizacije može mjerljivo translatirati na kvalitetu proizvoda koje ta organizacija proizvodi.

Ta tvrdnja je još više izražena u današnjem vremenu kada razvojna okruženja postaju sve više distribuirana jer težnja za smanjenjem troškova razvoja, potreba za širenjem na nova tržišta i potraga za kvalitetnom radnom snagom opciju outsourcing-a čini primamljivom sve većem broju softverskih tvrtki. No je li odluka o outsourcing-u i distribuiranom razvoju, odnosno općenito promjena organizacijske strukture razvojnog tima trivijalna odluka? Može li takva odluka ostaviti dugoročne posljedice na kvalitetu softverskog proizvoda? U nastavku je par ideja i empirijskih istraživanja koje se bave tom problematikom.

Povezanost organizacijske strukture razvojnog okruženja i kvalitete konačnog proizvoda

Conwayev zakon - veza između organizacijske strukture i dizajna sustava

Melvin E. Conway je 1967. godine postavio tvrdnju da se odabirom organizacijske strukture razvojnog okruženja koje radi na dizajnu nekog sustava odmah postavljaju određene granice u slobodi pronalaženja optimalnog dizajna sustava[1]. Drugim riječima, konačni dizajn sustava je u određenoj mjeri zrcalna slika odabrane organizacijske strukture razvojnog okruženja. Conway tvrdi da je svaki sustav koji je predmet dizajna sastavljen od manjih podsustava koji su međusobno linearno povezani (Slika 1.). Na isti način može se prikazati organizacijska struktura razvojnog okruženja, gdje su organizacijski dijelovi također međusobno linearno povezani komunikacijskih kanalima. Općenito se može reći da se svaki sustav, koliko god kompleksan bio, sastoji od čvorova (node), grana između čvorova (branch) i sučelja prema drugim podsustavima (interface).

Linearni graf

Slika 1. Linearni graf sustava

Osnovno pitanje koje se nameće u ovakvoj situaciji je koja je veza između strukture sustava organizacije koja dizajnira sustav i strukture sustava koji je predmet dizajna. Prema Conway-u, odgovor je začuđujuće jednostavan – veza je u nekim slučajevima gotovo identifikacijska, tj. dizajn sustava je zrcalna kopija organizacijske strukture koja dizajnira sustav, dok se u drugim slučajevima kolapsom linearnog grafa može dizajn sustava translatirati u organizacijsku strukturu. Riječ je o pojavi u apstraktnoj algebri zvanoj homomorfizam (homomorphism). Matematičkim rječnikom možemo reći da postoji homomorfizam od linearnog grafa sustava prema linearnom grafu organizacije. Ova veza između sustava i organizacije koja ga dizajnira poznata je kao Conway-ev zakon (Conway's law)[1]. S obzirom da u stvarnim projektima dizajn sustava mora biti prilagodljiv kako bi bio uspješan, Conway zaključuje da je za uspješan dizajn potrebna prilagodljivost organizacije koja ga dizajnira. Ovakva filozofija razvoja sustava pokreće pitanja o vrijednosti resursa u organizaciji te vrijednosti kvalitete komunikacije unutar organizacije koja bi trebala biti transparentna prije nego se krene u dizajn sustava.

Empirijska istraživanja

Od Conwayevog članka u časopisu Datamation 1968. godine prošlo je 40-tak godina prije nego se pojavilo prvo empirijsko istraživanje koje je dokazalo Conwaye-ve tvrdnje. Iako postoji mnogo istraživanja koja na apstraktnoj razini kroz organizacijske teorije istražuju povezanost organizacijske strukture i strukture dizajna sustava, tek su se posljednjih godina pojavile prve empirijske studije koje mjerljivo pokazuju direktnu vezu između organizacije i proizvoda.

Korištenje analitičke DSM metode za mjerenje modularnosti sustava

Godine 2008. poslovna škola na Harvardskom sveučilištu (Harvard Business School) objavila je empirijsku studiju koja istražuje dualnost između proizvoda i organizacijskih arhitektura, tj. provjerava točnost hipoteze o zrcalnoj vezi među njima[2]. U dokazivanju te hipoteze korištena je analitička tehnika zvana Design Structured Matrices (DSM) koja omogućava vizualizaciju arhitektura softvera i mjerenje usporedbe modularnosti različitih softverskih proizvoda. Istraživanje se fokusira na usporedbu Open Source i zatvorenih razvojnih okruženja (proprietary development) usporedbom različitih programskih proizvoda sličnih kompleksnosti te istih funkcionalnosti proizvedenim u različitim razvojnim okruženjima. 

Svaki softverski proizvod je baziran na informaciji, odnosno njegov dizajn je baziran na nizovima instrukcija (source code) koji obavljaju određene zadatke bez obzira da li se radi o objektno-orijentiranim ili proceduralnim jezicima. S obzirom na takav dizajn moguće je automatikom identificirati međuovisnosti koje postoje između različitih dijelova kôd-a. Takve međuovisnosti mogu zatim otkriti različite aspekte strukture dizajna softverskog proizvoda. Konkretno, na slici 2. vizualno je prikazan jednostavan primjer međuovisnosti dijelova sustava i matrica vidljivosti (Visibility Matrix) za taj sustav. Matrica vidljivosti sadrži informaciju o direktnoj međuovisnosti elemenata u sustavu.

Linearni graf

 

A

B

C

D

E

F

A

0

1

1

0

0

0

B

0

0

0

1

0

0

C

0

0

0

0

1

0

D

0

0

0

0

0

0

E

0

0

0

0

0

1

F

0

0

0

0

0

0

Slika 2. Linearni graf i matrica vidljivosti sustava

Kako bi došli do informacije o mjeri ukupne međuovisnosti elemenata u sustavu, direktnoj i indirektnoj, potrebno je napraviti derivaciju matrice vidljivosti, koja je prikazana na slici 3. Gustoća matrice vidljivosti je mjera ukupne modularnosti sustava, a ta veličina se još naziva i propagacijski trošak (Propagation Cost). Propagacijski trošak u stvari govori o tome koliko će kompleksne (odnosno skupe) biti promjene pojedinog dijela sustava s obzirom na međuovisnosti s ostalim dijelovima sustava. U slučaju u primjeru propagacijski trošak će iznositi 42% (omjer broja jedinica prema ukupnoj veličini matrice). To je pojednostavljeni primjer matematičkog modela korištenog u ovom istraživanju. 

M0

M1

M2

 

A

B

C

D

E

F

 

A

B

C

D

E

F

 

A

B

C

D

E

F

A

1

0

0

0

0

0

A

0

1

1

0

0

0

A

0

0

0

1

1

0

B

0

1

0

0

0

0

B

0

0

0

1

0

0

B

0

0

0

0

0

0

C

0

0

1

0

0

0

C

0

0

0

0

1

0

C

0

0

0

0

0

1

D

0

0

0

1

0

0

D

0

0

0

0

0

0

D

0

0

0

0

0

0

E

0

0

0

0

1

0

E

0

0

0

0

0

1

E

0

0

0

0

0

0

F

0

0

0

0

0

1

F

0

0

0

0

0

0

F

0

0

0

0

0

0

M3

M4

V=ƩMn;n=[0,4]

 

A

B

C

D

E

F

 

A

B

C

D

E

F

 

A

B

C

D

E

F

A

0

0

0

0

0

1

A

0

0

0

0

0

0

A

1

1

1

1

1

1

B

0

0

0

0

0

0

B

0

0

0

0

0

0

B

0

1

0

1

0

0

C

0

0

0

0

0

0

C

0

0

0

0

0

0

C

0

0

1

0

1

1

D

0

0

0

0

0

0

D

0

0

0

0

0

0

D

0

0

0

1

0

0

E

0

0

0

0

0

0

E

0

0

0

0

0

0

E

0

0

0

0

1

1

F

0

0

0

0

0

0

F

0

0

0

0

0

0

F

0

0

0

0

0

1

Slika 3. Derivacija matrice vidljivosti

Autori studije spretno su iskoristili činjenicu da su neki proizvodi razvijeni u zatvorenom razvojnom okruženju u određenom trenutku postali Open Source aplikacije, tako da su mogli usporediti početnu verziju source kôda aplikacije kad je postala Open Source i zadnju verziju aplikacije koja je razvijana u Open Source okruženju. Tako su mogli dobiti realnu sliku promjene  u arhitekturi aplikacije u odnosu na promjenu razvojnog okruženja. Konačna usporedba troška propagacije u aplikacijama u različitim područjima primjene prikazana je na slici 4.

Područje

Open Source okruženje

Zatvoreno okruženje

Tolerancija

upravljanje financijama

7.74%

56.06%

p<0.1%

tekst procesor

8.25%

41.77%

p<0.1%

tablični kalkulator

23.62%

54.31%

p<0.1%

operativni sustav 1

7.18%

22.59%

p<0.1%

operativni sustav 2

7.21%

24.83%

p<0.1%

baze podataka

11.30%

43.23%

p<0.1%

Slika 4. Usporedba propagacijskog troška u Open Source i zatvorenim okruženjima

Rezultati su vrlo zanimljivi. S obzirom da je propagacijski trošak aplikacija u Open Source razvojnom okruženju osam puta manji nego u zatvorenom razvojnom okruženju, nema sumnje da je empirijski dokazano da Open Source aplikacije imaju modularniju arhitekturu od onih proizvedenih u zatvorenom razvojnom okruženju, s obzirom da je organizacijska struktura Open Source razvojnog okruženja također modularnija. Kako modularnost aplikacije utječe na kvalitetu i druge aspekte aplikacije je tema za neko drugo istraživanje, ali početna hipoteza da je dizajn sustava refleksija organizacijske strukture koja dizajnira sustav je dokazana. Autori zaključuju istraživanje s preporukom da voditelji projekata moraju težiti tome da razumiju utjecaj odabira organizacijske strukture na dizajn aplikacije i konačnu kvalitetu proizvoda. Također autori napominju da ovo istraživanje ima sve veće implikacije s obzirom na trend distribuiranog razvoja softvera.

Predviđanje kvalitete konačnog proizvoda korištenjem organizacijske metrike

Iste godine (2008.) objavljeno je istraživanje koje je proveo Microsoft, a vezano je uz predviđanje kvalitete konačnog proizvoda korištenjem organizacijske metrike[3]. Istraživanje se odnosi na razvojni proces Windows Vista aplikacije  i obuhvaća preko 50 milijuna linija kôda, nekoliko tisuća razvojnih inženjera koji su sudjelovali u razvoju i nekoliko milijuna krajnjih korisnika diljem svijeta. S obzirom na te činjenice, to je jedno od najvećih istraživanja ikada provedenih vezano uz razvoj komercijalnog softvera.

Istraživanje je fokusirano na traženje empirijske povezanosti između pojavljivanja grešaka u programskom proizvodu i organizacijske kompleksnosti u procesu razvoja programskog proizvoda, te definiranja kvantitativne metrike u tom smjeru. Autori navode da su se dosadašnja istraživanja komercijalnog softvera oslanjala isključivo na metriku kôda aplikacije (kompleksnost, promjene, testiranje i međuovisnost) kako bi se predvidjelo pojavljivanje grešaka u aplikaciji. U ovom istraživanju oni se oslanjaju na metriku organizacijske strukture razvojnog okruženja za istu svrhu. Istraživanje je podijeljeno na nekoliko etapa:

  • definiranje organizacijske metrike u domeni razvoja softvera
  • izrada metodologije za predviđanje grešaka u softveru korištenjem organizacijske metrike
  • istraživanje da li organizacijska metrika ima bolju preciznost u predviđanju pojavljivanja grešaka u softveru od klasičnih metoda
  • kvantifikacija važnosti iskustva rada inženjera na prijašnjim verzijama softvera koji sudjeluju u razvoju nove verzije

Organizacijska metrika, kako je definirano u istraživanju, oslanja se na slijedećih osam parametara:

  • NOE (Number of Engineers) – broj inženjera koji su sudjelovali u pisanju kôda i koji su i dalje zaposleni u tvrtki
  • NOEE (Number of Ex-Engineers) – broj inženjera koji su sudjelovali u pisanju kôda, ali više nisu zaposleni u tvrtki
  • EF (Edit Frequency) – ukupan broj promjena u kôdu
  • DMO (Depth of Master Ownership) – mjera vlasništva nad kôdom, odnosno mjera koja određuje na kojem nivou unutar organizacijske jedinice je inženjer kojem inženjeri ispod njega imaju 75% udjela u promjenama na kôdu; što niži nivo vlasništva, to je manja potreba za komunikacijom i veća odgovornost
  • PO (Percentage of Org contributing to development) – omjer ljudi koji rade promjene na kôdu na DMO nivou u odnosu na ukupan broj ljudi tom nivou
  • OCO (Level of Organizational Code Ownership) – postotak promjena od strane organizacije koja ima vlasništvo nad kôdom, a ako nema vlasnika, tada se uzima u obzir organizacija koja je imala većinu promjena na kôdu
  • OOW (Owerall Organization Ownership) – omjer broja inženjera koji su sudjelovali u razvoju u organizaciji koja ima vlasništvo nad kôdom u odnosu na ukupan broj inženjera koji su sudjelovali u razvoju
  • OIF (Organizational Intersection Factor) – mjera ispreplitanja različitih organizacija koje su sudjelovale u pisanju kôda u omjeru većem od 10%

Metodologija predviđanja grešaka koja se oslanja na organizacijsku metriku definirana je na način prikazan na slici  5.

Tvrdnja

Metrika

Što više ljudi radi na kôdu to je manja kvaliteta.

NOE

Velik gubitak članova tima utječe na gubitak znanja, a tako i na kvalitetu.

NOEE

Što je više promjena na komponentama, to je veća nestabilnost, a time i manja kvaliteta.

EF

Što je niži nivo vlasništva, veća je kvaliteta.

DMO

Što je veća organizacijska kohezija među ljudima koji su radili na kôdu to veća kvaliteta.

PO

Što veća kohezija promjena to je veća kvaliteta.

OCO

Što je veća difuzija inženjera koji rade na kôdu to je slabija kvaliteta.

OOW

Što je veća difuzija različitih organizacija koje rade na kôdu to je slabija kvaliteta.

OIF

Slika 5. Opis organizacijske metrike u kontekstu metodologije za predviđanje grešaka

Studija je provedena na način da su podaci definirani u organizacijskoj metrici prikupljani za svaku verziju Windows Viste u produkciji. Na osnovi tih podataka najprije je izgrađeno hijerarhijsko stablo čitave organizacije, a zatim je napravljena statistika promjena u kôdu na osnovi VCS (Version  Control System) sustava. Statistika se mjerila nad 3404 datoteka koje ukupno imaju preko 50 milijuna linija kôda. Mjera kvalitete su bile pogreške u radu sustava nakon svake verzije u produkciji. Takve greške mjerile su se prvih šest mjeseci nakon što je proizvod pušten u produkciju. 

Kako bi se kvantificirale korelacije između parametara organizacijske metrike, autori studije proveli su Spearmanovu korelaciju, a brojevi koje su dobili bili su empirijski dokaz međuovisnosti parametara u organizacijskoj metrici. Drugim riječima, dobili su kvantitativni dokaz veze između organizacijske strukture i kvalitete softvera. Također, na osnovi prikupljenih statistika, prvi puta su napravljena mjerenja na koji način iskustvo inženjera koji su radili na prijašnjim verzijama softvera utječu na kvalitetu.

Kod predviđanja grešaka na osnovi organizacijske metrike, u matematičkom modelu najprije se koristi logistička regresija kako bi se za elemente sustava izračunalo u kojoj mjeri su podložni greškama (Failure-pronenness). Što je veća podložnost greškama neke komponente, to je veća vjerojatnost da će se u post-produkcijskoj fazi desiti greška na toj komponenti. Kako bi se elementi svrstali u dvije kategorije, oni podložni greškama i oni koji to nisu, potrebno je definirati donju granicu tolerancije, odnosno LCB (Lower Confidence Bound). Nakon definiranja donje granice tolerancije, autori su provjerili putem dvije metode da li su svih osam parametara organizacijske metrike potrebni u logističkoj regresiji, odnosno da li utječu na preciznost predviđanja. Obje metode dale su potvrdan odgovor za svih osam parametara. 

Točnost predikcijskog modela autori studije određivali su s dvije varijable: preciznost (Precision) i provjera (Recall). Na slici 6. prikazana je tablica klasifikacije pomoću koje su definirane varijable preciznosti i provjere.

 

 

Predviđeno

 

 

Nije podložno greškama

Podložno greškama

Stvarno

Nije podložno greškama

a

b

Podložno greškama

c

d

Slika 6. Tablica klasifikacije

Preciznost (P) je definirana kao udio točno predviđenih elemenata koji su podložni greškama prema slijedećoj jednadžbi:

P = d/(b+d)

Provjera (R) je definirana kao udio točno identificiranih stvarnih slučajeva koji su podložni greškama prema slijedećoj jednadžbi:

R = d/(c+d)

Teoretski, savršena predikcija bila bi u situaciji gdje je P = R = 1. Mjerenja su provedena sa 99%-tnom točnošću, a rezultati predikcije u usporedbi s nekim klasičnim modelima predikcije dani su na slici 7.

Model

Preciznost

Provjera

Organizacijska metrika

86,2%

84,0%

Promjene u kôdu

78,6%

79,9%

Kompleksnost kôda

79,3%

66,0%

Međuovisnosti

74,4%

69,9%

Pokrivenost kôda

83,8%

54,4%

Greške u pred-produkciji

73,8%

62,9%

Slika 7. Usporedba preciznosti modela previđanja pojavljivanja grešaka

Zaključak koji se nameće je da organizacijska metrika daje značajno preciznije rezultate od tradicionalnih metoda u predviđanju pojavljivanja grešaka u post-produkcijskom razdoblju, odnosno predviđanje kvalitete konačnog proizvoda. Nakon objavljenih rezultata studije autori su započeli suradnju s Fraunhofer research institute, kako bi napravili paralelno istraživanje za više softverskih proizvoda od više različitih proizvođača kako bi se još se više uvjerili u točnost rezultata ovog istraživanja.

Zaključak

Conweyeve pionirske ideje iz 60-tih godina prošlog stoljeća o utjecaju organizacijske strukture na kvalitetu konačnog proizvoda nisu izgubile značaj u današnjem vremenu neizbježnog trenda sve većem okretanju distribuiranom razvoju softvera i outsourcing-u.

Iz prvog istraživanja[3] jasno je da Open Source rješenja koja se oslanjaju na distribuirani razvoj imaju modularniji dizajn, te samim time i manji propagacijski trošak pri uvođenju promjena u sustav. Možda bi komercijalni proizvođači softvera mogli ponešto naučiti od Open Source zajednice koja već desetljećima uspješno koristi specifične metodologije i alate u distribuiranom razvoju softvera.

Iz drugog pak istraživanja[4] vidljiv je direktan utjecaj promjena u organizacijskoj strukturi u procesu razvoja na pojavljivanje grešaka u pojedinim dijelovima sustava nakon isporuke. Korištenjem organizacijske metrike moguće je s velikom preciznošću predvidjeti u kojim dijelovima kôda će se pojaviti više grešaka u postprodukcijskoj fazi, npr. tamo gdje je bila velika fluktuacija inženjera u procesu razvoja.

Zaključak je da je za kvalitetan dizajn i razvoj bilo kakvog sustava nužno posvetiti pažnju organizacijskoj strukturi razvojnog tima u smislu odabira načina razvoja (outsourcing/distribuirani razvoj da ili ne?), odabiru razvojne metodologije, načinu ostvarenja kohezije u timu, te zadržavanju iskusnih inženjera (osobito onih koji su sudjelovali u razvoju ranijih verzija proizvoda), a time i očuvanju baze znanja na kojoj se bazira core business organizacije. Studija Carnegie Mellon sveučilišta iz 2001. godine[4] provedena na velikim distribuiranim projektima razvoja softvera zaključuje da za razliku od tradicionalnih teorija koje sugeriraju koordiniranje timova isključivo putem organizacije zadataka i komunikacije unutar tima, u distribuiranom okruženju je od presudne važnosti da se svi članovi tima kroz komunikaciju dubinski upoznaju s problematikom na projektu što će im omogućiti implicitnu koordinaciju među sobom. Drugim riječima, u početnoj fazi članovi tima su učenici koji usvajaju znanja, uče metodologiju i savladavaju korištenje tehnologijom, ali bi u konačnici trebali prijeći u fazu kada postaju aktivni sudionici na projektu u smislu da postanu inicijatori i generatori novih ideja, te na taj način značajnije doprinesu projektu. Dok je u prvoj fazi nužno striktno slijediti metodologiju i koristiti zadane okvire interakcije, evolucijom u drugu fazu tim postaje tim u punom smislu te riječi, gdje svi članovi tima ravnopravno preuzimaju odgovornost za uspjeh projekta, svaki u svojem segmentu. U drugoj fazi tim je sposoban zajedničkim snagama razviti vlastite načine kolaboracije, a također i nadograditi metodologiju koju koriste za svoje specifične potrebe.

Reference

  1. Melvin E. Conway, „How Do Committees Invent?“, Datamation magazine,  1968., http://www.melconway.com/research/committees.html
  2. Alan MacCormack, John Rusnak, Carliss Y. Baldwin, „Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis“, Working paper, Version 3.0, Harvard Business School, 2008., http://www.hbs.edu/research/pdf/08-039.pdf
  3. Nachiappan Nagappan, Brendan Murphy, Victor R. Basili, „The Influence of Organizational Structure on Software Quality: An Empirical Case Study“, TechReport, Microsoft Research / Association for Computing Machinery Inc., 2008., http://research.microsoft.com/pubs/70535/tr-2008-11.pdf
  4. J. Alberto Espinosa, Robert E. Kraut, Sandra A. Slaughter, Javier F. Lerch, James D. Herbsleb, and Audris Mockus „Shared Mental Models, Familiarity and Coordination: A Mulit-Method Study of Distributed Software Teams“, 2001., http://repository.cmu.edu/cgi/viewcontent.cgi?article=1094&context=hcii

Popularne teme
.NET ABAP ADFS Agile Always On Anemic Model Angular Azure Backbone benchmark BI BI projekti Bootstrap building people business inteligence Business Intelligence Change Chrome CI CITCON Claims compile Continuous Delivery continuous deployment Continuous Integration CSR d3js data data visualization Data visualization alati DDD dekompozicija dependency injection dinamička forma dinamički parametri dinamički query distribuirani razvoj Domain-Driven design DOP društvena odgovornost edge-based video analytics Eliminating waste enkapsulacija enterprise razvoj softvera ERP ETL Excel FIORI Frontend game Geopackage GPKG GIS Git Groovy heat map HICCUPS Hichert HTML IBCS interoperability invision IoT IPSO izvještavanje java JavaFX Javascript Jazz Build Engine JBE Jenkins jquery jqueryui jsfiddle JVM Kaizen Kanban king KING ICT Kingovci Knockout kvaliteta lambde leadership Lean legacy code M language Management Maven Metodologija microservices Microsoft mobile Mobility mockups moć monday game NetWeaver network nodejs oblikovni obrasci OGC OKR open source optimizacija organizacija organizacijska struktura OutOfMemoryError outsourcing overengineering paginacija Performance performanse PERT PMI PMP; Agile; Project management; Scrum; KING ICT; razvoj; metodologija podatkovni skup pouzdanost Power BI Power Map Power Pivot Power Query Power View pretraga proces procjena Product Owner programming proizvod Project manager projektni plan radar Rational Team Concert razvoj tima refaktoriranje Release resize responsive charts REST retrospektiva Rich-Domain model Roko Roić rolling wave planning RTC SAP scale scatterplot chart Scrum scrum team scrum tim service boundaries single responsibility principle Single Sign-On smart metering SoapUI social responsibility softver Software software prototyping Software Testing Club Spring Boot SQL standard sustav videonadzora svg tdd Team team building team development Team Foundation Server tech tehnologije terminski plan Testing tim timesheet timovi Toggl.com touch transakcijski nadzor tražilica underengineering unit testing Uspjeh Visual Studio vodstvo vodstvo leadership moć društvena odgovornost DOP social responsibility CSR vođenje projekata WBS Web Zagreb STC

PRIJAVA NA NEWSLETTER

Najnovije novosti iz ICT svijeta