Osp Iiparc All

PREDAVANJA 6 Timski rad i emocionalna inteligencija
UVOD
• Tri ključne stvari za softverski projekat su ljudi, procesi i tehnologija.

• Ljudi su najvažniji dio projekta i potrebno je imati odgovarajući broj ljudi sa odgovarajućim
vještinama koji su motivisani da urade posao najbolje što mogu.
• Najveći dio budžeta od projekta uglavnom ide na plate njihovih članova
• Softvetski projekti zahtijevaju dobro koordinaran timski rad
o Potrebne su različite vještine koje rijetko posjeduje jedna osoba
o Vrijeme izvršenja: npr. 10 inženjer-godina
o Sinergija
• Problem: neki izvanredni softver inženjeri nisu zainteresirani ili nisu psihološki pogodni da budu
članovi tima.
• Ljudi različito reaguju na istu situaciju.
• Ljudi iz različitih sredina različito posmatraju stvari.
• U poslu je česta situacija da su pojedinci izloženi velikom pritisku:
o neizvjesnost i nesigurnost. Njihova reakcija zavisi od mnogih faktora.
• Što više poznajemo ljudsku prirodu to bolje komuniciramo s ljudima.
• Emocionalna inteligencija predstavlja sklop više sposobnosti - sposobnost prepoznavanja,
razumijevanja kontrole vlastitih, vlastitih,ali i tuđih emocija.
• Emocionalna inteligencija se dijelom stiče genetskim nasljeđivanjem, ali značajnim dijelom i
procesom učenja.
• Prema Golemanu (1995. g.), model emocionalne inteligencije sastoji se od nekoliko bitnih
komponenti:
o Samosvijest – sposobnost „čitanja“ vlasititih emocija i shvaćanje kakav utjecaj imaju na

okolinu
o Osobno donešenje odluka – proučavanje vlastitih postupaka i poznavanje posljedica
o Upravljanje osjećajima – spoznabanje što je podloga osjećaja
o Prevladavanje stresa – naučiti opuštati se i razumjeti važnost opuštanja
o Empatija – razumijevanje tuđih osjećaja i uvažavanje različitosti mišljenja
o Komunikacija- razgovarati o osjaćajima i razumijevanjem biti dobar slušatelj
o Smootkrivanje – razumijevanje potreba za otvorenošću i povrjenjem, načuti ikada i kako
govoriti o svojim osjećajima
o Pronicljivost – prepoznavanje obrazaca u osobnom i životu drugih ljudi
o Samoprihvaćanje – umjeti prihvatiti svoje mane, umjeti cijeniti svoje vrline
o Osobna odgovornost – preuzeti odgovornosti i umjeti prepoznati posljedice osobnih
reagiranja
o Samopouzdanje – umjeti izložiti svoje brige i osjećaje bez ljutnje i pasivnosti
o Grupna dinamika – spoznati kada pratiti, a kada voditi
o Rješenje sukoba – model „pobijediti / osvojiti“ pri pregovaračkom kompromisu
MENADŽERSTVO VS VOĐENJE
• Projektni menadžer – menedžira projekat i vodi osoblje na projektu

• Menadžerstvo je pravljenje planova i estimacija, prikljupljanje i analiza podataka vezanih za
projekat i produkt, izvještavanje o progresu, kontroliranje razvojnog procesa i produkta te
identifikacija i ublažavanje faktora rizika.
• Vođenje se bavi komunikacijom sa osobljem koje radi na projektu i ostalim učesnicima,
koordinacijom radnih aktivnosti i održavanjem morala.
• Dobri menadžeri ne moraju biti dobre vođe (lideri) i obrnuto. Menadžerstvo traži analitičke
aktivnosti, a vođenje uključuje ljudske odnose.
• Saznajte iz čega niste dobri i nemojte to raditi.
• Ne morate sve raditi sami, zato postoje timovi. Ako nešto ne znate ili postoje neko ko će to brže
i/ili bolje uraditi tražite pomoć.
• Osobine vođe
o Pažljivo sluša
o Delegira autoritet
o Olakšava timski rad
o Koordinira radne aktivnosti
o Olakšava komunikaciju
o Priča svakodnevno sa pojedincima
o Kaže „hvala“ kada je zasluženo
o Podučava i trenira
o Održava entuzijazam
o Pomiruje razlike
o Rješava konflikte
o Uključuje nove članove
o Pomaže zaposlenicima pri razvoju planova za karijeru i postizanju profesionalnih ciljeva
o Preraspodjeljuje radnike ako je potrebno
• Menadžer je zadužen da dostavi prihvatljiv produkt na vrijeme i unutar budžeta (filmski
producent – odgovoran za cijeli projekat).
• Lider za tehnički dio projekta je zadužen za vođenje projektnog tima u smjeru koji će rezultovati
prihvaljivim produktom i zadovoljiiti vremenske i financijske uslove (filmski direktor – odgovoran
za sadržaj produkta).
• Menadžer i lider mogu biti jedna osoba kod manjih projekata (ako osoba ima potrebne osobine
ili je u stanju da ih razvije). Ako se radi o različitim osoba, uspješnog projekta zavisi od njihovog
slaganja.
TIMOVI I TIMSKI RAD
• Tim je grupa pojedinaca koji međusobno sarađuju u koordiniranom okruženju kako bi postigli
zajednički cilj.
• Primarni zadatak lidera je da u sklopu projekta održava afmosferu pogodnu za timski rad.
• Svaki član mora podrediti neke svoje lične ciljeve zajedničkim ciljevima tima. Najbolja opcija je
kada su ciljevi pojedinca ujedno i ciljevi tima.
• Kazne i ukori su za tim (ili dijelove tima), a ne za pojedince.
• Spajanje pojedinaca u kohezivan (povezan) tim rijetko se desi spontano.
• Faktori koji doprinose kreiranju efikasnog i efektivnog tima za softver inženjering
o Odgovarajući broj ljudi
o Korektna mješavina vještina
o Dobri alati
o Odgovarajući trening
o Uzajamno poštovanje
o Poštovanje menadžera i lidera
o Želja da se bude član tima
o Dijeljeno vlasništvno nad produktom – Energoinvest, FDS
o Dobri komunikacijski kanali
o Dobro radno okruženje
o Zajedničko druženje
• Ulazak u tim mora odobriti vođa tima i često svi članovi tima koji će raditi sa novim članovima.
• Individualci su problem za tim – treba ih ukloniti ili im naći zadatke koje mogu samostalno raditi.
Zasluge koje se pripisuju timu nisu u tom slučaju njihove zasluge.
• Za disfunkcionalne grupe su karakteristični pojedinci koje ne žele da pomognu drugima
(vremenski pritisak, prekovremeni rad, takmičenje između pojedinaca koji ne nagrađuje
saradnju).
• Karakteristike kompaktnog tima
o Rijetke izmjene članova tima
o Jak osjećaj povezanosti s timom osjećaj elitizma
o Zajedničko vlasništvo nad produktom
o Uzajamno pomaganje
o Očigledno uživanje u radu i u društvu ostalih članova tima
• Stvari koje sprječavaju nastanak kompaktnog tima
o Defenzivan menadžment
o Nepromišljena birokratija
o Fizičko izdvajanje članova tima
o Fragmentacija vremena – rad na različitim zadacima
o Nerealni rokovi
o Nedostatak vremena za kreiranje kvalitetnog produkta
o Kontrola grupa unutar tima
o Previše prekovremenih sati
• Povjerenje i respekt su ključni za dobar tim – oboje se stiče.
• Nezadovoljavaljuće performanse nekon člana tima moraju se ozbiljno tretirati (trening,
mentorstvo, bolji alati, klasifikacija odgovornosti, preraspodjela obaveza ili prebacivanje na drugi
projekat).
• Pojam, „in the flow“ – trenutak kada se pažnja pojedinca u potpunosti usmjeri na ono što radi i
zahtijeva 15 do 20 minuta od početka rada. Tada je pojedinac najproduktivniji ako nema
nikakvih ometanja.
• Projektni menadžer i lider tima moraju voditi računa da developeri ne nadopunjuju softver i ne
poboljšavaju njegov kvalitet više nego što je potrebno.
• Prekovremeni rad nije moguće izbjeći kod razvoja softvera, ali se treba svesti na 10% sedmično
(4 sata prekovremeno u sedmici ili dva dodatna radna dana u mjesecu). Duži prekovremeni rad
ne bi trebao trajati duže od 1-2 sedmice nakon čega slijedi adekvatna kompenzacija.
• Bornout ili sagorijevanje
o Predstavlja ličnu krizu koja počinje sa neprimijetnim simptomima, a može završiti sa
potpunom nesposobnošću za rad.
o Nema jedinstvene definicije niti je jednostavan za prepoznati jer ima ismptome koji se
ne mogu protumačiti na više načina. To je razlog što se često otkriva kada je već u
poodmakloj fazi. Mnogi psihijatri bornout smatraju modernom dijagnozom.
o Rezultat je emotivne i fizičke iscrpljenosti, preopterećenja, nezadovoljstva potignutim,
konstantnog stresa, pritiska, ...
o Početni simptomi su glavobolja, nesanica, neraspoloženje, razdražljivost, ... (90%
bornout osoba ima simptome depresije).
ODRŽAVANJE MORALA I MOTIVACIJE
• Održavanje morala se postiže najvećim dijelom kroz obezbjeđivanje okruženja i uslova u kojima
su pojedinci motivisani da dobrovoljno, pouzdano, rado i disciplinovano izvršavaju svoje zadatke
• Motivacija se također može postići i prijetnjom i izazivanjem straha (od kazne, poniženja,
gubitka posla). Ovaj pristup nije dobar za funkcionisanje tima.
• Psihološki elementi koji čine da osoba bude zadovoljna na poslu
o Osjećaj da je posao koji radi bitan
o Stalni osjećaj da je nešto postigla
o Priznanje za doprinos
o Korišenje različitih vještina
o Izvršavanje dobro definisanih zadataka
o Prilike za lični i profesionalni napredak
o Određeni nivo autonomije (inženjeri)
o Ugodna socijalna interakcija (oni koji rade u marketingu)
• Potrebno je shvatiti koji motivacijski faktor je bitan za koga ukoliko se želi postići pozitivno radno
okruženje
NE MOGU NASPRAM NE ŽELIM
• Efikasan lider mora razumijeti osobnost, vještine i motivaciju svakog podinog člana tima i
reagovati na situacije koje se mogu javiti na odgovarajući način.
4 moguća slučaja i pristupa kako ih riješiti

Nesposoban i nevoljan Realna situacija Podučavanje plus prodaja
Nesposoban ali voljan Opasna situacija Podučavanje plus pojačavanje
Sposoban ali nevoljan Nedostatak motivacije Prodaja plus pojačavanje
Sposoban i voljan Najbolja situacija Podučavanje plus delegiranja
• Tehnike podučavanja: kursevi, čitanje članaka, mentori, konsultantni

• Tehnike prodaje: anegdote, priče cijenjenih pojedinaca, gostujući predavači, kursevi, čitanje
radova
• Tehnike pojačavanja: kombinacija tehnike podučavanja, prodaje i drugih tehnika poput posjete
radionicama, uključivanje trenera
• Tehnike motivacije: tehnike prodaje i pojačavanja, uklanjanje barijera koje demotivišu pojedinca
• Tehnike delegiranja: rad s pojedincima na postavljanju ciljeva, davanje autoriteta i autonomije,
uspostavljanje procedura za prijavljivanje progresa i problema.
OSOBINE LIČNOSTI
• Ličnost određuju ponašanje, mentalne osobine i emocije.

• Pojedinci najbolje raguju na stil vođenja koji je kompatibilan sa njihovom ličnosti
• Metodična osoba orjentisana na detalje traži drugačiji nivo objašnjavanja od kreativne osobe
koja želi vidjeti „cijelu sliku“.
• Razvijeni su različiti modeli ličnosti. Neki od njih su korisni za sticanje uvida u različitost osobina
pojedinih tipova ličnosti
o Jungove osobine ličnosti
o Myers-Briggs indikatori tipa
o Wilson-ove dimenzije socijalnih stilova
• NIJEDAN MODEL NIJE KOMPLETAN! Oni opisuju neke aspekte ličnosti, ali ne daju cjelovitu sliku.
JUNGOVE OSOBINE LIČNOSTI
• Osobina ličnosti je karakterističan načina na koji osoba percipira, osjeća, vjeruje ili djeluje.
• Prvi uvodi razliku između introvertrnosti i ekstrovertnosti koje se odnose na način na koji
pojedinac percipira svoje okruženje
o Introvertne osobe: preferiraju unutrašnji svijet misli i osjećanja; za njih je čitanje knjige,
slaganje slagalice ili slušanje muzike način da uživaju u slobodnom vremenu
o Ekstrovertne osobe: preferiraju vanjski svijet stvari, ljudi i akcija; oni uživaju u
društvenim dešavanjima
• Sa svojim okruženjem se nosimo na četri načina: osjetilima, razmišljanjem, intuicijom i
osjećanjem.
• Većina osoba je introvertna ili ekstrovertna i koristi dominantno jedan od četiri načina da se nosi
sa svojim okruženjem. Drugi način koriste manje dominantno, a preostala dva gotovo nikako.
Način nošenja sa svijetom Osobine
Osjetila Koriste 5 čula i reaguju na informacije dobijene
na taj način
Razmišljanje Prikuplja informacije na logički način i prije nego
krene u akciju. Odluku donosi na racionalnoj
osnovi umjesto da reaguje na podražaje. Manje
su spontani od onih koji koriste dominantno
osjetila
Intuicija Percepcija svijeta izvan svjetnih procesa.
Podsvjestan način integriranja velike količine
informacija.
Osjećanja Procesiranje informacija bazirano na emotivnoj
reakciji.
• Nema svako predominantnu osobinu, ali se većina naučnika slaže da su introvertnost i

