Skoči na glavni sadržaj

Prethodno priopćenje

https://doi.org/10.31784/zvr.11.1.8

VIŠEKRITERIJSKA ANALIZA METODOLOGIJA ZA UPRAVLJANJE PROJEKTIMA U IKT SEKTORU

Nikola Kadoić orcid id orcid.org/0000-0002-8455-9105 ; Docent, Fakultet organizacije i informatike (Sveučilište u Zagrebu) Pavlinska 2, Varaždin, Hrvatska
Nikolina Žajdela Hrustek orcid id orcid.org/0000-0002-6311-4772 ; Izvanredna profesorica, Fakultet organizacije i informatike (Sveučilište u Zagrebu) Pavlinska 2, Varaždin, Hrvatska
Josip Fudurić orcid id orcid.org/0009-0008-8718-0468 ; Programer, Omega Software Kamenarka 37, Zagreb, Hrvatska


Puni tekst: hrvatski pdf 215 Kb

str. 131-149

preuzimanja: 170

citiraj

Preuzmi JATS datoteku


Sažetak

Razvojem novih metodologija za upravljanje projektima otvaraju se mogućnosti za bolje planiranje,
nadzor i kontrolu projekata i ostvarenja krajnjeg cilja izvođenja svakog projekta što podrazumijeva i
njegovu uspješnu realizaciju. U ovom radu fokus je na četiri najpopularnije metodologije za upravljanje
projektima u IKT sektoru: agilne metodologije Scrum i Kanban, nešto tradicionalnija ali uvelike
korištena metodologija vodopadnog pristupa te novija OpenPM2 metodologija. Cilj rada je temeljem
analize literature o navedenim metodologijama napraviti usporednu analizu te tako identificirati
kriterije usporedbe metodologija i izraditi hijerarhijsku strukturu problema odlučivanja kako bi
se potom mogla primijeniti metoda analitički hijerarhijski proces i moglo odlučiti o najpogodnijoj
metodologiji za konkretnu organizaciju u IKT sektoru u kojoj se planira provoditi projekt. Razvijeni
opći model odlučivanja o metodologijama za upravljanje projektima može se dopuniti specifičnim
zahtjevima organizacije ukoliko je to potrebno.

Ključne riječi

vodopadni model; SCRUM; Kanban; OpenPM2 metodologija; AHP

Hrčak ID:

302826

URI

https://hrcak.srce.hr/302826

Datum izdavanja:

31.5.2023.

Podaci na drugim jezicima: engleski

Posjeta: 895 *




1. UVOD

Da bi određeni projekt doživio uspjeh, važno je da bude dobro vođen. Dok se jednostavniji i kraći projekti mogu uspješno izvršiti i bez primjene sustavnog i metodološkog pristupa, složeniji i dugotrajniji projekti zahtijevaju primjenu sustavniji i strukturirani pristup. Stoga su i razvijeni različiti koncepti, metode i metodologije koje olakšavaju i optimiziraju upravljanje kompleksnih i dugotrajnih projekata. Metodologije za upravljanje projektima primjenjuju se u različitim područjima, a u velikoj mjeri i u području informacijsko-komunikacijskih tehnologija (IKT-a). Postoji veći broj metodologija za upravljanje projektima. Metodologije za upravljanje projektima imaju različite karakteristike i mogu biti pogodne za upravljanje projektima u različitim organizacijama. Uspješnost primjene određene metodologije za upravljanje projektima ovisi o brojnim karakteristikama. Ne postoji jedna, generalna i najbolja metodologija koju bi bilo poželjno primjenjivati u svim situacijama. Stoga, odlučivanje o najpogodnijoj metodologiji za upravljanje projektima u specifičnim situacijama predstavlja pravi izazov za IKT organizaciju na početku projekta. S druge strane, razvoj općeg modela odlučivanja o najpogodnijoj metodologiji za upravljanje projektima u različitim IKT organizacijama predstavlja i znanstveni izazov.

Rješavanju tog izazova u ovom radu pristupamo s pozicije višekriterijskog odlučivanja te primjene metode analitički hijerarhijski proces (AHP). Jasno je da je odabir najpogodnije metodologije za upravljanje projektima odluka koja zavisi o većem broju kriterija. Kako bi se efikasno modelirali svi ti kriteriji, poželjno je da se koristi višekriterijska metoda koja omogućuje grupiranje kriterija u klastere. Iz tog razloga, za ovaj istraživački rad je izabrana metoda AHP koja je ujedno i najpoznatija i najviše korištena metoda u području višekriterijskog odlučivanja.

Glavni doprinos rada je razvijen opći model odlučivanja o najpogodnijoj metodologiji za upravljanje projektima. Opći model odlučivanja rezultat je procesa strukturiranja koji je prvi korak metode AHP. Strukturiranje se provodi pomoću analize literature kao glavne metode. Pristup koji se koristio u formiranju AHP hijerarhije je odozdo prema gore (engl. bottom-up). Naime, pregledom literature, identificiran je popis kriterija relevantnih za izbor metodologije za upravljanje projektima u IKT sektoru, a potom su identificirani kriteriji grupirani u grupe temeljem sadržajne analize.

Ovaj rad je strukturiran na način da se u poglavlju 2 nalazi prezentacija četiri najpopularnije metodologije za upravljanje projektima koje su opisane kroz analizu relevantne i recentne literature iz područja upravljanja projektima. Potom su u poglavlju 3 kvalitativnom analizom identificirani kriteriji te navedenim pristupom odozdo prema gore (engl. bottom-up) grupiraju u grupe. Kao rezultat prikazano je hijerarhijsko stablo problema odlučivanja te je dana tablica odlučivanja koja opisuje prezentirane metodologije preko identificiranih kriterija. Konačno, u poglavlju 4 demonstrirana je primjena razvijenog općeg problema na pokaznom primjeru.

2. METODOLOGIJE UPRAVLJANJA PROJEKTIMA RAZVOJA PROGRAMSKIH PROIZVODA

Gotovo u svim granama gospodarstva pa tako primjerice i u IKT industriji preferira se projektni način rada. Kako bi se uspješno implementirao ovakav način rada za to su razvijene brojene metodologije koje predstavljaju „primjenu znanja, vještina, alata i tehnika na projektne aktivnosti kako bi se zadovoljili projektni zahtjevi“ (PMI, 2011). Slijedom pregleda relevantne literature autori su se odlučili opisati i usporediti pogodnost korištenja četiriju metodologija koje se spominju kao najzastupljenije u razvoju programskih proizvoda odnosno implementaciji informacijskih sustava. Jedna od njih je tradicionalni pristup koji se temelji na vodopadnom modelu, druge dvije su agilne metodologije Kanban i SCRUM, dok je četvrta nešto manje zastupljenija i korištena od strane voditelja projekata jer spada među novije osmišljene i primjenjivane, a radi se o OpenPM2 metodologiji kreiranoj od strane Europske komisije (Mahalakshmi, Sundararajan, 2013;Andrei i dr., 2019;Saeed i dr. 2019;Jabar i dr., 2019;Thummadi, Lyytinen, 2020;Bhavsar, Shah, Gopalan, 2020).

Agilne metodologije, za razliku od tradicionalnog pristupa pružaju veliku fleksibilnost u upravljanju projektima pri tome omogućuju organizacijama koje ih koriste stalnu prilagodbu novim zahtjevima konkurencije na globalnom tržištu kao i brzu reakciju na želje i potrebe krajnjih korisnika (Thesing, Feldmann, Burchardt, 2021). U nastavku rada daje se opis značajki svake od prethodno navedenih metodologija.

2. 1 Upravljanje projektima vodopadni pristup

Metodologija vođenja projekata vodopadnim pristupom pogodna je za projekte koji su financirani od strane državnih tijela ili različitih agencija koje striktno zahtijevaju točnost i ograničenost u vremenu, financijskim i materijalnim resursima i da je za sve isporuke unaprijed točno definirana dinamika koja se treba poštovati od strane isporučitelja. Iako ovaj pristup ubrajamo u tradicionalne metodologije vođenja projekata on se još uvijek uvelike koristi za specifične projekte kod kojih se najčešće zahtijeva da jedna faza projekta mora biti završena da bi druga mogla započeti (Almeida, 2017;Andrei i dr., 2019). Osnovna karakteristika ovog pristupa je da nema fleksibilnosti u dodjeljivanju zadataka članovima tima te se oni na početku trebaju strogo definirati za cijelo vrijeme trajanja projekta. Velika odstupanja od plana nisu poželjna ni u pogledu vremena kao i svih ostalih resursa, a posebice budžeta projekta koji je strogo definiran, ugovoren i verificiran od strane naručitelja i izvođača prije početka izvođenja projekta (Turner, 2018;Adenowo, 2013). Tipične faze koje se provode kod primjene ove metodologije su: planiranje, analiza, dizajn, oblikovanje, implementacija i testiranje te na kraju integracija i održavanje (Kramer, 2018). Novija inačica vodopadnog modela je djelomično inkrementalni vodopadni model. Novitet ovog pristupa je mogućnost povratka iz već započete faze na prethodnu fazu što omogućava izvršenje ponekih faza i više puta. Prednosti ovog modela ogledaju se u mogućnosti ponovljenog korištenja svih jednom izrađenih artefakata kod izvođenja sličnih projekata, dok je osnovni nedostatak nefleksibilnost s obzirom da se sve mora odvijati prema striktno definiranom planu već na samom početku i ne dozvoljava značajna odstupanja od plana što bi u konačnici rezultiralo i neuspjelom implementacijom i ostvarivanjem svih prethodno definiranih isporuka i krajnjeg rezultata projekta (Despa, 2014).

2. 2 Upravljanje projektima Kanban metodologijom

Kanban je jedna od metodologija koja se ubraja u tzv. agilne metodologije nastala šezdesetih godina dvadesetog stoljeća, a osnovna značajka joj je isporuka „upravo na vrijeme“ (eng. JIT - Just in time). Precizan prikaz posla korištenjem Kanban ploče osnovna je značajka ove metodologije. Ploča se sastoji od stupaca koji predstavljaju faze čiji su nazivi prilagodljivi ovisno o vrsti projekta koji se provodi. Kanban ploča prikazuje trenutno stanje na projektu i status svake aktivnosti koja se mora sprovesti (Ahmad, Markkula, Oivo, 2013;Wakode, Raut, Talmale, 2015). Kanban projektne timove karakterizira velika fleksibilnost u odrađivanju definiranih zadataka jer uloge svakog člana nisu točno određene. Važno je da se svaki predviđeni zadatak zabilježi na Kanban ploči i pravovremeno odradi što je velika prednost kod projekata gdje obujam posla od zadatka do zadatka značajno varira. (Kirovska, Koceski, 2015). Fleksibilnost je prisutna i u vremenu isporuke, s obzirom da nisu točno striktno određene za svaki zadatak ili dio zadatka te se isporuke dostavljaju krajnjem naručitelju kada su one spremne za isporuku bez točno unaprijed definiranih rokova i rasporeda. Fleksibilnost se ogleda između ostalog i kod samog zahtjeva za promjenom rasporeda na Kanban ploči jer se on proizvoljno kako se projekt izvršava može mijenjati uz mogućnost otklanjanja postojećih ili uvođenja novih stupaca (Tanner, Dauane, 2017;Alaidaros, Omar, Romli, 2018a,Alaidaros, Omar, Romli, 2018b). Kao osnovnu prednost Kanban metodologije može se izdvojiti fleksibilnost u provođenju planiranja koja je kontinuirana tijekom čitavog vremena izvršenja projekta što pozitivno utječe na članove projektnog tima kao i na jednostavnost vođenja s obzirom da se zadaci koji su od većeg prioriteta mogu i prvi odrađivati. Time što je omogućena fleksibilnost smanjuje se vjerojatnost nastanka „uskih grla“ što ujedno može pozitivno utjecati na smanjenje kašnjenja ili zaostajanje u kontinuiranim isporukama karakterističnim za sve agilne metodologije pa tako i za Kanban (Riaz, 2019;Durdan, 2021;Alaidaros, Omar, Romli, 2018c).

2. 3 Upravljanje projektima Scrum metodologijom

Agilna metodologija Scrum vođena je pristupom „ispravnog“ razvoja programskih rješenja, a osnovna joj je značajka uzastopno testiranje programskog rješenja i smatra se pogodnom za vođenje projekata koji su većeg i srednjeg obuhvata (Hron, Obwegeser, 2018;Ariza, Mozo, Quintero, 2018). Ova metodologija stavlja naglasak na stalnu i pravovremenu isporuku programskih rješenja što uvelike doprinosi zadovoljstvu klijenata/naručitelja koji su u svakome trenutku razvoja uključeni u sam razvoj te na taj način mogu izraziti sve svoje želje i preferencije (Cardozo i dr., 2010,Sharma, Hasteer, 2016;Ma’arif i dr., 2018;Khalid i dr., 2020). Kontinuirano poboljšanje jedno je od osnovnih načela kojim je vođena Scrum metodologija što podrazumijeva zajedničku suradnju i komunikaciju ljudskih resursa uključenih u izvedbu projekta te da se članovi tima samostalno organiziraju i vrše raspodjelu radnih aktivnosti s obzirom na kompetencije koje posjeduje svaki član projektnog tima ujedno razmjenjujući znanja i iskustva (Cardozo i dr., 2010;Permana, 2015;Sharma, Hasteer, 2016;Ramin, Matthies, Teusner, 2020). U Scrum metodologiji projektne timove grade tri glavna dionika: „razvojni tim“, scrum majstor“ i vlasnik proizvoda kojima se dodjeljuju „uloge i odgovornosti“. Scrum timovi imaju jedan temeljni zadatak, a to je u prethodno definiranom vremenu i s definiranim resursima izvesti isporuke odnosno sprintove tj. programska rješenja po dijelovima, a ne da se jednom isporukom obuhvati gotov krajnji proizvod (Morandini i dr., 2021). Kroz stalne isporuke (sprintove) dobivaju se povratne informacije od krajnjih korisnika/naručitelja koje mogu biti ulaz u narednu fazu ili služe za poboljšanje postojeće isporuke (sprinta). Ovakav način razvoja omogućava da krajnja isporuka programskog rješenja što je moguće više odražava sve želje i preferencije krajnjeg korisnika/naručitelja (Mundra, Misra, Dhawale, 2013).