ekstravertnost i 4 osobine ličnosti identificiranje od strane Jung-a univerzalne za sve kulture.
(Carl Jung 1920. godine)
MBTI TIPOVI LIČNOSTI
• 1940-tih Katharine Briggs i njena kćerka Isabel Briggs Myers razvile su Myers-Briggs Type
Indicator (MBTI) baziran na Jungovim osobinama ličnosti.
• Ovo je trenutno najkorišteniji test za procjenu stilova ličnosti. Rezultati su vezani za četiri skale:
ekstrovert-introvert, osjetila-intuicija, razmišljanje-osjećanje i prosuđivanje-percipiranje.
• Četvrta skala govori koji Jungov stil dominira, a koji je drugi po dominaciji. Prosuđivanje govori
da su osobe metodične i sklone redu, Percipiranje znači da su osobe više fleksibilne i spontane.
• Postoje 16 stilova ličnosti. Većina ljudi podpada pod jedan stil, dok su neki mješavina 2-3 stila.
MBTI stilovi ličnosti Tipični izbor karijere

ENFJ Terepeuti, učitelji, prodavači
ENFP Političari, glumci, marketinški poslovi
ENTJ Rukovodioci i administratori
ENTP Analitičari i poduzetnici
ESFJ Pružanje usluga koji uključuje kontakt s ljudima
ESFP Umjetnost, odnos s javnošću
ESTJ Javne usluge, volonterske organizacije
ESTP Promotori, poduzetnici
INFJ Terapeuti, ministri, generali, doktori praktičari
INFP Prilologija, arhitektura, religija
INTJ Primjenjena nauka, inženjerstvo
INTP Filozofija, matematika, teorijska nauka
ISFJ Medicinske sestre, bibliotekari, učitelji
ISFP Umjernosti i priroda
ISTJ Računovođe, revizori, inženjeri
ISTP Vojnici, tehničari
E: Ekstrovertno; I: introvertno; S: Osjetila; N: Intuicije; T: Razmišljanje; F: Osjećanje; J: Prosuđivanje;
P: Percipiranje
• Rezultati ovog testa ukazuju na to da je više od 50% softver inženjera introvertno (dok je svega
25% ukupne populacije introvertno). Oni dominantno razmišljaju (80-90%). Softver inženjeri su
skloniji logičkom i analitičkom zaključivanju nego ljudskim odnosima kada se gleda ukupna
populacija.
• Najčešći tipovi ličnosti sa softver inženjere su INTJ i ISTJ. N ličnosti teže da sagledaju širu sliku
situacije (slika cjelovitog rješenja) dok S ličnosti teže detaljnom istraživanju užih oblasti (koraci
koji vode do rješenja problema). Njihovo miješanje unutar tima može doprinijeti boljem
rješavanju problema, jer imaju različit pogled na njih. Njihove interakcija može izazvati konflikte.
• Neki naučnici smatraju da stil projektnog menađera ima značajnu veza sa skalom prosuđivanje-
percipiranje.
• Pristup menadžera koji naginje ka prosuđivanje je ujedno i pristup koji se javlja u word
breakdown structures, metodi kritičnog puta i drugim metodama koje se koriste pri razvoju
softvera.
• Pristup menadžera koji naginje ka percipiranju je ujedno pristup iterativnog razvoja i
menadžmenta rizika za vrijeme izvršenja projekta.
• Razumijevanje vlastitog tipa ličnosti može pomoći da se kompenzuju osobine koje možda nisu
prirodne za taj tip
Preferencije menadžera koji je po MBTI

Na strani prosuđivanja Na strani percipiranja
• Postavlja jasne i mjerljive ciljeve • Shvata da jasan plan ne garantuje da će
• Razbija velike zadatke u podzadatke i sve ići dobro
ima metodičan pristup • Ostaje otvoren ka promjenama plana
• Prazi razvoj kroz vijeme uvodeći kada dobije više informacija
kontrolne tačke i pažljivo prati napredak • Saznaje šta dodatno motiviđe pojedince
• Brže donosi zaključke i nije sklon da se drže rokova (autonomija,
mijenjanju odluka mogućnost usvajanja novih vještina, ...)
• Voli rad u struktuiranom okruženju • Razvija načina da redovno skenira
• Smatra da je recept za uspjeh „Planiraj okruženje tražeći nove informacije ili se
šta ćer raditi, onda radi po planu“ konsultuje sa nekim ko ima prirodni dar
• Motivacija su mu postignuća za to
• Želi ostvariti rezultate na jednom • Dozvoljava pojedincima da rade na
projektu, a potom nastaviti dalje vlasiti način ali ih i dalje smatra
• Uspostavlja pravila ko donosi odluke i odgovornim za finalni produkt
kada • Planira spontanosst – braingstorming
• Vjeruje odgovornim osobvama da su periodi
sposobne odganizirati projekat i postići • U ranoj fazi traži povretnu informaciju o
željene ciljeve tome koliko je postavljeni vremenski rok
realan
DIMENZIJE SOCIJALNIH STILOVA
• 1960-tih Larry Wilson Predstavlja svoj model socijalnih stilova (stilova komunikacije – bio bi bolji
naziv)
• Dimenzije socijalnih stilova su korisne za osobe koje prelaze u menadžere, menadžere koji žele
poboljšati radne odnose, zaposlene koji žele uspostaviti efektivne odnose unutar tima,..., sve
ljude u organizacijama koji žele bolje da razumije druge i da prilagode svoje ponašanje kako bi
imali efektivnije interacije.
Pojmovi: Orijentisan na zadatak, Orijentisan na pitanja, Orijentisan na ljude, Orijentisan na govor

PETO-NIVOISKI MODEL PONAŠANJA
Curtis, Krasner i Iscoe predstavljaju peto-nivoiski model ponašanja kod razvoja softvera 1988. godine.
• Ovaj model ilustrira probleme komunikacije i koordinacije na nivou pojedinca, tima, projekta,
kompanije i poslovne sredine
• Model naglašava psilohošle, socijalne i organizacione procese na svakom nivuou. Cilj modela je
vidjeti kako ti procesi utiču na produktivnost i na kvalitet softvera.
• Nivoi
o Pojedinac: kognitivni i motivacijski proces
▪ Kognitivni stilovi temelje se na tipičnom načinu intelektualnog funkcionisanja za
pojedinca, koji se očituje u njegovom zasebnom opažanju svijeta, zazim učenju i
posebno rasuđivanju.
▪ Modivacija može biti ekstranzična (želja za vanjskim nagradama) i intrizična
(obavljanje posla šzo je zanimljiv i doživljava se kao nagrada po sebi – zahtijeva
nivo izazova koji odgovara trenutnim vještinama pojedinca).
o Tim: kogitivni i motivacijski procesi djeluju zajedno sa sovijalnim procesima tima.
Otvaraju se pitanja komunikacije i koordinacije
o Organizacija: na projekte koje realizira kompanije utiče korpativna politika i kultura
o Poslovna sredina: interakcija sa drugim elementima matične organizacije, klijentove
organizacije, dobavljačima..
• Od veličine projekta zavisi nivo uticaja svakod od nivoa. Na male projekte viši nivoi utiču malo ili
nikako.
• Analiziraju se 3 problema:
o tanko širenje aplikacijskog domena znanja
▪ izuzetni dizajneri imaju nevjerovatan uticaj jer mogu ugraditi svoje aplikativno
znanje
▪ na nivou tima ulaže se dodatni trud da se koordinira razumijevanje aplikativnog
domena i modela sistema
▪ na nivou projekta treba osigurati da razvojni timovi dijele isti model sistema
▪ na nivou kompanije troši se vrijeme i novac za učenje nove oblasti aplikacije i
uključivanje novog člana tima u projekat )6-12 mjeseci)
▪ na nivou poslovne sredine razumijevanje aplikativnog domena i arhitekture
sistema koče ograničenja između pojedinih kompanija
o fluktuirani i konfliktni zahtjevi
▪ na nivou poslovne sredine javljaju se fluktuacije i konflikti kod zahtjeva (mijenja
ih korisnik ili se mijenja tehnologija i konkurentski produkt)
▪ na nivou kompanije problemi sa zahtjevima se javljaju radi unutrašnjih faktora
(korporativna politika, marketing, menadžment)
▪ na nivou projekta dizajnerski tim često pregovara s ciljem reduciranja konflikta i
limitacije zahtjeva (napraviti ono što je moguće s novcem i vremenom i
tehnološkim ograničenjima
▪ na nivou tima teško je primijeniti postignute dogovore
▪ pojedinci programeri često kreiraju skrivene izvore fluktuacije zahtjeva kada
dodaju poboljšanja koja nisu tražena
o komunikacijski i koordinacijski pad
▪ pojedinac i pored dokumentacije i dalje mora dosta da komunicira
▪ timovi dosta vremena provode definišući uslove, koordinirajući razgovore i
kreirajući komunikacijske kanale za protok informacija
▪ na nivou projekta potrebno je uključiti pojedince iz timova da komuniciraju
međusobno i stvore komunikacijsku mrežu
▪ na nivou kompanije organizacijeke granice sprješavaju razumijevanje zahtjeva
▪ na nivou poslovne sredini sve grupe su presudne za upravljanje projektom i
imaju svoje zahtjeve
HIPOKRAT-GALENOVA KLASIFIKACIJA
• Smatraju da postoje 4 temperamenta

• Temperament se određuje kao konstitucijski uvjetovan tipični način čovjekovog emotivnog
reagovanja.
1. Kolerik – intenztivne emocije koje se naglo i često javljaju. Lako zapada u stanje srdžbe
2. Sangvinik – relativno brzo emotivno reaguje, alu mi reakcije nisu osobito jake ni trajne. Lako
mijenja svoje emotivno stanje i više je sklon vedrom raspoloženju.
3. Flagmatik – brlo rijetko reaguje emotivno, a kada reaguje emociju mu se sporo javljaju i
slabog su intenziteta. Radi se u pravilu o mirnom, stabilnom, slabo osjetljivom i slabo
pokretljivom čovjeku.
4. Melankolik – rijetko emotivno reaguje, ali kada reaguje reakcije su mu jake i traju dugo.
Reaguje emotivno na sve što je u vezi s njegovom osobnošću. Teško se odlučuje, slabo je
pokretljiv i kod njega često prevladavaju emocije tuge i zabrinutosti.
PREDAVANJE 7 – PLANIRANJE PROJEKTA
UVOD
• Menadžment projekta — proces vođenja projekta od njegovog početka do završetka koristeći

skup menadžment modela
• Funkcionalni pogled na projekat: planiranje i procjenjivanje, mjerenje i kontrola, komunikacija,
koordinacija i vođenje, upravljanje rizicima
• Dinamički pogled na projekat: definicija, početak , izvršenje, reorganizacija i završetak
• Planiranje projekta — fokus na fazi definisanja: definisanje problema, planiranje rješenja i
procjena resursa. Izlazi su:
o Opis problema (kratki dokument — problem statement)
▪ razvijaju ga klijent i projektni menadžer iterativno
▪ opisuje trenutnu situaciju, funkcionalnosti koje treba podržati, razvojno
okruženje, očekivane rezultate, datume isporuke i uslove prihvatanja
▪ nije kompletna specifikacija već sažetak dva buduća dokumenta: analiza potreba
na projektu i Software project management plan (SPMP)
o Top-level dizajn
▪ opis softverske arhitekture koju radi softverski arhitekt
▪ inicijalna dekompozicija sistema na podsisteme koji se dodjeljuju pojedinim
timovima (obavezno se revidira tokom faze dizajna podsistema)
▪ fokus je na funkcionalnosti, identificirani su glavni podsistemi i njihovi servisi, ali
nisu definisani interfejsi
▪ služi za kreiranje dokumenta za dizajn sistema
o Software project management plan (SPMP) — svi upravljivi aspekti projekta:
organizacija, work breakdown struktura, radni paketi, raspored
▪ prva verzija — detalji samo za rane faze projekta
▪ piše je projektni menadžer tokom faze definisanja projekta
▪ zaokružen dokument dobija se tek nakon faze analize i revidiraju ga menedžeri i
developeri
▪ na ovom dokumentu se radi sve dok projekt traje, a dinamika promjene zavisi
od situacija koje nastaju tokom projekta
Software project management plan (SPMP)
1. Uvod 3. Upravljivi procesi
1.1. Pregled projekta 3.1. Ciljevi i prioriteti menadžmenta
1.2 . Izlazi 1z projekta 3.2. Pretpostavke, ovisnosti i zahtjevi
1.3. Evolucija ovih dokumenata 3.3. Risk menadžment
1.4. Reference 3.4. Mehanizmi monitoringa i kontrole
1.5. Definicije i akronimi
2. Organizacija projekta 4. Tehnički procesi
2.1. Model procesa 4.1. Metode, alati i tehnike
2.2. Organizaciona struktura 4.2. Softverska dokumentacija
2.3. Organizacijske granice i interfejsi 4.3. Funkcije za podršku projekta
2.4. Odgovornosti na projektu
5. Radni elementi, vremenski plan i budžet
• Komponente projekta i njihove međuzavisnosti mogu se predstaviti pomoću menadžment

modela:
o Work breakdown struktura — hijerarhijska reprezentacija svih zadataka na projektu:
dekompozicija aktivnosti (grupe vezanih zadataka) na upravljive zadatke
o Model aktivnosti / mrežni dijagram — razmatra privremene zavisnosti između zadataka
o Organizacioni chart — prikazuje učesnike u projektu i njihove uloge (inicijalni plan
upravljanja projektom, identifikacija vještina)
o Projektni plan — mapirani mrežni dijagram
o Planiranje projekta — izlaz ne možemo dobiti kroz jednu monolitnu aktivnost: podijeli
pa vladaj
o Dekompozicija radnih paketa u manje zadatke (identifikacija aktivnosti i njihovih
međuzavisnosti)
o Planiranje je iterativni proces — rad na produktu povećava razumijevanje
o Izvodivost projekta — osnovni, željeni i opcionalni zahtjevi
WORK BREAKDOWN STRUKTURA (WBS)
• Jednostavna hijerarhijska reprezentacija svih zadataka na projektu

• Agregacija cjelokupnog rada potrebnog da se odradi na projektu
• Cilj je uraditi dekompoziciju ukupnog posla na zadatke koji su dovoljno mali da se može
procijeniti njihovo trajanje i da se mogu dodijeliti jednoj osobi. Sadrži menadžerske i tehničke
aktivnosti projekta.
• Različiti pristupi razvoju WBS

o Funkcionalna dekompozicija bazirana na softverskim procesima — najčešća
o Funkcionalna dekompozicija bazirana na funkcijama produkta — u slučaju projekta
visokog rizika
o Objektno-orjentisana dekompozicija
o Dekompozicija po geografskim oblastima ili organizacionim jedinicama
• Funkcionalna WBS
Lista koraka WBS

Uradi autentifikaciju 1. Napraviti listu koraka za autentifikaciju
1.1. Razviti forme za korisnički interfejs (Login,
mijenjanje PIN-a)
1.2. Realizacija autentifikacijskog protokola sa
serverom
1.3. Razviti inicijalno kreiranje računa
Povuci novca 1. Napraviti listu koraka za povlačenje novca
2.1. Razviti forme za korisnički interfejs (selektuj
račun, specificiraj iznos)
2.2 Ostvari komunikaciju sa serverom
2.3. Razviti poslovnu logiku za odobravanje
povlačenja novca
2.4. Razviti interfejs sa distributerom novca
Provjeri depozit 3. Napravi listu koraka za provjeru depozita
3.1. Razviti forme za korisnički interfejs
(specificiraj provjeru, ubaci provjeru)
3.2. Ostvari komunikaciju sa serverom
3.3. Razvtij poslovnu logiku za bilježenje
depozita
2.4. Razviti interfejs sa štampačima ceduljica
• Objektno-orijentisana WBS
• Korisne stvari kod kreiranja WBS za menadžera

o korištenje postojeće WBS
o uključivanje ključnih developera
o identifikacija radnih gap-ova
o identifikacija preklapanja poslova
• WBS dekompozicijski kriteriji
o otkrivaju se skrivene kompleksnosti (npr. posao koji treba uraditi je jasan)
o mogu se identificirati mogućnosti ponovnog korištenja postojećih softverskih
komponenti
o mogu se specificirati potrebni hardverski resursi (moguće da će iz toga proizaći revizija
o hardverskih potreba)
o moguće je uraditi estimaciju potrebnog napora za razvoj softvera
• Poznati problem traži manji nivo dekompozicije. Dubina WBS je tipično 3-4 nivoa tokom faze
planiranja i proširuje se sa još 1-2 nivoa tokom faze izvršavanja projekta.
15 SMJERNICA ZA DIZAJN WBS
1. Koristiti Arhitecture Decomposition View (ADY) kao bazu (specificira hierarhiju“dio je/ is-part-
of“; elementi su imenice)
2. Struktuirati ADV i WBS da bi se olakšala dodjela zadataka
3. Razviti i koristiti procesno-orjentisanu WBS
4. Ukomponovati radne aktivnosti tokom razvoja i modifikacije modula produkta u WBS (imenični
izrazi iz ADV prelaze u odgovarajuće glagolske izraze)
5. Podijeliti projekat na maksimalno 7-8 funkcionalnih oblasti na najvišem nivou WBS (uključuje sve
što treba uraditi na projektu)
6. Svaki od elemenata ne granati na više od 7 podelemenata
7. Dubina WBS ide do 6-7 nivoa
8. Koristiti decimalni brojni sistem radi sistematične identifikacije radnih aktivnosti i zadataka
9. Alocirati priroritetne zahtjeve za razvojne aktivnosti i zadatke u WBS
10. Dizajnirati WBS top-down, bottom-up i middle out
11. Koristiti radne pakete za specifikaciju projektnih zadataka (3)
12. Analizirati radne zadatke za željene osobine projekta — dobijaju se informacije o budžetu (4)
13. Izvesti vremenski plan na osnovu radnih paketa (mrežni dijagram) (1)
14. Odrediti potrebne resurse na osnovu radnih paketa i vremenskog plana (2)
15. Revidirati i elaborirati WBS periodično i kada nastupi neki događaj
INICIJALNI VREMENSKI PLAN I MREŽNI DIJAGRAM
• Zadaci imaju međusobne zavisnosti, vrijeme trajanja, broj učesnika

• Mrežni dijagram reprezentira projekat tj. sve događaje, aktivnosti i veze među njima
• Procjenu trajanja zadataka određuje menadžer prije početka projekta

o često nedovoljno precizno
o inicijalni vremenski plan
o kreira se detaljno za prvih par sedmica projekta — ostatak prati sadržaj dokumenta koji
opisuje problem i revidira se (softverski arhitekt 1 timovi)
o timovi rade na planiranju aktivnosti paralelno sa fazom analize zahtjeva i dizajna sistema
o novi zadaci za WBS trebaju biti prezentovani do kraja faze analize
o ovo su informacije za drugu verziju SPMP
• Tehnike mrežnog planiranja — poddiscipline
o Analiza strukture: aktivnosti, zavisnosti, numeracija a co
A — WBS broj, trajanje i radni paket
KLJUČNE TAČKE — milestones (može biti svaki čvor)
o Analiza vremena
o Analiza troškova
ukupan napor koji se ulaže u jedan zadatak (i) izražava se u inžinjer-sedmicama (ei)
napor na nivou projekta: množenje trajanja zadatka sa brojem ljudi angažovanih na
njemu i suma svih zadataka na projektu (E)
o Estimacija troškova: neka je plata za inžinjer-sedmicu X, tada su troškovi projekta X*E
o Analiza resursa
na projektu je obično fiksan broj ljudi pri čemu pojedine faze projekta traže više a neke
manje developera
zanemariti u potpunosti kod inicijalnog mrežnog dijagrama 1 rješavati naknadno
- koristeći reorganizacija zadataka, produžetak trajanja, dodavanje resursa,
korištenje efikasnijih resursa, reduciranje zahtjeva
- NE ići na prekovremeni rad i redukciju kvaliteta
• Tehnike mrežnog planiranja omogućava procesno praćenje i nadziranje toka projekta, kao i
precizno planiranje rokova završetka projekta i planiranje troškova projekta
• CPM i PERT metoda
• Određuje se najkraće vrijeme trajanja projekta i kritični put
• Rezerve na kritičnom putu
• Vremenski ograničenja zadataka — neovisna od međuzavisnosti zadataka
o ASAP — najčešće ograničenje od strane naručilaca zadatka
o ALAP — najčešće ograničenje od ASAP strane primalaca zadatka
Ograničenje Definicija
ASAP Počni zadatak što prije
ALAP što kasnije
FNET ne završavaj prije
SNET ne počinji prije
FNLT ne završavaj kasnije od
SNLT ne počinji kasnije od
MFO mora se završiti u
MSO mora početi u
• Radni paketi se dodjeljuju pojedinim timovima

• Ne ići u previše detalja
MATRICA VJEŠTINA
• Matrica vještina je praktična forma za raspoređivanje pojedinaca na određene zadatke na

osnovu njihovih vještina, znanja i interesa.
• Kriteriji:
o primarne vještine ili znanje čini osobu kvalifikovanom da vodi određeni zadatak (a)
o sekundarne vještine 1li znanje čini osobu kvalifikovanom da učestvuje u izvršavanju
zadatka (b)
o interes znači da osobu zanima zadatak ali da ne posjeduje potrebne vještine (c)
Zadatak/učesnik A B C D
Dizajn kontrole (b) i (c) (b)
Dizajn baze podataka (b) (b) (a)
Dizajn korisničkog interfejsa (c) (b) i (c)
Konfiguracijski menadžment (c) (b)
• Ko su raspoloživi učesnici zavisi od strukture organizacije: projek-bazirane, linijske (funkcionalne)

i matrične organizacije
• Nakon kreiranja inicijalne WBS i mrežnog dijagrama menadžer zna koje su vještine potrebne za
svaki od zadataka
• Vještine potrebne za razvoj softverskog projekta:
o iz oblasti iz koje se pravi aplikacija
o komunikacijske
o tehničke
o za provjeru kvaliteta
o menadžerske
• Uloge na projektu i vještine koje zahtijevaju
o menadžerska: jedna osoba, vještina komunikacije, prepoznavanja rizika u ranoj fazi,
disciplina da razdvoji menadžerske od tehničkih odluka
o tehnička: menadžer je ujedno i softverski arhitekt kod malih projekata, tehničke uloge se
mogu dodijeliti i timu ljudi, vođa tima je zadužen za raspoređivanje poslova unutar tima,
potrebne vještine vođe tima su: efiktivna komunikacija, prepoznavanje kriza (tehničkih 1
društvenih), dobro balansiranje odluka, tehnički vođa je veza sa timom zaduženim za
arhitekturu sistema i potrebne vještine su: izvanredno tehničko znanje i iskustvo u
razvoju sistema
• Na šta treba obratiti pažnju
o nedovoljno ljudi sa potrebnim vještinama — menadžer planira formalni ili neformalni
trening
o menadžer određuje vođu tima prije formiranja tima — bar jedan iskusni developer za
svaki tim
o dodjela svih developera istovremeno na projekat (flat staffing) ili po potrebi (gradual
staffing)
KONTROLA PROJEKTA — METODE PROCJENJIVANJA (ESTIMACIJE)
• Za donošenje efektivnih odluka tokom faze izvršavanja projekta, menedžer treba precizne
informacije o njegovom stanju koje je teško dobiti:
o sistem je kompleksan— teško je procijeniti uticaj pojedinih komponenti
o developeri ne prijavljuju vođi tima probleme koje misle da mogu riješiti unutar tima
o ne prijavljuje se manja kašnjenja, ali ona mogu dovesti do značajnih poremećaja u
kasnijim fazama
• Alati za prikupljanje informacija o trenutnom stanju projekta
o sastanci — ključno je da tima ima povjerenje u menadžera
o oštre ključne tačke — završeno kodiranje I PROVJEREN KVALITET KODA (testiranje,
demonstracija, dokumentacija 1 integracija), ne zahtijeva saradnju developera
o pregled projekta — prezentacije svih timova
o inspekcija koda — formalne peer review je efektivna metoda za otkrivaje defekata u
ranoj fazi
o demonstracija prototipa — evaluacija tehnologije i funkcionalnosti, ali zanemaruje
rubne slučajeve i ne govori o robusnosti implementacije (mjeri progres ali nije oštra
mjera za procjenu koliko je posla urađeno)
TEHNIKE ESTIMACIJE (PROCJENE)
• Cilj estimacije je da se odredi skup parametara koji daju visok nivo pouzdanosti da će biti
moguće isporučiti prihvatljiv projekat unutar granica postavljenih kroz zahtjeve
• Parametri i zahtjevi koje treba razmotriti (dati kao zahtjevi ili procijenjeni)
o svojstva produkta
o atributi kvaliteta
o napor
o drugi resursi
o vremenski plan
o budžet
o tehnologija
• Estimacijske vrijednosti često značajno odstupaju od stvarnih
o nejasni i promjenljivi zahtjevi
o inicijalna estimacija nije unaprijeđena novim znanjem stečenim kroz bolje razumijevanje
problema
o neadekvatne metode ili alati
o veća kompleksnost finalnog projekta od očekivane
o pogrešna ili pristrasna procjena stručnjaka
o broj raspoloživih developera i njihove vještine nisu razmatrane prilikom estimacije
o eksterni faktori
FUNDAMENTALNI PRINCIPI ESTIMACIJE
• (princip 1.) Estimacija projekta je projekcija iskustva iz prošlosti u budućnost, prilagođena na

način da uzima u obzir razlike između prošlosti i budućnosti
o potrebno iskustvo iz prošlosti (baza za estimaciju, eksperti, lokalni rules of thumb,
industrijski prosjek)
o potrebno poznavanje budućnosti (zahtjevi sistema 1li produkta na kojem se radi)
o potrebno prilagođavanje kako bi se uzela u obzir razlika između prošlosti i budućnosti
(faktor prilagođavanja)
• Koristiti uvijek više tehnika za estimaciju
• Provjeriti alate koji se koriste i prilagoditi ih potrebama projekta koji se estimira
• Faktori prilagođavanja su atributi koji uzrokuju da se naizgled slični projekti razlikuju po naporu,
vremenskom planu, resursima, troškovima, ... i uključuju:
o relativnu kompleksnost produkta
o vještine i sposobnosti developera
o specifičnost i nestalnost zahtjeva
o pretjerani zahtjevi poput vremenskog pritiska
• Primjer: Novi projekat je kompleksniji od ranije rađenih projekata za 20%. Raniji projekti su
trebali 10 mjeseci i u prosjeku 10 softver developera (10 full-time ekvivalent FTE). Koliko treba
developera ako se novi projekat treba završiti za 9 mjeseci?
za ranije projekte: FTE=(10*10) inžinjer-mjeseci / 10 mjeseci = 10
20% kompleksniji projekat — 10 mjeseci i 12 developera ili 12 mjeseci i 10 developera
FTE = 120 inžinjer-mjeseci / 9 mjeseci = 13,3
treba više od 13 developera (voditi računa o složenijoj komunikaciji i koordinaciji radi
većeg tima)
• Duplo više ljudi ne znači duplo brži završetak projekta. Projekt nije moguće skraćivati po želji, jer
treba voditi računa o raspoloživosti resursa i drugim preduslovima.
• (princip 2.) Sve estimacije se baziraju na skupu pretpostavki koje treba realizovati i skupu
zahtjeva koje treba zadovoljiti.
• (princip 3.) Projekt se treba ponovo estimirati i to periodično, kako se povećava razumijevanje
projekta, i aperiodično kada se promijene parametri.
• Preporuka — ponovnu estimaciju 1 planiranje treba raditi:
o mjesečno za projekte kraće od 12 mjeseci
o jednom u 4 mjeseca za duže projekte
o kod velikih promjena u zahtjevima, zakazivanja nove tehnologije, skraćivanja
vremenskog plana, redukcije budžeta, nedostatka ključnog osoblja
• Prihvatljivo rješenje kada nastane problem:
o promjena opsega zahtjeva
o produžetak vremenskog plana
o dodavanje resursa
o korištenje boljih resursa
• Neprihvatljiva rješenja
• prekovremeni rad, redukciranje verifikacije i validacije, reduciranje dokumentacije
• Projekat je uvijek veći i kompleksniji nego što se pretpostavi — novčana rezerva od 10% do 50%
kao i mogućnost promjene ugovora
• Stara izreka: “Softver možeš dobiti: brzo, jeftino, da bude dobar; odaberi bilo koja dva.“
• Balansiranje tri fundamentalna parametra estimacije — vremenskog plan, resursa i zahtjeva
• Isporučiti prihvatljiv produkt na vrijeme i u okviru raspoloživog budžeta
o svi osnovni zahtjevi i neki željeni zahtjevi ispunjeni
• Bar jedan od tri parametra treba da bude fleksibilan. Postavka svih parametara na fiksne
vrijednosti (ili prestroga ograničenja) je gotovo siguran način da projekat propadne.
ESTIMACIJA VELIČINE PRODUKTA
• Većina metoda za estimaciju baziranih na produktu faktora koristi neke mjere veličine produkta
kao primarni faktor za estimaciju
o veličina ima jaču uzročnu vezu sa projektnim atributima napor i vremenski plan u
odnosu na druge atribute
o može se objektivnije mjeriti nego ostali atributi
o podaci vezani za veličinu, napor, vremenski plan 1 drugi mogu se povuči iz baze kreirane
na osnovu prethodno završenih projekata
• Delivered source lines of code (DSLOC ) je mjera za veličinu. Nedostaci: teško procijeniti na
početku projekta, kvalitet vs kvantitet, lični kod vs gotov kod
• Function points (FP) je prva alternativa DSLOC. Računa se brojanjem različitih vrsta ulaza, izlaza,
internih fajlova, upita i interfejsa u sistemu koji se estimira.
• DSLOC je neovisan o programskom jeziku dok FP nije.
TEHNIKE ESTIMACIJE – PRAGMATIČNE
• Pragmatične tehnike estimacije, teoretski bazirane tehnike estimacije i modeli estimacije

bazirane na regresiji — prva ne mora koristiti veličinu kao primarni ulaz za estimaciju, za razliku
od druge dvije.
• rule of thumb (ROT) - metoda koja dolazi iz prakse i nema formalni dokaz
• analogija
• procjena eksperta
• Delphi
• WBS/CPM/PERT
• Rule of thumb je generalo prihvaćena smjernica — softver inžinjering ne radi s fizičkim
entitetima pa koristi smjernice od kojih su neke općeprihvaćene u industriji kao npr.
o 50 do 100 puta je skuplje popraviti defekat nakon puštanja softvera nego prije
o 500 DSLOC/SM općeprihvaćena za konkretan softver ili lokalno za neku organizaciju i
njenu vrstu softvera (SM — staff-month 1li inžinjer-mjesec)
o Kako se broje linije koda? sa/bez komentara, sa/bez datotečnih rutina, sa reused, open
source kodom
o Je li negdje uključen napor uložen u testiranje i ostale aktivnosti mimo testiranja 1
kodiranja?
• Kod ROT treba voditi računa o sljedećem
o koja je mjera korištena kod estimacije (npr. DSLOC/SM ili FP/SM)
o da se kosristi za istu veličinu produkta jer je i za slične produkte faktor prilagođavanja
obično nelinearan
o riskantno je kosristiti samo ovu estimaciju iako je dobra za studije izvodivosti (what if
scenario) i grubu procjenu
• Analogija se često koristi u inžinjerskim disciplinama s ciljem pronalaska jednog ili više analognih
projekata kod kojih su poznati značajni atributi
o ROT je pouzdaniji ako je urađen za analogne projekte
o može postojati baza ranijih projekata sa bitnim atributima (kupac; vrsta produkta;
veličina i korišteno mjerenje; faktor prilagođavanja; razvojni model i alati; estimirano
vrijeme, napor i budžet i stvarne vrijednosti;...) — radi se upit i traži podudarnost sa
prijašnjim projektima do nekog nivoa (npr 10%)
• Kod analogije treba voditi računa o sljedećem
o dobra analogija je dobra baza za estimaciju
o pogrešne analogije daju netačnu estimaciju
• Procjena eksperta: traži se od jedne ili više stručnih osoba da estimiraju atribute projekta
o faktori prilagođavanja koje primjenjuju mogu uključivati subjektivne faktore poput
poznavanja radnika
o mogu reći da su faktori nejasni i nekompletni — ovo je korisno
• Kod procjene eksperta treba voditi računa o sljedećem:
o različiti ekspert mogu procijeniti različite dijelove sistema (npr. bazu, mrežu)
o eksperti mogu uključiti subjektivne i političke faktore koji nisu u bazi za estimaciju
o eksperti mogu biti preoptimistični ako procjenu ravnaju prema sebi (manje iskusni
developeri nisu efikasni kao eksperti)
o oslanjanje na prethodno iskustvo može biti netačno ili nekompletno
• Delphi estimacija radi sa procjenama više eksperata koje mogu ići kroz više krugova
o prvi krug — svaki ekspert daje estimaciju na bazi istih ulaznih podataka koristeći metode
koje želi
o koordinator vraća ove rezultate bez imena eksperata i svim dodatnim informacijama
koje su tražili (obično se koristi e-mail 1 templejti)
o drugi krug — ponovna estimacija na bazi dobijenog pregleda (dva dana za procjenu)
o broj krugova nije određen
o finalni sastanak se koristi za potvrdu estimacije i razgovor o potencijalnim problemima ili
za raspravu ako estimacija ne konvergira
o postoje varijacije tradicionalne Delphi estimacije (sastanci nakon svakog kruga — javni ili
anonimni)
• Kod Delphi estimacije treba voditi računa o sljedećem
o ne mora biti postignut dogovor (dodatni rad ili korištenje rezultata za analizu rizika)
o kombinacija mišljenja eksperata dobija se bez uticaja eksperata jednih na druge
o više krugova omogućava upoređivanje rezultata
o troši vrijeme i napor eksperata
o problem može biti nepopustljivost ili prejak uticaj jednog eksperta
• WBS/CPM/PERT je pristup baziran na WBS i radnim paketima
o estimacija radnih paketa može se bazirati na nekoj drugoj tehnici
o vjerovatno je najtačnija pragmatična tehnika jer se pozitivne i negativne varijacije
vezane za tačnost na nižim nivoima izniveliraju tokom agregacije na višim
• Kod WBS/CPM/PERT treba voditi računa o sljedećem
o povećana je tačnost estimacije jer se ide u detalje i bolje se razumije sistem
o u ranoj fazi planiranja nedostaje znanje ili vrijeme za pripremu WBS, mrežnih dijagrama,
radnih paketa
PREDAVANJE 8 – KONTROLA PROJEKTA
UVOD
o Menadžerisanje softverskog projekta uključuje planiranje i estimaciju, mjerenje i kontrolu,

koordinaciju i vođenje i upravljanje rizicima.
o Potrebno je obezbijediti objektivne ciljeve na osnovu kojih se može odrediti napredak i kvalitet.
o Napredak se mjeri periodičnim određivanjem trenutnog statusa svakog atributa i poređenjem tog
statusa s planiranim (sedmično, svake dvije sedmice, mjesečno): očekivani napor, vremenski
plan, troškovi, trenutni status produkta...
o Status projekta je dokumentovan u izvještaju napretka na osnovu kojeg se vidi koji faktori
projekta su kakvi trebaju biti po planu, a koje treba istražiti radi mogućih korektivnih mjera.
o Kontrola projekta se vrši primjenom korektivnih akcija ukoliko jedna ili više dimenzija napretka
odstupa od plana više od dozvoljenog, ili kada je odnos između projektnih atributa disbalansiran.
• Kašnjenje od 2 dana kod dostizanja velikog cilja ne zahtijeva korekcione mjere, ali 2
sedmice mogu uzrokovati neprihvatljivo kašnjenje koje zahtijeva korekcione mjere.
• Prekoračenje memorije za neki softver od 2% nije alarmantno, ali 20% može biti ozbiljan
problem.
o Korektivne mjere zavise od prirode odstupanja od izvornog plana i mogu uključivati:
• Produžetak vremenskog plana
• Dodavanje resursa (veći broj ljudi ne mora značiti veći efekat)
• Korištenje superiornijih resursa
• Poboljšanje različitih elemenata u razvojnom procesu
• Poboljšanje tehnologije (opasnost od produžetka trajanja projekta)
• Smanjenje opsega produkta (prioriteti zahtjeva, iterativni razvojni proces)
o Planiranje, estimacija, mjerenje i kontrola softverskog projekta su institucionalizovani
menadžment rizika.
o Moguće je isporučiti prihvatljiv produkt bez planiranja, estimacije, mjerenja i kontrole, ali to je
malo vjerovatno.
o Dodatni troškovi se ulažu u povećanje vjerovatnoće uspjeha i treba ih balansirati s troškovima
koji nastaju ako se ne uspije isporučiti prihvatljivi produkt na vrijeme.
o Razlozi za mjerenje:
• Obezbijediti frekventne indikatore progresa (ili uočavanje nedostatka istih)
• Obezbijediti rano upozorenje na probleme
• Dozvoliti analizu trendova za projekat
• Dozvoliti estimaciju finalnih troškova i završnog roka projekta
• Izgradnja repozitorija podataka.
o Učestalost mjerenja zavisi od metode razvoja softvera (agilna, inkrementalna, vodopad), od toga
šta se mjeri, od načina rada timova (učestalost sastanaka na kojim se podnosi izvještaj), od grupa
koje se sastaju (vođe timova s timom, menadžeri s korisnicima).
o Učestalo mjerenje omogućava ranu identifikaciju problema kao i predviđanje trendova kada su u
pitanju atributi projekta (defekti, trošak, vremenski plan).
• Npr. projekat kasni dvije sedmice, a završeno je pola projekta.
o Estimacija je projekcija iz prošlosti na budućnost koja je prilagođena na adekvatan način kako bi
uzela u obzir razlike između prošlosti i budućnosti.
o Estimacija bazirana na lokalnim podacima je pouzdanija od one bazirane na rules of thumb ili
industrijskom prosjeku.
• Cilj je kreiranje repozitorija podataka kako bi se estimacije budućih projekata mogle
bazirati na njemu.
• Analiza skupljenih podataka može otkriti učestale probleme koje treba razriješiti.
o Atributi koji se mjere ne zavise od kriterija uspješnosti, ali uglavnom se mjere:

• Napor: količina rada potrošena na razne radne aktivnosti
• Vremenski plan: postignuća u objektivno mjerljivim kontrolnim tačkama
• Trošak: trošak za razne resurse uključujući i napor
• Progres: završeni i prihvaćeni radni produkti
• Osobine produkta: implementirani i provjereni zahtjevi
• Atributi kvaliteta: defekti, dostupnost, pouzdanost, vrijeme odziva, propusnost
• Rizik: status faktora rizika i akcije za njihovo ublažavanje
o Boldirani atributi su suprostavljeni neboldiranim atributima.
o Pretjerano trošenje vremena, napora i novca na analizu i akcije vezane za mjerenje procesa je
indikator da je proces razvoja i menadžmenta neefikasan.
MJERE I MJERENJA
o Mjera je simbol dodijeljen nekim atributima pojava iz realnog svijeta (korištenje cjelobrojnih ili
realnih brojeva za mjerenje temperature).
o Mjerenje je proces mapiranja nekog atributa pojave iz realnog svijeta na skup simbola za koji su
specificirane dobro definisane operacije (mapiranje temperature putem Celziuseve, Farenhajtove
ili Kelvinove mjerne skale).
o Postoji 5 najčešće korištenih mjernih skala:
• Nominalna: frekvencije pojave između mjernih kategorija
dodjeljuje stavke kategoriji (broj ljudi za analizu, dizajn)
• Redna: redoslijed unutar kategorija s proizvoljnim intervalima između mjera
(nisko, srednje, visoko) – (1, 2, 3) ili (0, 4, 6), nema objektivnog nultog elementa
Interval: ravnomjerni intervali između mjera i proizvoljni nulti element
temperatura izražena u Celziusima, Farenhajti – 0 stepeni celzijusa nije duplo toplije od
30 stepeni
• Omjer: ravnomjerni intervali između mjera i proizvoljni nulti element
broj linija koda – 100 linija je dva puta više od 50 linija koda; temperatura izražena u
Kelvinima – 0K znači odsustvo temperature jer se atomi prestaju kretati; 200K je duplo
više od 100K jer se gleda kinetička energija atoma
• Absolutna: slična omjeru ali s jedinstvenim mjerama
npr. zabrana da se FP trasformišu u LOC u suprotnom se radi o omjer mjernoj skali
o Pravila mapiranja pojave na korištenu mjeru moraju biti dobro definisana i ravnomjerno
primjenjena unutar organizacije
• Kako se broje linije koda?
• Kako se broje defekti, ketegoriziraju li se?
o Zloupotreba mjernih skala
• Ocjenjivanje profesora (redna skala koja se koristi kao skala omjera)
o Direktne mjere (direktno primjenjivanje pravila mjerenja na pojavu) i indirektne mjere
(kombinacije direktnih mjera koristeći odgovarajuće operacije za tu mjernu skalu).
• FP, LOC?
o Direktne mjere:
• Veličina softvera (line of code)
• Broj zaposlenika po kategorijama (programeri, testeri)
o Indirektne mjere:
• Veličina (function points)
• Produktivnost (broj linija koda razvijeno tokom inžinjer-mjeseca)
MJERENJE ATRIBUTA PRODUKTA
o Mjerenje zahtjeva (operacijske mogućnosti, atributi kvaliteta, zahtjevi za dizajn) i tehničkih

specifikacija (primarni zahtjevi, izvedeni zahtjevi, atributi kvaliteta, zahtjevi za dizajn)
• prioritet, nivo granulacije, izvodivost, primatni-sekundardni scenario
o Mjerenje i kontrola promjena na produktu – kod kontrolnih tačaka se radi provjera određenih
produkata. Ovi produkti se mijenjaju ako se promijene uslovi koji utiču na produkt (prijava
promjene – CR) ili ako je produkt nekompletan (zahtjevi za izmjenu), netačan ili nekonzistentan
(prijava defekata DR). Promjene moraju biti odobrene, dokumentovane i moraju se postaviti nove
kontrolne tačke (novi zahtjevi se npr. mogu uključiti tek u drugoj verziji softvera).
• velike promjene signaliziraju nestabilnost projekta, posebno ako traže dosta dorade
o Mjerenje atributa dizajna arhitekture sistema – softverski dizajn uključuje dizajn
arhitekture (sinteza skupa komponenti, specifikacija strukturnih veza i odnosa između
komponenti, specifikacija interfejsa) i dizajn detalja (specifikacija interfejsa, algoritama,
strukture podataka, internog ponašanja, mehanizma za obradu izuzetaka svake softverske
komponente koja se razvija ili modificira)
o Dekompozicijski pogled - WBS; razvojni pogled - veza između komponenti razvijenih na
različitim elementima sistemskog hardvera (klijent-server npr.); određivanje ponašanja -
sekvencijalno i konkurentno aktiviranje sistemskih komponenti; ...
o Male promjene zahtjeva na kontrolnim tačkama, povećan broj dizajnerskih ciljeva koji su
pretvoreni u tehničke specifikacije i povećan broj testnih scenarija u kontrolnim tačkama
je znak stabilnog projekta.
o Specifikacija dizajna arhitekture sistema postaje kontrolna tačka kada odgovarajući
sudionici zaključe da je veći dio specifikacije zadovoljio objektivne kriterije verifikacije i
validacije. Specifikacija također mora biti pripremljena u formi pogodnoj za
implementaciju i planiranje testiranja (razumljiva developerima i testerima).
• Mjerenje atributa implementacije softvera - implementacija softvera uključuje: detaljan dizajn
modula, kodiranje modula, dokumentaciju koda, integraciju modula u komponente, inspekciju
(peer-reviews + vođa tima, 2-4 osobe), pregled koda i testiranje od strane onih koji su ga razvili.
o nivo detalja zavisi od poznavanja poznavanja problema
o kodiranje npr. je li prioritet brzina ili memorija kod kodiranja?
o koliko modula je dizajnirano, kodirano, testirano u odnosu na estimirani broj (jedna
mjera)
o inspekcija najbolji način da se otkriju defekti u ranoj fazi (2-4 puta efikasnija od
testiranja)
Inspekcija (2 sedmice i 30-40 radnih sati za 4 člana) Pregled/prolaz

• Naći defekte • Komunicirati
• Treniranje učesnika • Nema treniranja
• Dodijeljene su uloge: moderator,čitatelj, snimatelj, • Nema uloga
developer
• Developer ne prezentuje
• Čuvaju se zapisi • Imena učesnika se
• Analiza rezultata obično ne bilježe
• Developer obično
prezentuje
• Tipično: 37 defekata na 1000 linija koda s brzinom • Ne čuvaju se zapisi
inspekcije od 150 linija koda po tim-satu (300 po inspekciji); • Nema analize
kod ubrzanja na 500 linija po tim-satu broj pronađenih rezultata
defekat pada na 10
• testiranje od strane developera treba validirati osobine i kvalitet atributa svakog modula:
iterativna metoda- prijašnja verzija softvera je jezgra za testiranje modula u razvoju, agilna
metoda - testovi se pišu prije koda. Testiranje se ne smije preskočiti nakon integracije modula!
• Mjera kompleksnosti softverskog koda - kompleksan softver je teško razumjeti,
dokumentovati, testirati, modifikovati i ponovo upotrijebiti. Najčešće korištene mjere su:
o ciklomatska kompleksnost - COCOMO complexiti cost driver (0.73 <= CPLX <= 1.47)
povezivanje i kohezija (od slabe do jake) - slaba povezanost i jaka kohezija je poželjna
kod softvera
• Ciklomatska kompleksnost - mjera iz teorije grafova koja u ovom slucaju predstavlja broj
linearno nezavisnih puteva kroz kod.
• C=E-N+2 = 13-10+2=5
• E - strelice (bez rubnih)
• N - čvorovi (crni čvorovi sadrže dijelove koda koji uključuju druge module)
• C > 10 (ili 12) - prekompleksni moduli (rule of thumb).
• Koristi se često prije i nakon modifikacije softvera da se spriječi rast kompleksnosti.
• Neki softverski sistemi su odbačeni jer su kroz niz modifikacija postali previše kompleksni.
• Ciklomatska kompleksnost dizajna grupe modula računa se kao kombinacija ciklomatskih

kompleksnosti pojedinih modula po formuli:
• DC(S)= ∑DC(Mj)-N+1
• N broj modula
• DC(S) > 40 (ili 50) prekompleksan, razbiti na manje

• Može se koristiti za određivanje broja testnih scenarija

• Neki razvojni alati imaju ovo mjerenje.
• Mjerenje integracije i verifikacije softverskih jedinica

o Waterfall - kolekcija komponenti za čitav sistem; integracija se radi na kraju razvojnog
procesa
o Iterativni- integracija se radi nakon svakog ciklusa
o Neka mjerenja su: broj modula koji je uspješno integrisan u odnosu na planirani za taj
period; defekti za svaku komponentu, podsistem i cijeli sistem; broj i procenat dizajn-
baziranih testova koji su zakazali tokom razmatranog perioda i kumulativno; vrijeme
potrebno za zatvaranje zahtjeva za promjenu i izvještaja o defektu predviđenih za
integraciju.
• Mjerenje sistemske verifikacije i validacije
o Verifikacija (ispravan, kompletan i konzistentan sistem s aspekta tehničkih specifikacija i
operacijskih mogućnosti) se radi obično u razvojnom okruženju
o Validacija (određivanje stepena s kojim je isporučeni sistem zadovoljio svoju namjeru) se
radi obično u operativnom okruženju i uključuje stvarne korisnike
o Neka mjerenja su: broj i procenat kvantitativnih i kvaitativnih testova koji su zakazali u
tom periodu i kumulativno; predviđanja za kompletiranje verifikacije i validacije; update
zahtjeva, dizajna, koda, integracijskih zahtjeva za promjenu i izvještaja o defektu i drugih
indikatora statusa
MJERENJE I ANALIZA SOFTVERSKIH DEFEKATA
• Defekti su greške nađene tokom kontolne tačke prihvatanja produkta ili nakon prolaska kontrolne
tačke
o Pravljenje softvera bez defekata nije moguće
• Zakazivanje softvera podrazumjeva nezadovoljavanje potreba korisnika, očekivanja korisnika ili
tehničkih specifikacija pri radu u operativnom okruženju i korištenju od strane korisnika (pad
sistema, poruka da je došlo do greške, netačni rezultati proračuna).
• Defekti u softveru nastaju usljed ljudske greške koja može biti:
o Greške propusta (ne radi sto bi trebalo)
o Greške povjerenja (radi nekompletno, netačno ili nekonzistentno)
• Većina grešaka nastaje radi problema u komunikaciji, koordinaciji, nedostatka znanja, vještina,
odgovarajućih alata i ljudske greške (npr. prekovremeni rad)
• Kada se otkrije defekat piše se izvještaj. Organizacija treba zadati ciljeve koji ukljucuju
zatvaranje defekata u određenom vremensom periodu zavisno od njihovog prioriteta
o npr. 24h za velike defekte., 3 dana za manje defekte i 5 dana za nezgodne defekte
• Može se voditi i evidencija o ukupnom broju otvorenih defekata pri čemu se posebno vode
novonastali defekti, te vremenski period koji su defekti otvoreni (npr. < 3 dana).
• datum otvaranja i zatvaranja defekta

• kratak opis defekta
• prioriteti obrade, brzina obrade
• faza u kojoj je napravljena greška i u kojoj je otkrivena greška koja je uzrokovala defekat
• broj radnih sati potrebnih za ispravku
• Matrica defekata je također jedan od načina da se mjeri uspješnost pojedinih faza projekta
• Oper.- defekti otkriveni od korisnika u prvih 6 mjeseci koristenja softvera.
• Broj defekata otkriven tokom faze vezane za zahtjeve je 50, tokom dizajna je 25 itd. Svega 50%
defekata je otkriveno u prvoj fazi. U fazi dizajna također 50% od preostalih defekata - poboljšati
• Korisnik otkriva 5% defekata tokom prvih 6 mjeseci rada na softveru (20/386).
• Kriterij prihvatanja implementiranog koda je svega 53% (pronađeno je svega 80 od 150
implementacijskih defekata tokom implementacijskih aktivnosti. 7% implementacijskih defekata
se provuče kroz razvojni proces (10 od 150)
• Moglo bi se pokazati da od 60 defekata u fazi dizajna, njih 40 su posljedica 25 defekata koji nisu
otkriveni u fazi za zahtjeve, a preostalih 20 su kreirani tokom faze dizajna.
• Ove evidencije omogućavaju identifikaciu oblasti koje treba popraviti.
• Ukoliko se pronađe 70% defekata kod zahtjeva u svakoj od 5 razvojnih faza, tada korisniku
preostaje da nađe svega 1-(1-0.36 )*100=0.073% ovih defekata u prvih 6 mjeseci korištenja
softvera. 0.24% dizajnerskih defekata i 0.81% implementacijskih defekata se u ovom slučaju
provuku do krajnjeg korisnika.
• Ne očekuje se 100% pronalazak defekata do kontrolne tačke ali je nekih 70%-80% razuman
zahtjev za kvalitetni razvoj softvera.
• Ova analiza je bazirana na Waterfall razvojnom procesu. Kod iterativnog razvojnog procesa
očekuju se bolji rezultati.
• Većina problema na koje se nailazi u razvoju softvera nastaje jer je premalo vremena i
napora uloženo u zahtjeve i dizajn - ovim fazama se treba ozbiljno posvetiti
• Nije moguće detaljno pratiti sve zahtjeve vec treba da se odrede oni koji su esencijalni i da
im se posveti najvise pažnje.
• Šta se mjeri zavisi od cilja koji se želi postići, tj. Koji se atributi trebaju pratiti da bi se
moglo procijeniti je li cilj dostignut ili ne (npr. smanjiti broj defekata tokom razvoja
softvera)
MJERENJE I KONTROLA PROCESA

• Svaki softverski projekat mjeri i kontoliše sljedeće atribute: napor, vrijeme, trošak i progres.
o Šta nam govori procenat napora utrosen na mjerenje i kontrolu atributa projekta?
▪ 5-10% je uobicajeno
o Šta nam govori odstupanje od planiranog napora i troskova za neku fazu u projektu?
▪ nedovoljno ili prevelikio znanje učesnika,pretežak ili prelagan posao, ubrzavanje
projekta
o Nisu dobra velika odstupanja ni u pozitivnom ni u negativnom smjeru, jer to znaci da
nesto nije dobro procjenjeno, sem u slučaju da ima neko logicno opravdanje za to
odstupanje.
o Paziti kako se koriguju odstupanja:
▪ Produzetak vremena, dodavanje resursa, koristenje superiornijih resursa,
poboljsanje razvojnog procesa, smanjivanje zahtjeva
▪ Ne ici na predug prekovremeni rad, redukciju ili eliminaciju verifikacije,
validacije, dokumentacije, aktivnosti koje uticu na kvalitet
MJERENJE I ANALIZA NAPORA

• Tri su kategorije napora:
o Orginalni rad
o Evolucijska dorada (rework)
o Dorada koja se može izbjeći
• Retrospektivna dorada - vezana je za metodu razvoja
• Korektivna dorada - vezana je za ljudsku grešku
• Npr. Evolucijska dorada je uključivanje novih zahtjeva koji nisu mogli biti predviđeni u
prethodnoj iteraciji; retrospektivna dorada je uključivanje zahtjeva koji su mogli da budu
uključeni u prethodnoj iteraciji; korektivna dorada u iterativnom razvojnom procesu je dorada
nakon otkrivanja grešaka u revidiranom, testiranom i prihvaćenom produktu.
• Često se ne prati procenat pojedinih kategorija napora. Dorade koje se mogu izbjeći trebaju
predstavljati najviše 20% , ali često u organizacijama čine i 50% totalnog napora.
Taksomanija napora:
• Originalni rad
• Dorada
o Evolucijska
o Može se izbjeći
▪ Retrospektivna
▪ korektivna
MJERENJE I ANALIZA NAPORA KOD DORADE
o Količina napora za svaku od kategorija se mjeri praćenjem:

• Radnih paketa iz WBS (originalni napor)
• Napor uzrokovan promjenom zahtjeva (evoluciona dorada)
• Napor uzrokovan izvještajima za defekte (retrospektivna i korektivna dorada)
o Matrica dorade je slična matrici defekata. Dat je primjer matrice hipotetičkog ali realnog
softverskog produkta tokom njegovog razvoja i prvih 12 mjeseci korištenja. Vrijednosti
predstavljaju broj inžinjer-sati (povezana je sa prethodnom matricom).
• Potrebno je dosta napora za doradu defekata na zahtjevima koji nisu pronađeni u fazi
vezanoj za zahtjejve (1038-200: ~ 80%).
• 3 defekta nađena od korisnika zahtijevaju više napora od 50 defekata pronađenih tokom
revizije zahtjeva (300 naspram 200 inžinjer-sati).
• Najviše napora kod dorade ide na defekte koje je našao korisnik (2001/6863, 29%). Ako
bi jedan mjesec imao 152 inžinjer-sata i radna godina 11 inžinjer-mjeseci, tada bi trebalo
2001/)11*152) ~ 1,2 inžinjera za korekciju defekata tokom prve godine.
o Drugi način za određivanje napora dorade može se bazirati na matrici defekata (prva matrica) i
eksponencijalnom modelu dorade kao što je prikazan na narednom dijagramu.
• Dijagram je normaliziran na 1 inžinjer-sat za popravku defekta koji je pronađen u dijelu
za zahtjeve (samo dio dijagrama).
• Mnoge organizacije prijavljuju i veći eksponencijalni rast napora pri popravljanju
defekata.
• Treba gledati historijske podatke organizacije za kreiranje dijagrama relativnog napora.
• Sa dijagrama se vidi da ukoliko trebaju 4 inžinjer-sata za popravku defekta u fazi zatjeva,
onda treba 4*25 = 100 inžinjer-sati za popravku tog istog defekta ako ga otkrije korisnik.
o Tabela ispod i matrica defekata se koriste za kreiranje matrice dorade. Uzeto je u primjeru da
trebaju
• 4 inžinjer-sata za popravku defekta u dijelu za zahtjeve tokom faze za zahtjeve
• 6 inžinjer-sata za popravku dizajnerskog defekta u fazi dizajna
• 10 inžinjer-sata za popravku implementacijskog defekta u fazi implementacije,
verifikacijskog defekta u fazi verifikacije i validacijskog defekta u fazi validacije
PRAĆENJE NAPORA, VREMENA I TROŠKOVA; ESTIMACIJA BUDUĆIH STATUSA
o Binarno praćenje – osnovna tehnika za tačno praćenje statusa projekta (binary deliverables –
Tom Demarco).
• Task (radni paket originalnog rada, promjena zahtjeva ili prijava defekta) smatra se 0%
završenom dok s njim povezan produkt ne zadovolji kriterij prihvatanja, tj. dok nije
100% završen.
• Binarno praćenje pomaže da se izbjegne 95% sindrom završetka softverskog projekta
(napredak praćenje koristeći „nagađanje vremena“ često rezultuje projektima koji su
prijavljeni kao 95% završeni dugi vremenski period).
▪ Bolje imati 100% završeno 90% od ukupnog posla i znati da je to istina, nego misliti
da je završeno 90% od ukupnog posla i nadati se da je to istina.
• Korektivne akcije se poduzimaju najkasnije dva mjeseca od početka projekta.
• Naredna slika prikazuje binarno praćenje radnih paketa preko WBS. Za detaljnije
praćenje treba poboljšati dekompoziciju WBS (razbiti na manje taskove).
o Samo se listovi proglašavaju 0% ili 100% završeni dok se ostali dijelovi stabla računaju na
osnovu njih pod pretpostavkom da svaki task zahtijeva jednak napor.
o Ne ulaziti u prevelike detalje da taskovi postanu manji od 1 inžinjer-sedmice s aspekta kontrole i
mjerenja (programeri mogu raditi s više detalja samostalno praveći vlastite detaljnije WBS).
Najveći napor treba biti 1 inžinjer-mjesec.
Estimacija budućeg statusa – također na bazi binarnog praćenja