Jedna od ključnih različitosti u odnosu na ostale metodologije koja je karakteristična za Scrum su tzv. „ceremonije“ koje se odnose na projektne sastanke koji su vrlo učestali, a osnovna im je svrha neometano i krajnje precizno planiranje odvijanja tokova svih definiranih aktivnosti tijekom trajanja projekta, izgradnja i održavanje dobre organizacijske kulture između članova tima i stalna upućenost svih dionika projekta sa trenutnim stanjem projekta. Također je osnovna svrha ovakvih sastanaka zajednička diskusija i kreiranje triju glavnih artefakata, a to su kreiranje „artefakta inkrementa“, „artefakta zaostataka u sprintu“ i „zaostataka u proizvodu“ što ujedno predstavlja i isporuku svakog sprinta. Takve „ceremonije“ odnosno sastanci odvijaju se kako na dnevnoj, tako i na tjednoj odnosno mjesečnoj bazi ovisno o vrsti dionika u svrhu identificiranja zaostataka, organizacije daljnjih sprintova te pregleda i retrospektive ostvarenih sprintova (Morandini i dr., 2021). Prema istraživanju koje su proveliOverhage i Schlauderer (2012) prednosti koje su prepoznate vezane uz korištenje Scrum metodologije ogledaju se u brzini i prilagodbi svake projektne faze (sprinta) za dio programskog rješenja pa sve do krajnje isporuke, velika uključenost i informiranost svih dionika, posebice krajnjih korisnika u svakoj pojedinoj fazi (sprintu) kao i svih članova tima, što u konačnici osigurava maksimalnu fleksibilnost u svim segmentima i aktivnostima. Time što su ključne informacije svake faze projekta svima poznate osigurana je maksimalna transparentnost izvedbe sve do krajnje isporuke finalnog programskog rješenja. S druge strane, istraživanje od straneDespa (2014) prepoznalo je nekoliko mana Scrum metodologije kao što je teško nadomještanje članova projektnog tima ukoliko jedan ili više članova odluči prije završetka projekta napustiti projekt i velika razina iskustva koja se zahtijeva od svih članova tima koji sudjeluju u realizaciji projekta. Unatoč spomenutim nedostacima, istraživanje Hayat i dr., (2019) ukazalo je da većina tvrtki koje se bave razvojem programskih rješenja i koje su projektne aktivnosti izvodile pomoću Scrum metodologije, isporučivale su finalne proizvode u svim dogovorenim rokovima i okviru predviđenih materijalnih i financijskih i ostalih resursa s vrlo velikim uspjehom i kvalitetom kao i zadovoljstvom krajnjih korisnika/naručitelja.

2. 4 Upravljanje projektima OpenPM2 metodologijom

Glavna ideja razvoja OpenPM2 metodologije upravljanja projektima bila je sa ciljem postizanja ujednačenosti upravljanja svim projektima u okviru Europske komisije. Razvoj metodologije započinje 2007. godine i nastavlja se sve do danas s nizom novih inačica te je iz godine u godinu sve više prihvaćena u IKT sektoru (PM2 Alliance, 2019). Značajna je 2018. godina kada je ova metodologija po prvi puta predstavljena javnosti i osnovan PM2 savez s obzirom da je do tada primjena metodologije bila isključivo rezervirana samo za projekte kojima je upravljala Europska komisija. Od te se godine kroz različita događanja i aktivnosti kao što su konferencije, seminari, visokokvalitetna infrastrukturna podrška te usluge kroz najrazličitije vidove savjetovanja značajno promovira OpenPM2 metodologija kao i kroz sustave certificiranja kako bi se njezino korištenje proširilo u što većoj mjeri diljem Europske unije kao i izvan nje. Razlog tome je što je ova metodologija pogodna ne samo za razvoj programskih rješenja i uvođenje informacijskih sustava već općenito za realizaciju projekata većih obuhvata (projekti pozitivno djeluju na društvenu zajednicu stvaranjem dodane vrijednosti za različite ciljane skupine ili društvo u cjelini) iz razloga jer je metodologiju moguće prilagoditi zahtjevima projekta bilo koje domene (PM2 Alliance, 2019;Takagi, Varajão, 2019;Moya-Colorado, Yagüe Blanco, 2019;Obradović, 2018;Moya-Colorado, León-Bolaños, Yagüe-Blanco, 2021).

Način vođenja samog projekta primjenom OpenPM2 metodologije zahtijeva od voditelja kao i svih članova projektnog tima usmjeravanje svih napora u postizanje projektnih ishoda temeljem prethodno definiranih aktivnosti. Zadaci koji se trebaju izvršiti dodjeljuju se članovima projektnog tima na način da se prethodno utvrđuje tko od članova tima ima najviše kompetencija za odrađivanje pojedinog definiranog zadatka/aktivnosti. Pri tome se tijekom cijelog vremena izvršenja projekta daje prioritet onim isporukama koje su najvažnije i kojima se ostvaruje najveća dodana vrijednost, potičući stalni razvoj dobre organizacijske klime i kulture kako bi se postizali maksimalni rezultati. Tijekom svih faza projekta uključuje se sve dionike koji na bilo koji način mogu doprinijeti uspješnoj realizaciji projekta što u konačnici rezultira razmjenom iskustva, znanja i stjecanje novih kompetencija uz primjernu svih etičkih načela među svim dionicima projekta (Matovic, 2020). Primjena OpenPM2 metodologije zahtijeva određene pretpostavke od kojih najvažnija da se mora raditi o projektu, a ne samo o jednoj radnoj operaciji ili nekoj aktivnosti/ zadatku. Druga pretpostavka odnosi se na trajanje koje ne bi smjelo biti manje od mjesec dana te da je u projekt uključeno više od dva dionika/osobe. Jedna od bitnih pretpostavki koju zahtijeva ova metodologija je jasno definiranje upravljačke strukture projekta te točno definirane odgovornosti i uloge svih članova projektnog tima. Također jasno i precizno treba biti definiran proračun kao i domena samog projekta. Opsežna dokumentiranost i pravovremeno izvješćivanje te stalan nadzor osigurava veliku transparentnost rada što podrazumijeva izradu velikog broja artefakata (Kourounakis, Maraslis, 2017;Pantouvakis, 2017).