o Iz prethodne 2 tabele vidi se da je od 17% posla završeno 90% (dizajn arhitekture) itd.
o Ukupni procenat projekta koji je završen je:
(90 * 0.17) + (75 * 0.26) + (50 * 0.35) + (20 * 0.10) + (14 * 0.12) = 56%
o Na osnovu ovoga se može procijeniti koliko još inžinjer-mjeseci treba za završetak projekta i
povećati broj učesnika ako je to potrebno, ali paziti na Brookov zakon.
o 56% ne mora biti tačan podatak. Preostalih 30 zahtjeva mogu biti najlakši ili najteži zahtjevi.
Radi toga treba voditi računa da se uradi dekompozicija svakog zahtjeva dok se ne:
• otkrije kompleksnost i faktor rizika
• identificiraju mogućnosti ponovnog korištenja
• estimira napor za implementaciju zahtjeva (može se koristiti i težinski faktor npr. 1-5)
IZVJEŠTAVANJE O ZARAĐENOJ VRIJEDNOSTI
o Izvještavanje o zarađenoj vrijednosti (earned value reporting ili EV) – dobija se na osnovu
binarnog praćenja paketa originalnog rada, promjene zahtjeva evolucione dorade i prijave
defekata dorade koja se mogla izbjeći (retrospektivne i korektivne).
o EV pristup za prijavu završetka paketa (slično je za izmjenu zahtjeva i prijavu defekata):
• Koristeći rolling-wave pristup specificirati planirane troškove i trajanja svakog taska u
paketu koji će biti završen u narednom mjesecu
• Kada je završen task dodijeliti mu planirane troškove (napor+ostali troškovi) kao njegovu
„zarađenu vrijednost EV“ (EV je planirani trošak koji se „dobija unazad“ kada se task
završi)
• Za sve taskove završene do roka uporediti sumu EV (planirani trošak za sve taskove) sa
sumom stvarnih troškova (pokazatelj prekoračenja budžeta)
• Za sve taskove završene u roku uporediti broj taskova koji je trebao biti završen s brojem
završenih (pokazatelj je li vremenski plan ugrožen)
o Terminologija zarađene vrijednosti
• BCWP (Budget Cost of Work Performed) – Kumulativni iznos budžeta za sve taskove
završene do roka (zarađena vrijednost EV)
• ACWP (Actual Cost of Work Performed) – Stvarni troškovi svih završenih taskova
• BCWS (Budget Cost of Work Scheduled) – Planirani troškovi svih taskova pokrenutih da
budu završeni do roka
• BAC (Budget Actual Cost) – Planirani troškovi čitavog projekta
• SCD (Scheduled Completion Date) – Planirani datum završetka projekta
• EAC (Estimated Actual Cost) – Estimirani stvarni troškovi projekta na osnovu
dosadašnjeg progresa
• ECD (Estimated Completion Date) – Estimirani datum završetka na osnovu dosadašnjeg
progresa
• CV (Cost Variance) – CV = ACWP – BCWP
• SV (Schedule Variance) – SV = BCWS – BCWP
• CPI (Cost Performance Index) – CPI = ACWP / BCWP (CPI = BCWP/ACWP)
• SPI (Schedule Performance Index) – SPI = BCWS / BCWP (SPI = BCWP/BCWS)
• CVC (Cost Variance at Completion) – CVC = EAC – BAC
• SVC (Schedule Variance at Completion) – SVC = ECD – SCD
pri čemu je EAC = BAC *CPI i ECD = SCD * SPI (EAC=BAC/CPI i ECD=SCD/SPI)
Značenje nekih vrijednosti
o CPI < 1 i SPI<1 projekat ispod predviđenog budžeta i vremenskog plana