Prednost OpenPM2 metodologije je velika fleksibilnost primjene za svaku pojedinu vrstu i veličinu projekta, no ipak je neophodno držati se osnovnih koraka metodologije kao i postupaka, smjernica i preporučenih predložaka jer je to dio zaokružene cjeline. Gotovo kao i kod svake druge metodologije tako i kod OpenPM2 metodologije osnove faze su: inicijalna faza kojom se projekt započinje, zatim slijedi faza planiranja, nastavno je faza implementacije i izvršenja projekta te faza konačne isporuke odnosno završna faza. Kroz model upravljanja projektnom za svaku fazu definira se glavni cilj, ključni dionici kao i njihove uloge i odgovornosti te svi uvjeti pod kojima započinje i završava svaka pojedina faza. Kroz sve vrijeme trajanja i izvršenja projektnih aktivnosti provode se stalni nadzori i usporedbe s prethodno definiranim planom projekta kako sami pojedinačni projektni zadaci i aktivnosti tako i svi bitni aspekti vezani uz opseg, kvalitetu, troškove i ostale resurse neophodne za uspješnu realizaciju projekta. Osim modela upravljanja projektom jedno od ključnih temelja OpenPM2 metodologije su i jasno definirani postupci, artefakti kao i temeljito definiran životni ciklus projekta (Kourounakis, Maraslis, 2017;Pantouvakis, 2017).

3. ODLUČIVANJE O METODOLOGIJI UPRAVLJANJA PROJEKTIMA RAZVOJA PROGRAMSKIH PROIZVODA

Odlučivanje o metodologiji upravljanja projektima razvoja programskih proizvoda s perspektive tvrtke koja želi odabrati odgovarajuću metodologiju predstavlja višekriterijski problem odlučivanja. Mnogo je metoda za višekriterijsko odlučivanje koje mogu biti korištene u tom smislu. Neke od njih su jednostavnije za primjenu, a druge su složenije (Kadoić i dr, 2016). U jednostavnije metode možemo ubrojiti: rangiranje alternativa na temelju ocjena članova tima, rangiranje alternativa na temelju rangova članova tima te zbrajanje ponderiranih vrijednosti. S druge strane, u složenije metode odlučivanja možemo ubrojiti metode kao što su TOPSIS (tehnika za određivanje preferencija prema sličnosti s idealnim rješenjem, engl. The Technique for Order of Preference by Similarity to Ideal Solution), Elektra, Prometej, Dex metoda, AHP (analitički hijerarhijski proces, engl. The Analytic Hierarchy Process) ili ANP (analitički mrežni proces, engl. The Analytic Network Process).

Višekriterijska metoda koju je oportuno primijetiti zavisi ponajprije o važnosti problema odlučivanja te o njegovim karakteristikama (Kadoić i dr., 2017). Tako složenije metode ima smisla upotrijebiti dok je problem od strateške ili taktičke važnosti za organizaciju (na i za rješavanje operativnih problema). Najviše korištena metoda višekriterijskog odlučivanja jest AHP koju i možemo smatrati najprigodnijom metodom za odlučivanje o metodologiji upravljanja projektima razvoja programskih proizvoda. U prvom koraku te metode, potrebno je problem strukturirati preko hijerarhijskog stabla i pomoću tablice odlučivanja (Slika 1 iTablica 1).

U ovom poglavlju su prikazani rezultati prvog od četiri koraka primjene te metode, uz pomoć Slike 1 iTablice 1. Cilj tog prikazivanja jest napraviti početni model strukture problema odlučivanja koji po potrebi organizacije mogu dopuniti sukladno drugim njima važnim kriterijima, te potom provesti ostale korake u procesu odlučivanja. Početni, opći model odlučivanja može se koristiti i bez dopune s drugim kriterijima, ukoliko ih organizacija nije prepoznala. Kriteriji koji bi mogli biti važni za odlučivanje, a koji ne ovise o metodologijama, već o organizaciji mogu uključivati, između ostalog, znanje i dosadašnje iskustvo koje organizacija i ljudi koji vode projekt imaju u području primjene neke od metodologija.

Analizom literature identificirano je 16 kriterija usporedbe metodologija za upravljanje projektima. Sadržajnom analizom provedenom od strane autora rada koji su stručnjaci u području upravljanja projektima te stručnjaci u području primjene metode AHP, odozdo prema gore (bottom-up) pristupom ti kriteriji su grupirani u 4 grupe. Prva grupa se odnosi na osnovne karakteristike metodologije, druga se odnosi na projekt, treća grupa se odnosi na projektni tim koji izvršava projekt, a zadnja grupa se odnosi na isporuke projekta.

Slika 1. Hijerarhijski model za odlučivanje o odabiru najpogodnije metodologije za upravljanja projektima u organizaciji X metodom AHP
zbornik-veleri-11-131-g1.png

Izvor: autori

Ako određena organizacija želi dopuniti popis kriterija svojim kriterijima, tada se predlaže dodati petu grupu kriterija (klaster) Organizacija i u toj grupi navesti kriterije koji su u tom smislu relevantni.

U procesu višekriterijskog odlučivanja, u koraku uspoređivanja u parovima, praktično može biti korisna i tablica odlučivanja (Tablica 1). Radi se o sažetom pregledu vrijednosti alternativa (metodologija za upravljanje projektima) prema identificiranim kriterijima najniže razine.

Tablica 1. Usporedba metodologija za upravljanje projektima
ScrumKanbanVodopadnaOpenPM2
MetodologijaPogodnost metodologije za projekt Metodologija pogodna za sve vrste projekata (visoka), srednjeg i velikog opsega.Metodologija pogodna za sve vrste projekata (visoka) pri čemu nije nužna visoka razina upravljanja projektom.Metodologija pogodna za projekte koji ne zahtijevaju kontinuiranu isporuku.Metodologija pogodna za sve vrste projekata (visoka), srednjeg i velikog opsega.
SloženostSrednjaNiskaNiskaSrednja
VizualizacijaVisoka razina vizualizacije aktivnostiVisoka razina vizualizacije aktivnostNiska razina vizualizacije aktivnostiVisoka razina vizualizacije aktivnosti
Upravljanje metodologijomPotrebno visoko upravljanjePotrebna niska razina upravljanja Potrebno niska razina upravljanjaPotrebno visoko upravljanje
DokumentacijaJednostavna dokumentacijaJednostavna dokumentacijaJednostavna dokumentacijaSložena i opširna dokumentacija
ProjektMijenjanje prioriteta zadataka MogućeMogućeNije mogućeMoguće
Kopiranje načina vođenja projekta s drugog projekta iste metodologijeMoguće sve dok su sprint backlog i product backlog na projektima približno isti (djelomična mogućnost kopiranja načina vođenja).Moguće u potpunosti kopiranje načina vođenja projekta s drugog projekta obzirom na jednostavnost metodologije (visoka mogućnost kopiranja načina vođenja).Moguće ako je finalni proizvod/usluga koji se isporučuje kupcu sličnih osobina, te ako kupac ima približno ista očekivanja os finalnog proizvoda/ usluge (djelomična mogućnost kopiranja načina vođenja).Moguće ako su najbolje prakse iz prijašnjih projekata primjenjive na projekt (visoka mogućnost kopiranja načina vođenja).
Utjecaj dodatnih zahtjeva na realizaciju projektaNizakNizakVisokNizak
TimDefiniranost sastava timaStriktno definirane ulogeUloge nisu striktno definiraneUloge nisu striktno definiraneStriktno definirane uloge
Učestalost sastajanjaVisokaNiskaNiskaSrednja
Sudjelovanje kupacaMetodologija „propisuje“ kontinuiranu isporuku pri čemu kupac na kraju svake isporuke može definirati dodatne zahtjeve, te mijenjati prioritete isporuke (visoka uključenost kupaca).Kupac tijekom životnog ciklusa projekta može sudjelovati u definiranju prioriteta projekta kao i definirati dodatne zahtjeve (srednja uključenost kupaca).Metodologija omogućuje kupcima sudjelovanje u fazi definiranja zahtjeva koje je potrebno realizirati projektom (srednja uključenost kupaca).Metodologija definira sudjelovanje kupaca u svim fazama životnog ciklusa projekta (visoka uključenost kupca).
Utjecaj odlaska člana tima na uspjeh projektaVisokSrednjiVisokSrednji
Broj članova timaNajpogodnija za timove do 10 članovaPogodna za timove svih veličinaPogodna za timove svih veličinaPogodna za timove svih veličina
IsporukaBrzinaVisokaVisokaNiskaSrednja
KontinuiranostMoguća kontinuirana isporuka završenih sprintovaMoguća kontinuirana isporuka završenih zadatakaSekvencijalna isporukaSekvencijalna isporuka
Osiguranje kvaliteteKvalitetna isporuka osigurava se pomoću SCRUM događaja.Nema.Kvalitetna isporuka osigurava se činjenicom kako se korisniku isporučuje isključivo testiran, cjelovit programski proizvod.Kvalitetna isporuka osigurava se pomoću praćenja i nadzora koje se provodi u svim fazama životnog ciklusa projekta.

Izvor: autori

4. DEMONSTRACIJA PRIMJENE OPĆEG MODELA ODLUČIVANJA O NAJPOGODNIJOJ METODOLOGIJI ZA UPRAVLJANJE PROJEKTIMA

Nakon što je napravljen prvi korak u metodi AHP, slijedi primjena ostalih koraka metode AHP:

usporedba kriterija prve razine (klastera) u parovima s obzirom na cilj kako bismo odredili težine kriterija (w1, … w4)

• usporedba potkriterija druge razine (kriterija) u parovima s obzirom na nadređene kriterije kako bismo odredili težine potkriterija (w11, … w43),

• usporedba alternativa s obzirom na one (pot)kriterije u modelu koji nisu dekomponirani na kriterije niže razine kako bismo odredili lokalne prioritete alternativa,

• izračun ukupnih prioriteta alternativa,

• provođenje analize osjetljivosti.

Tablica 2 prikazuje predložak tablice prioriteta koji je potrebno popuniti u procesu primjene metode AHP.

Tablica 2. Usporedba metodologija za upravljanje projektima
ScrumKanbanVodopadnaOpenPM2
MetodologijaW1Pogodnost metodologije za projekt W11
SloženostW12
VizualizacijaW13
Upravljanje metodologijomW14
DokumentacijaW21
ProjektW2Mijenjanje prioriteta zadataka W22
Kopiranje načina vođenja projekta s drugog projekta iste metodologijeW23
Utjecaj dodatnih zahtjeva na realizaciju projektaW24
TimW3Definiranost sastava timaW31
Učestalost sastajanjaW32
Sudjelovanje kupacaW33
Utjecaj odlaska člana tima na uspjeh projektaW34
Broj članova timaW35
IsporukaW4BrzinaW41
KontinuiranostW42
Osiguranje kvaliteteW43
Ukupni prioriteti alternativa

Da bi se izračunale težine kriterija i potkriterija te lokalni prioriteti alternativa koristi se metoda uspoređivanja u parovima korištenjem Saatyjeve skale relativnih važnosti. Pri tome je potrebno paziti na konzistentnost uspoređivanja. Za detaljno objašnjenje tog postupka, mogu se konzultirati radovi autora metode AHP Thomasa Saatya, ili npr. rad (Kadoić, 2018.) za opis metode AHP na hrvatskom jeziku.

4. 1 Uspoređivanje u parovima

Da bi se odredile težine kriterija, potrebno je usporediti kriterije s obzirom na cilj korištenjem Saatyjeve skale. Saatyjeva skala sastoji se od 9 stupnjeva i koristi se za opisivanje odnosa između dva elementa koja se uspoređuju. Druge skale, npr. Likertova skala, skala školskih ocjena, Richterova skala (…), uglavnom mjere razinu svojstva jednog elementa. Saatyjeva skala u jednom trenutku promatra dva elementa.

• Broj 1 na Saatyjevoj skali koristi se onda kada su dva elementa međusobno jednaka u odnosu na promatrano svojstvo. Npr. ako dva učenika imaju istu ocjenu, ili ako su dva potresa jednako jaka, tada bismo koristili broj 1 za opisivanje odnosa među dva učenika ili dva potresa. S druge strane, kod Saatyjeve skale nemamo informaciju o apsolutnim vrijednostima svojstava elemenata, tj. ne znamo koju ocjenu imaju dva učenika čiji se odnos opisuje brojem 1, ili pak koliko su bili jaki ti potresi. Samo znamo da su ocjene jednake (možda obje ocjene 2, a možda i 5), odnosno da su potresi bili jednako jaki (možda oba slaba (1.5 po Richteru), a možda oba jaka (npr. 6 po Richteru)).

• Brojevi veći od 1, a manji ili jednaki 9 (svi realni brojevi u tom intervalu) se koriste onda kada dva elementa po promatranom svojstvu nisu jednaka, već jedan dominira nad drugim (jedan učenika ima višu ocjenu od drugog; jedan potres je jači od drugog). Ovisno o tome koliko je ta dominacija velika, odnosno, kolika je razlika u apsolutnim vrijednostima elemenata po promatranom svojstvu, koristit ćemo veći ili manji broj na intervalu skale (1;9]. Ako jedan učenik ima ocjenu 3, a drugi 4, tada možemo reći da drugi učenik dominira nad prvim intenzitetom na Saatyjevoj skali, npr. 3 (ovisno o konkretnom slučaju i donositelju odluka, različite osobe mogu iste elemente procijeniti različitim vrijednostima sa Saatyjeve skale). Ipak, na umu treba imati originalne definicije vrijednosti pojedinih stupnjeva sa Saatyjeve skale (3 je umjerena dominacija, 5 je jaka dominacija, 7 je vrlo jaka ili dokazana dominacija i 9 je ekstremna ili apsolutna dominacija).

• Koriste se i recipročne vrijednosti intervala (1:9] kada se želi opisati situacija da je neka alternativa dominirana od druge. Učenik koji ima ocjenu 3 s 1/3 dominira nad učenikom koji ima ocjenu 4.

Uspoređivanje kriterija u odnosu na cilj te izračun težina kriterija provodi se u nekoliko koraka:

1. Prvo se kreira kvadratna matrica koja odgovara broju elemenata koji se uspoređuju s obzirom na cilj. U našem slučaju to su 4 elementa, tj. 4 glavna kriterija u našem modelu evaluacije metodologija za upravljanje projektima. Matrica usporedbi popunit će se s vrijednostima sa Saatyjeve skale.