o U slučaju invertovanih formula ovo bi značilo da je projekat iznat predviđenog budžeta i da
vremenski kasni.
o CPI i SPI variraju tokom različitih perioda (EAC i EDC također). Kod projekta koj dobro
napreduje ACWP i BCWP linije su blizu BCWS linije.
o Primjer EV praćenja: Završena su prva 3 mjeseca projekta koji traje 12 mjeseci. Planirani
budžet je 500 000 EUR. Po projektnom planu treba potrošiti 40 000 EUR u prva tri mjeseca
projekta, kumulativni trošak je 50 000 EUR, a stvarni 60 000 EUR. Šta se može reći o statusu
ovog projekta nakon 3 mjeseca?
SCD = 12 mjeseci
BAC = 500 000 EUR
BCWP = 50 000 EUR
BCWS = 40 000 EUR
ACWP = 60 000 EUR
CPI = 60 000 EUR / 50 000 EUR = 1,2
SPI = 40 000 EUR / 50 000 EUR = 0,8
EAC = 500 000 EUR * 1,2 = 600 000
ECD = 12 * 0,8 = 9,6 mjeseci
Projekat je iznad predviđenog budžeta ali se izvršava brže nego što je predviđeno.
Estimirani stvarni troškovi u ovom trenutku su 600 000 EUR umjesto 500 000 EUR
planiranog budžeta.
Estimacija vremena pokazuje da će biti potrebno 9,6 mjeseci da se projekat završi u