2. Na glavnu dijagonalu te matrice stavljaju se vrijednosti 1 jer se tu neki element uspoređuje sam sa sobom (što je jednako). Ostale vrijednosti se popunjavaju tako da donositelj odluka daje procjenu važnosti svakog para kriterija.

3. Po dvije pozicije u matrici usporedbi govore o odnosu važnosti svaka dva kriterija. Npr. uTablici 3. u dvostruko uokvirenim ćelijama nalaze se usporedbe važnosti kriterija Tim i Isporuka. Između te dvije pozicije, donositelj odluke stavlja vrijednost iz intervala [1;9] u redak onog kriterija koji je važniji, a na preostalu poziciju će staviti pripadnu recipročnu vrijednost. Npr. ako je kriterij Isporuka važniji od kriterija Tim, i to 2 puta na Saatyjevoj skali, tada će broj 2 biti upisan u gornju dvostruko uokvirenu ćeliju, a 1/2 u donju.

Tablica 3. Matrica usporedbi
IsporukaTimProjektMetodologija
Isporuka1233
Tim1/2122
Projekt1/31/211
Metodologija1/31/211

4. Proces iz prethodnog koraka koristi se za popunjavanje svih ostalih pozicija u tablici. Također, potrebno je paziti na tranzitivnost u uspoređivanju. Npr. ako je donositelj odluke ocijenio da je Isporuka važnija od kriterija Tim, potom da je Tim važniji od kriterija Projekt, tada mora slijediti i da je Isporuka važnija od kriterija Projekt. Uz to potrebno je uvažiti i Saatyjevu skalu pa zaključiti da bi Isporuka trebala biti 4 puta važnija od kriterija Projekt. Dodatno, mala nekonzistentnost u uvažavanju tranzitivnosti na Saatyjevoj skali je dozvoljena. To znači da bi i umjesto 4 (važnost kriterija Isporuka u odnosu na kriterij Projekt) bilo prihvatljivo napisati i 3, ili 5. Postoji procedura kojom se može provjeriti da li je neka tablica usporedbi dovoljno uvažila tranzitivnost na Saatyjevoj skali. Ta procedura uključuje izračun omjera nekonzistencije koji mora biti manji od 0,1 da bi se neka matrica usporedbi smatrala konzistentnom.

5. Dok je matrica usporedbi popunjena, zbroje se stupci te matrice.

6. Potom se kreira nova kvadratna matrica koja se popunjava tako da se podijeli svaka vrijednost izTablice 3. s pripadnim zbrojem stupca.

7. Konačno, reci novodobivene matrice se uprosječe i tako se dobiju težine kriterija.

Tablica 4. Izračun težina kriterija iz matrice usporedbi
ITPMITPMWi
I1233I0,4620,5000,4290,4290,455
T0,50122T0,2310,2500,2860,2860,263
P0,330,5011P0,1540,1250,1430,1430,141
M0,330,5011M0,1540,1250,1430,1430,141
2,1674,0007,0007,000

Ukoliko bi u procjenjivanju sudjelovalo više sudionika, svaki od njih bi trebao izraditi svoju tablicu usporedbi. Potom bi se kreirala grupna tablica usporedbi čije bi vrijednosti bile jednake geometrijskim sredinama istih pozicija individualnih tablica usporedbi. Nakon toga bi se primijenili koraci 5-7 iz prethodno opisane procedure i dobile grupne težine kriterija.

Na potpuno jednaki način se dobiju i težine potkriterija te lokalni prioriteti alternativa, tj. u nastavku je potrebno još napraviti sljedeće tablice usporedbi i izračune:

• Matrica usporedbi potkriterija iz kriterija Isporuka u odnosu na taj kriterij (takva matrica će imati 5 redaka i 5 stupaca pošto je toliko potkriterija unutar kriterija)

• Matrica usporedbi potkriterija iz kriterija Tim u odnosu na taj kriterij (takva matrica će imati 3 retka i 3 stupca pošto je toliko potkriterija unutar kriterija)

• Matrica usporedbi potkriterija iz kriterija Projekt u odnosu na taj kriterij (takva matrica će imati 5 redaka i 5 stupaca pošto je toliko potkriterija unutar kriterija)

• Matrica usporedbi potkriterija iz kriterija Metodologija u odnosu na taj kriterij (takva matrica će imati 3 retka i 3 stupca pošto je toliko potkriterija unutar kriterija)

• Sveukupno 16 matrica usporedbi alternativa u odnosu na svaki od potkriterija, uvažavajući stvarne vrijednosti alternativa koje su vidljive uTablici 1.

4. 2 Izračun ukupnih prioriteta

UTablici 5 nalaze se težine kriterija i lokalni prioriteti alternativa dobiveni prethodno opisanim postupkom za organizaciju X. Pred tom organizacijom je projekt Y kojeg karakteriziraju sljedeće karakteristike:

• Projekt Y je projekt velikog opsega, te je stoga poželjna visoka razina vizualizacije provedbe aktivnosti na projektu.

• Klijent je javno tijelo te je stoga potrebno izraditi detaljnu i složenu dokumentaciju, razumljivu običnim građanima.

• Organizacija X je već prije radila tako složen projekt i koristila OpenPM2 metodologiju pri čemu su neki obrasci u provedbi projekta primjenjivi i u ovom projektu.

• S obzirom da projekt dolazi iz javnog sektora kojeg karakterizira visoko rizično političko okruženje, moguće je očekivati dodatne zahtjeve od klijenta.

• Projekt će provoditi uigran tim čiji članovi su imali stalne uloge na prijašnjim projektima.

• Članovi tima rade u istoj organizaciji i mogu se sastajati često.

• Nužno je sudjelovanje kupaca u svim fazama provedbe metodologije.

• Radi povjerljivosti podataka, bilo bi dobro da članovi tima ostaju fiksno raditi tokom cijele provedbe projekta.

• Rezultate projekta potrebno je isporučivati kontinuirano (sekvencijalno), zbog vanjske kontrole.

• Rezultati trebaju biti na visokoj razini kvalitete.

Navedene karakteristike bit će vrlo korisne u fazi evaluacija metodologija jer će po različitim kriterijima dati prednost možebitno različitim alternativama (metodologijama) s obzirom na njihove karakteristike koje su navedene ranije. Prilikom usporedbi alternativa u parovima s obzirom na potkriterije, koriste se vrijednosti iz tablice odlučivanja (Tablica 1), pri čemu evaluaciju treba izvršavati s obzirom na navedene karakteristike projekta Y i organizacije X.

Težine kriterija, težine potkriterija i lokalni prioriteti alternativa se međusobno množe i zbrojevi umnožaka čine ukupne prioritete alternativa. Metodologija koja ostvaruje najveći prioritet je najpogodnija metodologija za upravljanje projektima. Prema rezultatima, za prethodno opisani projekt Y najpogodnija metodologija je OpenPM2.

Tablica 5. Usporedba metodologija za upravljanje projektima
ScrumKanbanVodopadnaOpenPM2
Metodologija0,455Pogodnost metodologije za projekt 0,250,30,30,10,3
Složenost0,20,20,30,30,2
Vizualizacija0,20,30,30,10,3
Upravljanje metodologijom0,20,30,20,20,3
Dokumentacija0,150,10,10,10,7
Projekt0,263Mijenjanje prioriteta zadataka 0,30,30,30,10,3
Kopiranje načina vođenja projekta s drugog projekta iste metodologije0,40,250,250,250,25
Utjecaj dodatnih zahtjeva na realizaciju projekta0,30,30,30,10,3
Tim0,141Definiranost sastava tima0,20,40,10,10,4
Učestalost sastajanja0,20,550,10,10,25
Sudjelovanje kupaca0,20,30,20,20,3
Utjecaj odlaska člana tima na uspjeh projekta0,20,40,10,40,1
Broj članova tima0,20,10,30,30,3
Isporuka0,141Brzina0,40,350,350,10,2
Kontinuiranost0,20,250,250,250,25
Osiguranje kvalitete0,40,20,050,30,45
Ukupni prioriteti alternativa0,274810,239560,175510,31012

4. 3 Analiza osjetljivosti

U zadnjem koraku provodi se analiza osjetljivosti kojom provjeravamo stabilnost dobivenih rezultata. Dobra praksa u analizi osjetljivosti jest oduzimanje i dodavanje 5 postotnih točaka nekoj težini kriterija na prvoj razini (uz istovremeno dodavanje i oduzimanje 5 postotnih točaka ukupno ostalim težinama kriterija na prvoj razini, u omjerima njihovih stvarnih težina). U našem slučaju, to znači da bismo imali ukupno osam analiza osjetljivosti. U svakoj od tih osam analiza osjetljivosti zračunavamo ukupne prioritete (bez promjene težina potkriterija i lokalnih prioriteta alternativa). Ukoliko sve (ili barem većina) analiza osjetljivosti rezultira time da najveći ukupni prioritet ima metodologija za upravljanje projektima koja je imala najveći ukupni prioritet prije provođenja analize osjetljivosti, tada tu metodologiju možemo potvrditi kao konačnu odluku. U protivnom, potrebno je napraviti dodatne analize. U našem slučaju imat ćemo 8 analiza osjetljivosti. Zbirna tablica pokazana je uTablici 6.

Tablica 6. Zbirna analiza osjetljivosti (poretci alternativa)
ScrumKanbanVodopadnaOpenPM2
Prije analize osjetljivosti2341
Metodologija –5 %2341
Metodologija +5 %2341
Projekt –5 %2341
Projekt +5 %2341
Tim –5 %2341
Tim +5 %2341
Isporuka –5 %2341
Isporuka +5 %2341

Prema analizi izTablice 6, poredak alternativa nije se mijenjao, tj. OpenPM2 je u svim analizama ostala metodologija s najvećim prioritetom za navedeni kontekst. Dok je to slučaj (da se poredak alternativa nije mijenjao), može se potvrditi OpenPM2 kao konačna odluka. Ukoliko analiza osjetljivosti pokaže značajne promjene prvorangirane alternative, nećemo potvrditi odluku, već ćemo morati dodatnim analizama zaključiti koju alternativu, između onih koje se po analizama osjetljivosti, pojavljuju na prvom mjestu.

5. ZAKLJUČAK

U ovom radu naglasak je na višekriterijskoj analizi metodologija za upravljanje projektima kako bi se identificirali kriteriji za usporedbu metodologija. Kriteriji koji su identificirani u analizi literature, grupirani su u klastere pristupom odozdo prema gore (bottom-up). Na taj način kreiran je opći hijerarhijski model odlučivanja o najpogodnijoj metodologiji za upravljanje projektima u IKT organizaciji. Taj model može biti prema potrebi dopunjen dodatnim kriterijima, specifičnim za određenu organizaciju. Opći model pogodan je za primjenu metode AHP te je u radu prezentirana demonstracija primjene metode AHP u tom kontekstu.

Dodatno, opći hijerarhijski model pogodan je za primjenu i drugih hijerarhijskih modela, među kojima je i metoda DEX. Uz odgovarajuće modifikacije, model je primjenjiv i za druge metode višekriterijskog odlučivanja.

Primjenom ovog pristupa IKT organizacija može donijeti odluku o izboru metodologije za upravljanje projektima. Važno je da organizacija izabere najpogodniju metodologiju kako bi metodologija bila u službi efikasnog planiranja i provedbe projekta, a ne usko grlo u tom procesu.

References

 

Adenowo A. A.; Adenowo B. A. (2013). Software Engineering Methodologies: A Review of the Waterfall Model and Object-Oriented Approach. International Journal of Scientific & Engineering Research, 4(7), 427-434.

 

Ahmad M. O.; Markkula J.; Oivo M. (2013, September). Kanban in software development: A systematic literature review. In 2013 39th Euromicro conference on software engineering and advanced applications, (pp. 9-16). IEEE.

 

Alaidaros H.; Omar M.; Romli R. (2018a). Towards an improved software project monitoring task model of Agile Kanban method. International Journal of Supply Chain Management (IJSCM), 7(3), 118-125.

 

Alaidaros H.; Omar M.; Romli R. (2018b). A theoretical framework for improving software project monitoring task of Agile Kanban method. In International Conference of Reliable Information and Communication Technology (pp. 1091-1099). Springer, Cham.

 

Alaidaros H.; Omar M.; Romli R. (2018c). Identification of criteria affecting software project monitoring task of Agile Kanban method. In AIP Conference Proceedings, (Vol. 2016, No. 1, p. 020021). AIP Publishing LLC.

 

Almeida F. (2017). Challenges in migration from waterfall to agile environments. World Journal of Computer Application and Technology, 5(3), 39-49.

 

Andrei B. A.; Casu-Pop A. C.; Gheorghe S. C.; Boiangiu C. A. (2019). A study on using waterfall and agile methods in software project management. Journal Of Information Systems & Operations Management, 125-135.

 

Ariza H. M.; Mozo V. R.; Quintero H. M. (2018). Methodology for the Agile development of software based on a guide for the body of knowledge of scrum (SBOKTM Guide). International journal of applied engineering research, 13(14), 11479-11483.

 

Bhavsar K.; Shah V.; Gopalan S. (2020). Scrumbanfall: an agile integration of scrum and kanban with waterfall in software engineering. International Journal of Innovative Technology and Exploring Engineering (IJITEE), 9(4), 2075-2084.

 

Cardozo E. S.; Araújo Neto J. B. F.; Barza A.; França A. C. C.; da Silva F. Q. (2010, April). SCRUM and productivity in software projects: a systematic literature review. In 14th International Conference on Evaluation and Assessment in Software Engineering (EASE), (pp. 1-4).

 

Despa M. L. (2014). Comparative study on software development methodologies. Database Systems Journal, 5(3), 37-56.

 

Durdan L. (2021), 4 Common Mistakes Made While Beginning with Kanban, (siječanj 2021), [Na internetu], Dostupno:https://djaa.com/4-mistakes-while-beginning-with-kanban/. [pristupano: 11. 5. 2021. ]

 

Hron M.; Obwegeser N. (2018, January). Scrum in practice: an overview of Scrum adaptations. In Proceedings of the 51st Hawaii International Conference on System Sciences.

 