odnosu na 12 planiranih mjeseci.
o EV izvještaji su koncizan način za prezentiranje:

• Tekućeg statusa troškova (napor + drugi troškovi), vremenskog plana i progresa na
produktima
• Trendova tokom vremena
• Trenutne estimacije (npr. mjesečne) finalnih troškova (EAC) i datuma isporuke sistema
(ECD) bazirane na trenutnom statusu projekta
o Binarno praćenje osigurava precizno mjerenje završenih projekata
o Da bi EV izvještavanje bilo efektivno mora se precizno podnositi izvještaj o uloženom naporu i
vremenu
• Za razvoj softvera to bi bilo svaka 2h ili 4h
• Članovi tima ne bi trebali prijavljivati rad na previše zasebnih zadataka (optimum je 2-4
zadatka dnevno, u suprotnom projekat nije dobro organizovan ako je dnevni broj
zadataka često veći)
ORGANIZACIJA SOFTVERSKOG PROJEKTA
(SOFTWARE PROJECT ORGANIZATION, ETF RIO OSP I-3650)
Vanr.prof.dr Samir Omanović, dipl.ing.el.

PREDAVANJE 09 – Upravljanje promjenama softvera
Maj 2021
UPRAVLJANJE PROMJENAMA SOFTVERA
 Konfiguracija je skup karakteristika koje definišu softverski
proizvod, što uključuje sve funkcionalne i nefunkcionalne
specifikacije proizvoda.
šk.god.2020/2021
Organizacija softverskog projekta,
 Software Configuration Management (SCM) je proces
sistematičnog upravljanja promjenama, organizovanja promjena i
kontrole promjena u dokumentima, kôdu i drugim proizvodima rada
tokom životnog ciklusa razvoja softvera, s ciljem da se maksimizira
produktivnost i minimiziraju greške.
 Neki od razloga zašto organizacija treba SCM su:
 Više ljudi radi na softveru koji se stalno mijenja. Važna je sljedivost.
 Može se desiti da postoji više verzija, grana i autora softvera, da oni rade
možda geografski distribuirano i konkurentno.
 Mogu se desiti promjene specifikacije zahtjeva, promjene budžeta
projekta, promjene politika, promjene rasporeda projekta i sl. i svemu
tome se treba prilagoditi.
 Softver se izvršava na različitim platformama.
 SCM omogućava koordinaciju među zainteresiranim stranama. 2
 SCM je koristan u kontroli troškova mijenjanja softverskog sistema.
Promjene Promjene
zahtjeva politika i pravila
šk.god.2020/2021
Promjene u Promjene u
timovima rasporedu ili
(organizaciji) budžetu
Svaka promjena stavki
konfiguracije softvera
utiče na
utiče na finalni proizvod,
zbog čega je važno iste
kontrolisati.
3
Kôd Planovi Razni Testovi Podaci
dokumenti
 Softverski sistemi se stalno mijenjaju i tokom razvoja i tokom
upotrebe, zbog:
 otkrivenih nedostataka,
zahtjeva za promjenama,
šk.god.2020/2021

 novog okruženja – platforme na kojoj treba raditi,
 uvođenja novih funkcionalnosti zbog kompetitivnih prednosti,
 i td.
 Upravljanje konfiguracijom softvera (software
configuration management – SCM) je vezano za procese, politike,
i alate za upravljanje promjenama softverskog sistema.
 Zbog dinamike razvoja softvera se često dešava da se promjene
vrše na nekoliko verzija istovremeno i rad na pogrešnoj
verziji ili gubitak izvornog koda verzije može imati velike
negativne posljedice.
 Upotreba sistema za upravljanje konfiguracijom osigurava da
učesnici imaju informaciju o sistemu koji se trenutno razvija da
bi na taj način izbjegli opasnost da se međusobno
preklapaju/ometaju u radu. 4
Period razvoja
i testiranja
AKTIVNOSTI UPRAVLJANJA Razvojne vrezije

softvera
KONFIGURACIJOM
(dnevni build)
PRE-ALFA
Prijedlozi ALFA ver.

promjena
BETA ver.
šk.god.2020/2021
Izgradnja Upravljanje Kandidat za release
(izdanje)
sistema promjenama GAMA/DELTA/...
(build)
Spreman za
isporuku - RTM
Release to
Release-i Manufacturing
Verzije Verzije
(izdanja) /Marketing
komponenti sistema
sistema Komercijalno
dostupan - GA
General Avaliability
U upotrebi –
Upravljanje Upravljanje finalna verzija
GOLD 5
verzijama release-ima
Period izdanja
AKTIVNOSTI UPRAVLJANJA
KONFIGURACIJOM
 Upravljanje promjenama (change management) je vezano za praćenje
zahtjeva za promjenama softvera od strane klijenta (naručioca) i
inžinjera razvoja. Ovdje se određuju cijena i uticaj (posljedica
promjene), te donosi odluka da li će se izvršiti promjena i kada.
šk.god.2020/2021
 Upravljanje verzijama (version management) je vezano za praćenje
više verzija komponenti sistema te osiguravanje da se promjene koje
različiti inžinjeri razvoja vrše ne preklapaju.
 Izgradnja sistema (system building) je proces spajanja komponenti
sistema (compiling and linking) i kreiranja izvršne verzije sistema
(executable).
 Upravljanje izdanjima (release management) je pripremanje softvera