Jabar M. A.; Abdullah S.; Jusoh Y. Y.; Mohanarajah S.; Ali N. M. (2019, December). Adaptive and dynamic characteristics in hybrid agile management model for software development project success. In 2019 6th International Conference on Research and Innovation in Information Systems (ICRIIS), (pp. 1-5). IEEE.

 

Kadoić N. (2018). Nova metoda za analizu složenih problema odlučivanja temeljena na analitičkom mrežnom procesu i analizi društvenih mreža, Doktorski rad

 

Kadoić N.; Begičević Ređep N.; Divjak B. (2016). E-learning decision making: methods and methodologies. Re-Imagining Learning Scenarios, CONFERENCE(June), 24.

 

Kadoić N.; Begičević Ređep N.; Divjak B. (2017). Structuring e-Learning Multi-Criteria Decision Making Problems. In P. Billjanović (Ed.), Proceedings of 40th Jubilee International Convention, MIPRO 2017 (pp. 811-817) Croatian Society for Information and Communication Technology, Electronics and Microelectronics - MIPRO.https://doi.org/10.23919/MIPRO.2017.7973514

 

Khalid A.; Butt S. A.; Jamal T.; Gochhait S. (2020). Agile scrum issues at large-scale distributed projects: scrum project development at large. International Journal of Software Innovation (IJSI), 8(2), 85-94.

 

Kirovska N.; Koceski S. (2015). Usage of Kanban methodology at software development teams. Journal of applied economics and business, 3(3), 25-34.

 

Kramer M. (2018). Best practices in systems development lifecycle: An analysis based on the waterfall model. Review of Business & Finance Studies, 9(1), 77-84.

 

Ma’arif D.; Yusnorizam M.; Hafifi Yusof M. F.; Mohd Satar N. S. (2018). The Challenges of Implementing Agile Scrum in Information System’s Project. Jour of Adv Research in Dynamical & Control Systems, 10.

 

Mahalakshmi M.; Sundararajan M. (2013). Traditional SDLC vs scrum methodology–a comparative study. International Journal of Emerging Technology and Advanced Engineering, 3(6), 192-196.

 

Matovic I. M. (2020). Combining Agile and Traditional Project Management as a Better Approach to Project Implementation. RAIS, 1.

 

Morandini M.; Coleti T. A.; Oliveira Jr E.; Corrêa P. L. P. (2021). Considerations about the efficiency and sufficiency of the utilization of the Scrum methodology: A survey for analyzing results for development teams. Computer Science Review, 39, 100314.

 

Moya-Colorado A.; Yagüe Blanco J. L. (2019, July). Exploring the adequacy of OpenPM2 to European Union–funded international development grant projects implemented by Civil Society Organizations. In Proceedings of the 23rd International Congress on Project Management and Engineering, Málaga, Spain (pp. 10-12).

 

Moya-Colorado A.; León-Bolaños N.; Yagüe-Blanco J. L. (2021). The Role of Donor Agencies in Promoting Standardized Project Management in the Spanish Development Non-Government Organizations. Sustainability, 13(3), 1490.

 

Mundra A.; Misra S.; Dhawale C. A. (2013, June). Practical scrum-scrum team: Way to produce successful and quality software. In 2013 13th International Conference on Computational Science and Its Applications, (pp. 119-123). IEEE.

 

N.Kourounakis A.; Maraslis A. Pregled metodologije za upravljanje projektima PM2, srpanj 2017., [Na internetu], Dostupno:https://webgate.ec.europa.eu/fpfis/wikis/display/OpenPM²/Croatian?preview=/319960211/338608723/PM%C2%B2-Overview.HR.pdf. [ 5. 4. 2021. ]

 

Obradović V. (2018). Contemporary trends in the public sector project management. European Project Management Journal, 8(2), 52-56.

 

Overhage S.; Schlauderer S. (2012, January). Investigating the long-term acceptance of agile methodologies: An empirical study of developer perceptions in scrum projects. In 2012 45th Hawaii International Conference on System Sciences, (pp. 5452-5461). IEEE.

 

Pantouvakis J. P. (2017, September). How can IPMA contribute to new PM2 EU commission standard?. In 2017 12th International Scientific and Technical Conference on Computer Sciences and Information Technologies (CSIT), (Vol. 2, pp. 246-251). IEEEQ.

 

Permana P. A. G. (2015). Scrum method implementation in a software development project management. International Journal of Advanced Computer Science and Applications, 6(9), 198-204.

 

PMI: Project Management Institute, VODIČ kroz znanje o upravljanju projektima : (vodič kroz PMBOK), Zagreb:Mate, 2011

 

PM2 Alliance (travanj 2019.), History of PM [Na internetu]. Dostupno:https://www.pm2alliance.eu/history-of-pm2/. [pristupano 14. 3. 2021. ].

 

Ramin F.; Matthies C.; Teusner R. (2020, June). More than code: Contributions in scrum software engineering teams. In Proceedings of the IEEE/ACM 42nd International Conference on Software Engineering Workshops, (pp. 137-140).

 

Riaz M. N. (2019). Implementation of Kanban techniques in software development process: An empirical study based on benefits and challenges. Sukkur IBA Journal of Computing and Mathematical Sciences, 3(2), 25-36.

 

Saeed S.; Jhanjhi N. Z.; Naqvi M.; Humayun M. (2019). Analysis of Software Development Methodologies. International Journal of Computing and Digital Systems, 8(5), 446-460.

 

Sharma S.; Hasteer N. (2016, April). A comprehensive study on the state of Scrum development. In 2016 International Conference on Computing, Communication and Automation (ICCCA), (pp. 867-872). IEEE.

 

Takagi N.; Varajão J. (2019). Integration of success management into project management guides and methodologies-position paper. Procedia Computer Science, 164, 366-372.

 

Tanner M.; Dauane M. (2017). THE USE OF KANBAN TO ALLEVIATE COLLABORATION AND COMMUNICATION CHALLENGES OF GLOBAL SOFTWARE DEVELOPMENT. Issues in Informing Science & Information Technology, 14.

 

Thesing T.; Feldmann C.; Burchardt M. (2021). Agile versus Waterfall Project Management: Decision Model for Selecting the Appropriate Approach to a Project. Procedia Computer Science, 181, 746-756.

 

Thummadi B. V.; Lyytinen K. (2020). How much method-in-use matters? A case study of agile and waterfall software projects and their design routine variation. Journal of the Association for Information Systems, 21(4), 7.

 

Turner R. (2018). Software System Methodology. In In Computational Artifacts (pp. 117-120). Springer, Berlin, Heidelberg.

 

Wakode R. B.; Raut L. P.; Talmale P. (2015). Overview of Kanban methodology and its implementation. IJSRD-International Journal for Scientific Research & Development, 3(02), 2321-0613.


This display is generated from NISO JATS XML with jats-html.xsl. The XSLT engine is libxslt.

accessibility

closePristupačnostrefresh

Ako želite spremiti trajne postavke, kliknite Spremi, ako ne - vaše će se postavke poništiti kad zatvorite preglednik.