za isporuku krajnjim korisnicima, i praćenje verzija koje su isporučene
krajnjim korisnicima.
 Standard IEEE 828-2012 (http://ieeexplore.ieee.org/document/6170935/)
je standard koji određuje minimalne potrebe za upravljanje
konfiguracijom. Ovaj standard se fokusira na procese upravljanja
konfiguracijom i dokumente koji nastaju u tim procesima.
 Standard ANSI/EIA-649-B (MIL–HDBK–61B; http://www.product-
lifecycle-management.com/download/mil-hdbk-61b%20(draft).pdf)
definiše terminologiju i proces CM. 6
KONFIGURACIJOM
 Ključne funkcije su:
 Planiranje i upravljanje životnim ciklusom SCM –
izrada formalnog dokumenta i plana kojim se vodi SCM.
Uključuje stavke kao što su: osoblje, odgovornosti, resursi,
šk.god.2020/2021
trening, definicije, procedure, alate, revizije, kontrole, ...
 Identifikacija konfiguracije – uspostava i održavanje
osnovnih postavki kojima se definiše arhitektura sistema i
njegovih podsistema, komponenti i td. To je osnova za
identifikaciju, dokumentaciju i praćenje promjena kroz
dizajn, razvoj, testiranje i isporuku.
 Kontrola konfiguracije – uključuje evaluaciju
odobravanje/neodobravanje svih prijedloga i zahtjeva za
promjenama. Pokriva proces kontrole izmjena dizajna,
hardvera, firmvera, softvera i dokumentacije.
 Evidencija statusa konfiguracije – uljučuje procese
evidentiranja i izvještavanja vezanog za stavke konfiguracije
(hardver, softver, ...) i sva odstupanja od identificirane
konfiguracije. To olakšava pronalaženje uzroka u slučaju 7
problema.
KONFIGURACIJOM
 Verifikacija i audit konfiguracije – nezavisna revizija
hardvera i softvera koja ima za cilj da provjeri usklađenost
konfiguracije sa postavljenim zahtjevima, standardima i
šk.god.2020/2021
identificiranom konfiguracijom.
 Upravljanje podacima – treba da uspostavi vezu između
SCM i upravljanja podacima (DM) jer su danas skoro svi
podaci digitalnog oblika i SCM mora uzeti u obzir i DM,
odnosno praćenje podataka (dokumenata) kroz njihov životni
vijek.
8
AKTIVNOSTI UPRAVLJANJA KONFIGURACIJOM
šk.god.2020/2021
9
http://www.product-lifecycle-management.com/download/mil-hdbk-61b%20(draft).pdf
SCM uloge
• Glavni odgovorni • Odgovoran je za održavanje
za identifikaciju konfiguracije kôda
stavki konfiguracije • Mijenja kôd tokom
šk.god.2020/2021
• Brine da tim slijedi standardnih razvojnih
SCM proces. aktivnosti ili na zahtjev za
• Odobrava ili odbija promjenu.
zahtjeve za • Provjerava promjene i
• Nadzire
izmjenama rješava eventualne konflikte.
napredak razvoj i
detektuje
probleme u SCM
procesu.
• Brine se da se
poštuju i slijede • Treba razumjeti
procedure i osnove SCM proces-a
politike vezane za kako bi znao ima li
kreiranje, zadnju verziju
mijenjanje i softvera.
testiranje.
• ...
10
OSNOVNI TERMINI
UPRAVLJANJA KONFIGURACIJOM
 Stavka konfiguracije (software configuration item – SCI) je svaki
element softvera (dizajn, kod, testni podaci, dokument, i sl.) koji je
stavljen pod kontrolu konfiguracije. Stavka konfiguracije mora imati
jedinstveno ime (identifikaciju).
šk.god.2020/2021
 Kontrola konfiguracije (configuration control) je proces koji
osigurava evidentiranje verzija sistema i komponenti, i sačuvavanje
svih verzija komponenti tokom postojanja sistema.
 Verzija (version) je instanca stavke konfiguracije koja se po nečemu
razlikuje od ostalih instanci te iste stavke konfiguracije. Verzija uvijek
ima jedinstveni identifikator – najčešće naziv stavke konfiguracije +
broj verzije.
 Odobrena konfiguracija sistema (baseline) je skup verzija
komponenti koje čine sistem kao cjelinu. Treba da je uvijek moguće
ponovo formirati odobrenu konfiguraciju sistema od komponenti koje je
sačinjavaju. Zbog toga se vrši kontrola odobrenih konfiguracija sistema.
 Sekvenca odobrenih verzija koda (codeline) je skup verzija jedne
softverske komponente i ostalih stavki konfiguracije o kojima ovisi. Ovo
je važno kontrolisati zbog praćenja uticaja promjena.
 Sekvenca odobrenih konfiguracija sistema (mainline) – skup
(sekvenca) svih odobrenih konfiguracija sistema (baseline) koje 11
predstavljaju različite verzije sistema.
OSNOVNI TERMINI
UPRAVLJANJA KONFIGURACIJOM
 Izdanje/isporuka (release) je verzija sistema koja je
isporučena klijentu.
 Radni prostor (workspace) je zaštićeni radni prostor u kome
šk.god.2020/2021
je moguće raditi promjene softvera bez opasnosti da će to
uticati na rad ostalih koji koriste ili modifikuju taj softver.
 Grana koda (branching) predstavlja kreiranje odobrene
konfiguracije koda iz postojeće. Nova odobrena konfiguracija
koda i postojeća se nakon toga razvijaju nezavisno jedna o
drugoj.
 Spajanje (merging) je spajanje različitih odobrenih
konfiguracija koda (codelines) radi kreiranja nove verzije
komponente softvera.
 Izgradnja sistema (system building) je formiranje izvršne
verzije (executable) kompajliranjem i linkovanjem
odgovorajućih verzija komponenti i biblioteka koje čine 12
sistem.
PROCES UPRAVLJANJA PROMJENAMA
 Zahtjevi za promjenama su uobičajeni događaji u životu
jednog softverskog proizvoda.
Da bi se uspješno odgovorilo na ovakve događaje potrebno je
šk.god.2020/2021

imati definisan proces upravljanja promjenama i skup alata
koji olakšavaju izvršenje tog procesa.
 Cilj upravljanja promjenama je osigurati najbolji proces
evolucije softvera (najprioritetnije promjene, najpovoljniji
omjer trošak/korist).
13
PRIMJER MODELA
PROCESA UPRAVLJANJA PROMJENAMA
Učešće Podrška korisniku
klijenta u
odlučivanju! PROVJERA
Klijent zahtjeva za
promjenom
Podnošenja
zahtjeva za Nevalidan Validan
promjenom
šk.god.2020/2021
Razvoj proizvoda ZATVARANJE REGISTROVANJE
zahtjeva za zahtjeva za
(Odbor za kontrolu ZAHTJEVI ZA promjenom promjenom
promjena) PROMJENAMA
PROCJENA Razvoj softvera

zahtjeva za
promjenama ANALIZA
implementacije
ANALIZA
IZBOR zahtjeva uticaja i cijene
za promjenama
koji se realizuju
MODIFIKACIJA Neuspješno
softvera
TESTIRANJE
ZATVARANJE
softvera 14
zahtjeva za
ZATVARANJE
promjenama koji
zahtjeva za
se ne realizuju Uspješno
promjenom
PRIMJER IZVRŠENJA
ZAHTJEV KORISNIKA
Broj zahtjeva: #11326

Naziv projekta: ETF Sarajevo, ERP Naziv komponente: ERP/Nalog za knj.
šk.god.2020/2021
Prioritet: Visok Željeni datum isporuke: 01.12.2012
Naziv: Automatsko kreiranje storno naloga
Opis: Potrebno je napraviti funkcionalnost automatskog kreiranja storno
naloga na osnovu postojećeg naloga.
Potrebno prihvaćanje: Da Broj zahtjeva iz vanjskog sistema: 56/12
Kriteriji prihvaćanja: -
Inicijator zahtjeva: Faris O.

Podnositelj zahtjeva: Tarik O. Voditelj projekta korisnika: Tarik O.
Datum podnošenja: 14.10.2012 11:15:15
Status: Zahtjev podnesen
Prilozi: 15
Dokument sa primjerom naloga knjiženja i storno naloga knjiženja

PRIMJER IZVRŠENJA
 Kada korisnik podnese zahtjev vrši se provjera a zatim PRIHVAĆANJE ili
ODBIJANJE.
 Prilikom prihvaćanja se određuje tip podnesene prijave (Incident – uočeni
nedostatak softvera ili Promjena – nova funkcionalnost ili modifikacija
šk.god.2020/2021
postojeće), određuje se da li je naplativo ili nije i dodjeljuje se nekom od
Rješavatelja – osoba određenih za izvršenje zahtjeva. Pri tome se mogu
unijeti i dodatna polja koja mogu pomoći rješavanje zahtjeva.
 Rješavatelj će sam ili uz pomoć saradnika izvršiti analizu zahtjeva (kako ga
realizovati, koje su posljedice i koja je procjena potrebnog rada). Na osnovu
toga će popuniti polja kao npr:
 Rezultati analize: Zahtjev se može realizovati. Pri tome treba imati u vidu da su
procedure vezane za temeljnicu smještene u paketu procedura TEM. Dodavanje ove
funkcionalnosti ne remeti rad ostalih funkcionalnosti. Voditi računa da se prava za
storniranje dodijele posebnoj roli jer ova funkcionalnost iziskuje nadzor izvršenja.
Bilježiti u log svako izvršenje
 Opis rješenja: Na formi TEMELJNICA bi se dodalo dugme Storno naloga. Klikom na to
dugme bi se pozivala procedura TEM.STORNO_NALOGA i proslijedio parametar
Broj_naloga_za_storno. Kreirala bi se tabela STORNO_NALOZI_LOG u kojoj bi se
bilježili podaci o tome koji korisnik, za koji nalog i kada je pokrenuo kreiranje storno
naloga. Kreirala bi se rola STORNO_NAL ... 16
 Procjena potrebnog vremena: 16:00 (inžinjer sati)
 Planirani datum isporuke: 21.10.2012
PRIMJER IZVRŠENJA
 Na osnovu kreiranog opisa i procjene Klijent vrši analizu da li prihvatiti ili
odbiti zahtjev (cost/benefit).
 Ako klijent prihvati zahtjev onda se njegov status mijenja u PRIHVAĆEN,
a ako ne prihvati onda se status može promijeniti u OTKAZAN ili se može
šk.god.2020/2021
vršiti dopuna zahtjeva i druge izmjene.
 Kada Rješavatelj dobije obavijest (mail notifikaciju) da je zahtjev prihvaćen
tada ulazi u realizaciju istog. Pri tome u prilogu zahtjeva (kao zabilješku,
ili dokument prilog i sl.) bilježi sve što je potrebno za uspješnu realizaciju
zahtjeva, uključujući i korespondenciju s Klijentom. Prilikom realizacije
zahtjeva Rješavatelj troši vrijeme, o čemu vodi zabilješku uz zahtjev.
Obično se unosi utrošeno vrijeme, interno (planirano) utrošeno
vrijeme, razlog (šta je rađeno), kategorija posla i sl.
 Nakon što Rješavatelj završi izmjenu softvera i uspješno je testira,
priprema isporuku korisniku (koje komponente i koje verzije se
postavljaju i na koji način) te istu postavlja kod korisnika ili predaje
korisniku da je sam postavi (zavisi od Ugovora).
 Prilikom pripreme isporuke se u poljima koja opisuju izvršenje zahtjeva
bilježi npr: koje komponente se isporučuju, kako se instaliraju i sl.
17
 Prilikom isporuke se bilježi datum i vrijeme isporuke ta ostale bitne stvari.
PRIMJER IZVRŠENJA
 Nakon isporuke se neko vrijeme čeka da povratnu informaciju od strane
korisnika – rok za validaciju i primjedbe od strane korisnika.
 Ukoliko nema primjedbi od strane korisnika ili korisnik potvrdi uspješnu
validaciju onda se zahtjev ZATVARA. Pri tome se bilježi datum
šk.god.2020/2021
zatvaranja. Zatvaranjem zahtjeva se daje signal da se isti može fakturisati
Klijentu, odnosno naplatiti od njega. Faktura glasi na uslugu
modifikacije softvera po zahtjevu #broj, količina je broj procijenjenih
sati a cijena sata je određena posebnim Ugovorom.
 PRETHODNO OPISANO JE PRILIČNO IDEALAN PRIMJER

IZVRŠENJA PROCESA UPRAVLJANJA PROMJENAMA. Uvijek
mogu nastupiti situacije koje iziskuju posebnu podproceduru. Npr. može
se desiti da utrošeno vrijeme realizacije znatno odstupa od procjene (loša
procjena; manja odstupanja se tolerišu) što iziskuje ponovno pregovaranje s
Klijentom – izradu nove procjene, analizu Klijenta i odobravanje Klijenta.
 Generalno, zahtjev treba da prolazi kroz stanja (PRIJAVLJEN,
PRIHVAĆEN, PROCJENA ZAVRŠENA, ODOBRENA PROCJENA, ...) i u 18
okviru sebe treba da sadrži sve što je vezano za taj zahtjev.
 Dešava se da se postave dupli zahtjevi ili da jedan zahtjev obuhvata
funkcionalnosti zahtijevane u drugom zahtjevu. Ovakvi dupli zahtjevi se
odbacuju.
Dešava se prijava nedostatka softvera koja je već prijavljena ili možda čak i
šk.god.2020/2021

riješena.
 Dešava se prijava nedostatka softvera zbog nedovoljnog poznavanja
upotrebe softvera, odnosno pogrešnog razumijevanja raspoloživih
funkcionalnosti.
 Ponekad postoje funkcionalnosti koje nisu dokumentovane pa ih korisnik
vidi kao nedostatak softvera. It's not a bug; it's an undocumented
feature!
 Ponekad je izmjena kritična i može dovesti do zaustavljanja rada
sistema. Zbog toga se takve isporuke puštaju u produkciju s velikim
oprezom (procijeniti rizik po poslovanje) i naravno planski – sačuvati
prethodno stanje, uraditi to u vrijeme poslovne nekativnosti Klijenta
(vikend npr.) da bi se u slučaju neuspjeha moglo vratiti staro stanje, i sl.
19
 Prilikom promjena voditi računa i o ciklusima (iteracijama) izgradnje
softvera.
 Ukoliko se radi o upravljanju promjenama na softveru koji
je generalne namjene (npr. CAD softver) onda uključenost
Klijenta nema uticaja na donošenje odluka, nego se odluke
donose na bazi marketinških analiza, preporuka inžinjera u
šk.god.2020/2021
timu i sl.
 U ovakvim slučajevima se proces može znatno pojednostaviti da
se ne gubi puno vremena na administriranje zahtjeva.
 U agilnim metodama je uključenost klijenta velika pa i u

procesu upravljanja promjenama. Npr. u ekstremnom
programiranju je klijent uključen i u analizu uticaja zahtjeva za
promjenom na ostale dijelove sistema i sl.
 Sve promjene se moraju bilježiti. Mora se čuvati istorija
promjena svake komponente. 20
 SCM alati bi trebali imati sljedeće karakteristike:
 Paralelizam, koji omogućava rad više korisnika na istom fajlu.
 Kontrolu verzija, koja omogućava čuvanje i praćenje svih izmjena te
šk.god.2020/2021
vraćanje na prethodnu verziju ako iz nekog razloga promjene nisu
prihvaćene.
 Sinhronizaciju, koja omogućava da korisnik ima sinhroniziranu
lokalnu kopiju kako bi lokalno imao uključene i promjene koje
prave drugi korisnici.
 Popularni alati su:
 Git – besplatni i open-source alat za kontrolu verzija.
 Team Foundation Server – grupa alata i tehnologija koje
omogućavaju koordinaciju i kolaboraciju tima u izgradnji proizvoda.
 Ansible – je alat otvorenog kôda koji pored upravljanja
konfiguracijom nudi i mogućnosti vezane za automatizaciju
isporuke i drugih zadataka. 21
 ... Desktop Central, CFEngine, Puppet, Spinnaker, ...
UPRAVLJANJE VERZIJAMA
 Upravljanje verzijama (version management –VM) je proces praćenja
različitih verzija softverskih komponenti ili konfiguracijskih stavki, te
sistema u kojima su te komponente ugrađene.
Osim toga se osigurava i da se izmjene koje se vrše paralelno
šk.god.2020/2021

međusobno ne preklapaju.
 U osnovi se na upravljanje verzijama može gledati kao na upravljanje
sekvencom odobrenih verzija kôda (codeline) i odobrenim konfiguracijama
sistema (baseline).
 Baseline se može specificirati kroz konfiguraciju sistema. Npr. navede se
tačna verzija kôda – X.1.2 ili samo identifikator komponente (X). Ako se
navede samo identifikator komponente onda se misli na zadnju validnu
verziju.
 Za upravljanje verzijama se koriste alati kao npr. CVS (open-source) ili
Subversion (open-source) ili Serena PVCS Version Manager (komercijalni).
 Alati za upravljanje verzijama osiguravaju sljedeće funkcionalnosti:
identifikaciju verzija i release-a, upravljanje pohranjivanjem, vođenje 22
istorije promjena, istovremeno mijenjanje komponente, podrška projektima
koji dijele komponente, ...
Codeline (A) Baseline – V1
A A 1.1 A 1.2 A 1.3 A 1.1 B 1.2 C 1.2
šk.god.2020/2021
L1 L2 Ex1
Codeline (B)
B B 1.1 B 1.2 B 1.3

Baseline – V2
A 1.2 B 1.2 C 1.3

Codeline (C)
C C 1.1 C 1.2 C 1.3 L1 L2 Ex2
Biblioteke i vanjske komponente Mainline
L1 L2 Ex1 Ex2
23
Datum kreiranja
Sekvenca verzija
šk.god.2020/2021
Verzija Verzija Verzija Verzija
1.0 1.1 1.2 1.3
Tekuća
(zadnja)
verzija
V1.3
D1 D2 D3 izvorni kôd
Struktura pohranjivanja
Pohranjivanje na bazi razlika (delta – D). Za više informacija 24

oko načina formiranja delti pogledati literaturu vezanu za
“delta encoding”
UPRAVLJANJE VERZIJAMA SAMIR
Sistem za upravljanje verzijama Workspace (U1)

check_in
A A 1.1 A 1.2 A 1.3 A
check_out B
šk.god.2020/2021
C
B B 1.1 B 1.2
EMIR
C C 1.1 C 1.2 C 1.3
Workspace (U2)
check_in
P P 1.1 P 1.2 X
check_out Y
Q Q 1.1 C
Primjer: Dvije osobe istovremeno mijenjaju komponentu C. Prva
osoba koja uzme komponentu C će uraditi check_out. Kada druga
X X 1.1 X 1.2 osoba zatraži tu komponentu sistem će je upozoriti da je već uzeta
komponenta. Ako korisnik ipak želi tu komponentu može je dobiti ali
će izmjene na njoj predstavljati odvojenu granu u odnosu na 25verziju
koju će vratiti prva osoba. Nakon što se uradi check_in, obje verzije
Y Y 1.1 komponente C će postojati u odvojenim granama. Naravno, uvijek se
može sačekati da se komponenta oslobodi i da ne dođe do formiranja
grane – zavisi šta se želi.
Moguće je npr. da su osobe iz prethodnog primjera formirale TAG (LABEL):
istovremeno dvije verzije (V2.1.1 i V2.2) i napravile novu
granu a da su radile na različitim dijelovima koda iste
Neke verzije koda
komponente (njihovi dijelovi koda se ne preklapaju). Nakon se mogu označiti iz
toga (odmah ili nakon još nekoliko verzija u odvojenim određenog razloga.
granama) se može izvršiti spajanje i ukinuti nepotrebna
grana. Codeline 2.1
šk.god.2020/2021
<branch>
V2.1.1 V2.1.2
Codeline 2
V2.0 V2.1 V2.2 V2.3 V2.4

<merge>
<branch>
V1.0 V1.1 V1.2 V1.3
Codeline 1 Grana koja

V1.2.1 V1.2.1 se više ne
<branch>
razvija
Codeline 1.2
26
IZGRADNJA SISTEMA (BUILD)
 Izgradnja sistema (build) je proces formiranja cjelovitog izvršnog sistema
(executable) prevođenjem (compiling) i povezivanjem (linking) komponenti
sistema, vanjskih biblioteka, konfiguracijskih datoteka i td.
Sistem (razvojno okruženje) koji vrši izgradnju (build) mora komunicirati
šk.god.2020/2021

sa sistemom za upravljanje verzijama da bi mogao dobiti adekvatne
verzije komponenti koje ulaze u cjelinu.
 Izgradnja sistema je kompleksan proces koji je podložan greškama jer u
njemu mogu učestvovati tri različite platforme:
RAZVOJNI CILJNI
SISTEM SISTEM
Izgradnja Testno Ciljna platforma je
Razvojni okruženje
Realno
okruženje
Izvršni okruženje u kome će
sistema (simulacija
zbog alati realnog
(teško ga je sistem se sistem izvršavati i
simulirati) može se razlikovati
testiranja i okruženja)
sl. Privatni radni Ciljna od razvojnog. Ciljna
platforma može biti
prostor VMS i Build platforma
ugrađeni sistem ili
sistem ograničenih
mogućnosti.
check_out SISTEM ZA (co) SERVER ZA
(co) UPRAVLJANJE IZGRADNJU
Server za izgradnju
VERZIJAMA SISTEMA konačne verzije sistema.
27
check_in
Usko sarađuje sa VMS i
može se oslanjati na
vanjske komponente.
Agilne metode traže čestu izgradnju
sistema pa se primjenjuje
IZGRADNJA SISTEMA (BUILD) kontinuirana integracija sistema kao
što je prikazana na slici. Nije uvijek
primjenjivo (veliki sistemi razlika
između testne i ciljne platforme i sl.)
SISTEM ZA
Privatni radni
UPRAVLJANJE
prostor
VERZIJAMA Testovi
neuspješni
šk.god.2020/2021
Izgradnja i Izgradnja i
Check_out Pravljenje
testiranje testiranje
MAINLINE promjena
sistema sistema
Testovi
Check_in u uspješni
Build server
Testovi SERVER ZA SISTEM ZA

neuspješni IZGRADNJU UPRAVLJANJE
Izgradnja i
testiranje SISTEMA VERZIJAMA
sistema
Testovi Smjestiti
promjene u
28
uspješni
VM
UPRAVLJANJE RELEASE-IMA
 Release je verzija koja se isporučuje klijentu.
 Softver za masovnu upotrebu obično ima dvije vrste release-a:
 Major (veliki) release – uključuje značajne nove funkcionalnosti; očekuje se naplata
istog.
šk.god.2020/2021
 Minor (mali) release – uključuje popravljene nedostatke softvera; obično se isporučuje
besplatno.
 Kada se proizvede release mora se dobro dokumentovati tako da se može
kreirati ponovo u budućnosti. Važno je zabilježiti komponente koje ulaze u
release, ali je važno zabilježiti i okruženje na kome je rađena izgradnja
istog (build).
 Važno je planiranje kada će i kog obima biti pušten novi release.
Ako to zahtjeva određene promjene kod klijenta onda može naići na
negativan odziv.
 Postoji niz faktora koji se razmatraju kada se donosi odluka kada pustiti
novi release. Neki od najvažnijih su: tehnički kvalitet sistema, promjene na
platformi, 5-to Lehman-ovo pravilo (release sa puno novih funkcionalnosti
će vjerovatno morati biti propraćen sa release-om za popravljanje 29
nedostataka), konkurencija, očekivanja tržišta, dogovor sa klijentom, ...
LEHMAN-OVA PRAVILA VEZANA ZA
PROMJENE SISTEMA (EVOLUCIJU SISTEMA)
1. Kontinuirano prilagođavanje (continuing change). Program koji se
koristi u realnom okruženju se mora prilagođavati istom, ili će njegov stepen
prilagođenosti okruženju progresivno opadati.
2. Rast kompleksnosti (increasing complexity). Evolucijom struktura
programa postaje sve kompleksnija. Dodatni resursi se moraju odvojiti da bi se
šk.god.2020/2021
očuvala jednostavnost.
3. Evolucija velikih programa (large program evolution). Evolucija
programa je samo-regulativan proces. Atributi sistema (veličina, vrijeme
između release-a, broj prijavljenih nedostataka i td.) su približno nepromjenjivi
za svaki release.
4. Organizacijska stabilnost (organizational stability). Tokom života
programa stepen njegovog razvoja je približno konstantan i nezavisan od
resursa namijenjenih razvoju tog sistema.
5. Očuvanje poznavanja programa (conservation of familiarity). Tokom
života programa, inkrementalna promjena u svakom release-u je približno
konstantna.
6. Kontinuirani rast (continuing growth). Da bi se očuvalo zadovoljstvo
korisnika količina funkcionalnosti mora rasti.
7. Opadanje kvaliteta (declining quality). Kvalitet sistema će opadati ako se
ne prilagaođava promjenama okruženja.
8. Sistem povratne sprege (feedback system). Proces evolucije uključuje 30
mnoge različite povratne sprege koje se mogu posmatrati kao jedan sistem koji
služi značajnom unaprjeđenju proizvoda (softvera).
UPRAVLJANJE RELEASE-IMA
 Release pored izvršnog programa može uključivati:
 konfiguracione fajlove
 podatke potrebne za funkcionisanje sistema
instalacijski program
šk.god.2020/2021

 dokumentaciju (elektronsku i papirnu)
 pakovanje i reklamu
 Važno je naglasiti na koje prethodne release se može primijeniti novi
release. Npr. ako neko ima rel.1 i nije instalirao rel.2 a želi instalirati
rel.3, da li je to moguće. Poželjno je da je moguće, ali nije pravilo da to
jeste tako.
 Klijenti ne shvataju uvijek važnosti primjene određenog release-a, a
moguće je da taj release otklanja neke važne nedostatke koji su vezani
za sigurnost i sl.
31

Osp Iiparc All

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Osp Iiparc All

Uploaded by

Copyright:

Available Formats

PREDAVANJA 6 Timski rad i emocionalna inteligencija

• Tri ključne stvari za softverski projekat su ljudi, procesi i tehnologija.

o Samosvijest – sposobnost „čitanja“ vlasititih emocija i shvaćanje kakav utjecaj imaju na

• Projektni menadžer – menedžira projekat i vodi osoblje na projektu

ODRŽAVANJE MORALA I MOTIVACIJE

4 moguća slučaja i pristupa kako ih riješiti

• Tehnike podučavanja: kursevi, čitanje članaka, mentori, konsultantni

• Ličnost određuju ponašanje, mentalne osobine i emocije.

JUNGOVE OSOBINE LIČNOSTI

• Nema svako predominantnu osobinu, ali se većina naučnika slaže da su introvertnost i

MBTI TIPOVI LIČNOSTI

MBTI stilovi ličnosti Tipični izbor karijere

Preferencije menadžera koji je po MBTI

Pojmovi: Orijentisan na zadatak, Orijentisan na pitanja, Orijentisan na ljude, Orijentisan na govor

• Smatraju da postoje 4 temperamenta

PREDAVANJE 7 – PLANIRANJE PROJEKTA

• Menadžment projekta — proces vođenja projekta od njegovog početka do završetka koristeći

• Komponente projekta i njihove međuzavisnosti mogu se predstaviti pomoću menadžment

• Jednostavna hijerarhijska reprezentacija svih zadataka na projektu

• Različiti pristupi razvoju WBS

Lista koraka WBS

• Korisne stvari kod kreiranja WBS za menadžera

15 SMJERNICA ZA DIZAJN WBS

• Zadaci imaju međusobne zavisnosti, vrijeme trajanja, broj učesnika

• Procjenu trajanja zadataka određuje menadžer prije početka projekta

• Radni paketi se dodjeljuju pojedinim timovima

• Matrica vještina je praktična forma za raspoređivanje pojedinaca na određene zadatke na

• Ko su raspoloživi učesnici zavisi od strukture organizacije: projek-bazirane, linijske (funkcionalne)

TEHNIKE ESTIMACIJE (PROCJENE)

• (princip 1.) Estimacija projekta je projekcija iskustva iz prošlosti u budućnost, prilagođena na

ESTIMACIJA VELIČINE PRODUKTA

TEHNIKE ESTIMACIJE – PRAGMATIČNE

• Pragmatične tehnike estimacije, teoretski bazirane tehnike estimacije i modeli estimacije

o Menadžerisanje softverskog projekta uključuje planiranje i estimaciju, mjerenje i kontrolu,

o Atributi koji se mjere ne zavise od kriterija uspješnosti, ali uglavnom se mjere:

MJERENJE ATRIBUTA PRODUKTA

o Mjerenje zahtjeva (operacijske mogućnosti, atributi kvaliteta, zahtjevi za dizajn) i tehničkih

Inspekcija (2 sedmice i 30-40 radnih sati za 4 člana) Pregled/prolaz

• Ciklomatska kompleksnost dizajna grupe modula računa se kao kombinacija ciklomatskih

• Može se koristiti za određivanje broja testnih scenarija

• Mjerenje integracije i verifikacije softverskih jedinica

• datum otvaranja i zatvaranja defekta

MJERENJE I KONTROLA PROCESA

MJERENJE I ANALIZA NAPORA

MJERENJE I ANALIZA NAPORA KOD DORADE

o Količina napora za svaku od kategorija se mjeri praćenjem:

Estimacija budućeg statusa – također na bazi binarnog praćenja

IZVJEŠTAVANJE O ZARAĐENOJ VRIJEDNOSTI

Značenje nekih vrijednosti

o CPI < 1 i SPI<1 projekat ispod predviđenog budžeta i vremenskog plana

BAC = 500 000 EUR

BCWP = 50 000 EUR

BCWS = 40 000 EUR

ACWP = 60 000 EUR

CPI = 60 000 EUR / 50 000 EUR = 1,2

SPI = 40 000 EUR / 50 000 EUR = 0,8

EAC = 500 000 EUR * 1,2 = 600 000

ECD = 12 * 0,8 = 9,6 mjeseci

Estimacija vremena pokazuje da će biti potrebno 9,6 mjeseci da se projekat završi u

o EV izvještaji su koncizan način za prezentiranje:

Vanr.prof.dr Samir Omanović, dipl.ing.el.

AKTIVNOSTI UPRAVLJANJA Razvojne vrezije

Prijedlozi ALFA ver.

PROCJENA Razvoj softvera