Prof. dr Zoran . AVRAMOVI, dipl.in.elek.

zoran.avramovic@unvi.edu.ba

+381 63 245-605

SADRAJ

Pojam i vrste projekata. Koncept upravljanja projektom. Organizacija za upravljanje projektima. Upravljanje ljudskim resursima u projektu. Upravljanje ugovaranjem. Upravljanje kvalitetom projekta. Upravljanje rizikom projekta. Upravljanje komunikacijama u projektu.

SADRAJ - nastavak

Upravljanje promenama u projektu. Planiranje realizacije projekta. Praenje i kontrola realizacije projekta. Sistem izvetavanja o realizaciji projekta. Standardni raunarski programi za upravljanje projektom.Upravljanje pomou projekata.Projektno orijentisana organizacija.

UVOD

Ciklus razvoja softvera sastoji se iz vie faza, pri emu se neki od njih ponavljaju sve dok se sistem ne zavri a naruilac i korisnik budu zadovoljni. Meutim, pre nego to se potvrde sredstva za realizaciju razvoja ili odravanja softvera, korisnik obino eli da proceni koliko e projekat da kota i traje. U ovom predmetu pratimo aktivnosti koje su neophodne za planiranje razvoja softverskog projekta i upravljanje njime, a to su:

praenje napretka projekta,

osoblje i organizaciju projekta,

uloeni rad i rokovi,

upravljanje rizikom i

modelovanje procesa i planiranje projekata.

Definisanje projekta

Projekat je privremen i jedinstven poduhvat, to znai da se preduzima privremeno, da ostvari jedinstven proizvod ili uslugu. Privremenost oznaava da svaki projekat ima definisan poetak i kraj, ali to ne znai da ima kratko vreme trajanja jer mnogi projekti traju i po nekoliko godina. Jedinstvenost oznaava da je projekat neto neponovljivo i da se razlikuje od svih slinih proizvoda ili usluga. Kraj projekta oznaava realizaciju projektnih zadataka.Projekat je poduhvat sa definisanom takom poetka i definisanim ciljem, na osnovu koga je odreena realizacija.

Karakteristike projekta

Ne postoje dva ista projekta pa e ak i ponovljeni projekat imati razlike sa komercijalnog, administrativnog ili nekog drugog stanovita. Projekat ukljuuje sledee karakteristike:

ivotni ciklus,

startni i zavrni termini,

budet (finansijska sredstva),

aktivnosti,

korienje resursa,

jedinstvenu odgovornost i

timske uloge i odnose koji su subjekti promena i koje treba definisati i odrediti, a kasnije njima i upravljati.

Projektni ciljevi

Cilj je ono to se eli postii. Da bi bili dobri, ciljevi moraju biti:

specificirani dobro definisani, da budu jasni onima koji rade na realizaciji projekta,

merljivi da bi se znalo koliko je jo ostalo do realizacije cilja,

usklaeni mora biti tano definisan dogovor izmeu naruioca i projektog tima,

realni da postoji realna osnova za ostvarenje ciljeva sa dostupnim resursima, znanjem i vremenom,

vremenski podesni - da po realizaciji ne izgube svoju svrhu.

Praenje napretka softvera

Softver je koristan samo ako realizuje eljenu funkciju ili prua traenu uslugu. Prema tome, tipian projekat zapoinje kada nam se obrati naruilac radi razmatranja uoene potrebe. Obino naruilac ima pitanja na koje treba dati odgovor:

- da li razumete moj problem i moje potrebe?

da li moete da projektujete sistem koji bi reio moj problem ili zadovoljio moje potrebe?

koliko e vam vremena biti potrebno da razvijete takav sistem?

- koliko e kotati razvoj tog sistema?

Projektni rokovi opisuju razvojni ciklus nekog softvera u okviru odreenog projekta, sa fazama projekta od kojih je svaka razbijena na izolovane zadatke koje je potrebno realizovati. Prema tome, rokovi predstavljaju vremensku osu koja prikazuje kada zapoinju aktivnosti i kada se zavravaju tj. kada e proizvod razvojnog procesa biti na raspolaganju. Sistemski pristup obuhvata analizu i sintezu i to razbijanje problema na delove, formulisanje reenja za svaki deo i sklapanje tih delova u konherentnu celinu. Posao zapoinjemo radom sa naruiocima i potencijalnim korisnicima da bismo shvatili njihove elje i potrebe, a u isto vreme proveravamo da li su oni zadovoljni naim poznavanjem njihovih potreba.

Pri tome navodimo sve meuproizvode tj. stavke koje naruilac oekuje da dobije tokom razvoja projekta. U meuproizvode spadaju:

dokumenti,

demonstracija funkcije,

demonstracija podsistema,

demonstracija tanosti,

demonstracija pouzdanosti, bezbednosti ili performansi.

Posle toga utvrujemo koje aktivnosti moraju da se sprovedu u cilju realizacije definisanih elemenata isporuke. Pri tome, moemo koristiti neku od tehnika za modelovanje procesa, izlaui tano ta se mora dogoditi i koje aktivnosti zavise od drugih aktivnosti, proizvoda odnosno resursa.

U naoj analizi projekta, moramo napraviti jasnu razliku izmeu aktivnosti i putokaza. Aktivnost je deo projekta koji se odigrava tokom nekog vremenskog perioda, dok putokaz predstavlja zavretak aktivnosti u odreenom vremenskom trenutku. Prema tome, aktivnost ima poetak i kraj, dok putokaz predstavlja kraj neke posebno izdvojene aktivnosti.Paljivim ispitivanjem projekta razvoj moemo podeliti na niz faza. Svaka faza se sastoji od koraka, a svaki korak se sastoji od aktivnosti. Analizom razvoja ili odravanja softvera, postiemo da projektni tim i naruilac bolje shvate ta je obuhvaeno izgradnjom ili odravanjem sistema.

Struktura poslova i grafovi aktivnosti

Analiza ove vrste nekada se opisuje kao proces generisanja strukture poslova u okviru projekta, budui da opisuje projekat kao skup diskretnih poslova. Treba imati u vidu da aktivnosti i putokazi predstavljaju elemente koje naruilac i razvojni tim mogu da koriste za praenje razvoja ili odravanja. Naruilac e moda hteti da vidi napredak u bilo kojoj taki projekta. Kao uesnici u razvoju, moemo da ukaemo na aktivnost, da bismo predstavili poslove koji su u toku i putokaze, sa ciljem prezentacije stepena gotovosti posla.

Svaku aktivnost moemo opisati sa 4 parametra: prethodnikom, trajanjem, krajnjim rokom i krajnjom takom. Prethodnik je skup dogaaja koji moraju da se dogode pre nego to se posmatrana aktivnost zapone. Trajanje je vreme potrebno za kompletiranje aktivnosti.Krajnji rok ja datum do kojeg aktivnost mora biti okonana.Krajnja taka je obino putokaz i oznaava da je aktivnost zavrena.Pomou ovih parametara moemo nacrtati graf aktivnosti. vorovi grafa predstavljaju putokazi, a grane koje povezuju vorove predstavljaju sadrane sktivnosti.

Procena gotovosti

Graf aktivnosti moemo uiniti jo korisnijim dodavanjem informacija o proceni vremena koja je potrebna za zavretak svake aktivnosti. Sledea tabela sadri procene za svaku aktivnost:Tabela1. Aktivnosti i potrebno vremeAktivnostPotrebno vreme (u danima)Korak1. Priprema zemljitaAktivnost 1.1: Premer zemljita3Aktivnost 1.2: Traenje dozvola15Aktivnost 1.3: Kopanje temelja10Aktivnost 1.4: Kupovina materijala10

Za svaku aktivnost, definisanu grafom, moemo izraunati dva vremena: realno potrebno vremeraspoloivo vreme.Stvarno potrebno vreme ili stvarno vreme aktivnosti je vreme koje je potrebno za okonanje aktivnosti, dok raspoloivo vreme predstavlja vreme koje je u okviru vremenskih rokova, raspoloivo za njeno okonanje. Vreme kanjnja ili klizanje aktivnosti predstavlja razliku izmeu raspoloivog i stvarno potrebnog vremena za okonanje posmatrane aktivnosti:

Vreme kanjenja = raspoloivo vreme stvarno potrebno vreme

Alati za praenje napretka

Postoje mnogi alati koji se koriste za praenje napretka projekta. Neki alati su runi, drugi predstavljaju jednostavne aplikacije za rad sa tabelama, a postoje i sofisticirani alati sa kompleksnim grafikim predstavama. Da bismo videli koje vrste alata mogu da budu korisni pri projektovanju, razmotriemo strukturu posla vezanu za izgradnju komunikacionog softvera, gde je rukovodilac predstavio rad na projektu u 5 koraka: planiranje sistema, projektovanje, kodovanje, testiranje i isporuku.Mnogi softverski sistemi za upravljanje projektima crtaju strukturu posla i pomau rukovodiocu projekta u praenju napretka po svakom koraku i aktivnosti. Dijagrami i grafikoni mogu takoe da prue infomacije o resursima.

Osoblje na projektu

Postoje odreene aktivnosti koje su neophodne u svakom softverskom projektu. U kljune aktivnosti spadaju:

analiza zahteva,

projektovanje sistema,

projektovanje programa,

implementacija programa,

testiranje,

obuka,

odravanje i

osiguranje kvaliteta.

Osoblje projekta moe da se razlikuje po vie kriterijuma. Dve osobe koje rade na istom radnom mestu mogu da se razlikuju po najmanje jednom od sledeih kriterijuma:

sposobnost izvravanja posla,

interesovanje za posao,

obuenost,

rukovodilake sposobnosti...

U svakom razvojnom projektu lanovi razvojnog tima komuniciraju meusobno, sa korisnicima kao i sa naruiocem. Na napredovanje projekta ne utie samo stepen komunikacije ve i sposobnost pojedinca da saopti svoje ideje.

Stilovi rada

Razliiti ljudi imaju razliite stilove za interakciju sa saradnicima radi razumevanja problema koji u toku rada iskrsnu. Omiljeni stil rada moemo da posmatramo u funkciji dva parametra: nain na koji se razmenjuju misli i raaju ideje i uticaja emocija na donoenje odluka. Jung (1959) prve naziva ekstrovertima, a druge introvertima. Slino tome, intuitivne osobe zasnivaju svoje odluke na oseaju i emotivnoj reakciji na probleme dok druge osobe su racionalne i donose odluke, pre svega, ispitujui injenice i paljivo razmatrajui sve mogunosti.

Raznolikost stilova moemo da posmatramo pomou grafikona, gde je stil komunikacije na horizontalnoj, a stil odluivanja na vertikalnoj osi.

INTUITIVAN

RACIONALAN

EKSTROVERT

INTROVERT

INTUITIVAN

INTROVERT

Pita druge

Priznaje oseanja

INTUITIVAN

EKSTROVERT

Saoptava drugima

Priznaje oseanja

RACIONALAN

INTROVERT

Pita druge

Odluuje logino

RACIONALAN

EKSTROVERT

Saoptava drugima

Odliuje logino

Slika 1. Stilovi rada

Organizacija projekta

Projektni timovi za razvoj i odravanje softvera se sastoje od lanova tima koji su organizovani na nain koji doprinosi brzoj izradi kvalitetnih proizvoda. Izbor odgovarajue strukture projekta zavisi od nekoliko inilaca, a to su:

biografije i stilovi rada lanova tima,

broj ljudi u timu,

stilovi rukovoenja koje primenjuju naruilac i razvojni tim.

Dobri rukovodioci projekta su svesni tih pitanja i trae lanove tima koji su dovoljno fleksibilni za interakciju sa svim uesnicima, bez obzira na stil rada.

Potreban rad

Jedno od prelomnih gledita planiranja u upravljanju projektom je shvatanje koliko e projekat priblino da kota. Prekoraenje trokova moe dovesti do odustajanja od projekta.Zato je dobro izvriti procenu trokova jo u ranoj fazi ivotnog ciklusa projekta i tako pomoi rukovodiocu da utvrdi broj ljudi neophodnih za razvoj i da odgovarajue osobe budu raspoloive kada je to neophodno. Iz budeta projekta pokriva se vie vrsta trokova: sredstva, osoblje, metodi i alati. Trokovi sredstava obuhvataju: hardver, prostor, nametaj, telefone, modeme, grejanje, kanalizaciju, kablove, diskove, papir... Drugi projektni trokovi obuhvataju kupovinu softvera i alata za podrku aktivnostima razvoja. Uloeni rad predstavlja trokovnu komponentu sa najveim stepenom neizvesnosti.

Algoritamske metode

Istraivai su napravili modele koji izraavaju odnos izmeu potrebnog rada i faktora koji na njega utiu. Ti modeli se obino opisuju pomou jednaina u kojima je napor funkcija, a vie inilaca (iskustvo, veliina i tip aplikacije) nezavisne promenljive. Veina tih modela potvruje da je veliina projekta najuticajniji faktor u jednainama gde se rad izraava na sledei nain:

E = (a + bSc) m (X)

gde je S procenjena veliina sistema, a, b , c su konstante. X je vektor faktora trokova, xq do xn, a m je korekcioni faktor koji od njih zavisi. Drugim reima, rad se meri uglavnom na osnovu veliine predloenog sistema, uz korektivni uticaj vie drugih karakteristika projekta, procesa, proizvoda ili korienih resursa.

Metodi mainskog uenja

Ima istraivaa koji se bave mainskim uenjem npr. oslanjajui se na neuralne mree mogue je predstaviti vei broj povezanih i zavisnih jedinica. U neuralnim mreama, svaka jedinica (neuron, predstavljen mrenim vorom) predstavlja jednu aktivnost. Svaka aktivnost ima svoje ulaze i izlaze. Svakoj jedinici mree pridruuje se softver koji proraunava svoj ulaz, izraunavajui ponderisanu sumu. Ako suma premauje vrednost zadatog praga, jedinica proizvodi izlaz. Taj izlaz postaje ulaz za druge povezane jedinice u mrei, sve dok mrea ne proizvede konanu vrednost. Neuralna mrea je proirenje grafa aktivnosti.

Postoji mnogo naina kako neuralna mrea moe da proizvede izlazne informacije. Neke tehnike posmatraju unazad ono to se dogodilo u drugim vorovima dok neke posmatraju ono unapred, u cilju predvianja ta e se upravo dogoditi. One se nazivaju tehnike prostiranja unazad.Neuralne mree se razvijaju njihovim obuavanjem na osnovu podataka iz ranijih projekata. Relevantni podaci se ubacuju u mreu, a sama mrea koristi algoritme koji idu unapred ili unazad, identifikujui ablone u podacima.

Upravljanje rizicima

Rukovodioci projekta moraju da uestvuju u upravljanju rizicima da bi razumeli rizike i njima upravljali u svojim projektima. Rizik razlikujemo od drugih dogaaja u projektu na osnovu 3 pokazatelja:

gubitak po dogaaju,

izvesnost pojave dogaaja i

stepen do kog je mogue promeniti ishod.

Efekte identifikovanih rizika moemo kvantifikovati mnoenjem uticaja rizika sa njegovom verovatnoom, ime dobijamo izloenost riziku. Postoje dva glavna izvora rizika:

opti rizici i

rizici koji su specifini za razmatrani projekat.

Opti rizici su rizici koji su zajedniki za sve softverske projekte, a rizici specifini za projekat su pretnje koje su posledica slabih taaka konkretnog projekta.

Aktivnosti upravljanja rizicima

Upravlajnje rizicima obuhvata vie koraka prikazanih na slici 2. Najpre procenjujemo rizik datog projekta i to procenjivanje se sastoji od 3 aktivnosti: identifikovanje rizika, analize rizika i dodeljivanje prioriteta svakom od njih. Za identifikaciju rizika koristimo vie razliitih tehnika.

Slika 2. Koraci u upravljanju rizicima

Postoje 3 strategije za umanjenje rizika i to su:

- izbegavanje rizika,

- prenoenje rizika i

- podrazumevanje rizika.

Pod pojmom sprega rizika podrazumevamo kolinik razlike iloenosti riziku pre i posle umanjenja rizika i troka koje to umanjenje nosi. Drugim reima, sprega umanjenja rizika je:

(izloenost riziku pre umanjenja izloenost riziku posle umanjenja) / troak umanjenja rizika

Plan projekta

Da bismo naruiocima preneli rezultate analize rizika i predloili upravljanje njime obino pravimo plan projekta. Plan u pisanom obliku sadri korisnikove potrebe i nae namere vezane za zadovoljenje tih potreba. Plan moe biti osnova za potvrdu uinjenih pretpostavki, posebno onih vezanih za trokove i rokove.Dobar plan projekta mora da ima sledee elemente:

- obim projekta,

- rokove projekta,

- organizaciju projektnog tima,

- tehniki opis predloenog sistema,

- standarde koji se koriste u projektu, postupke, tehnike i alate,

- plan osiguranja kvaliteta,

- plan upravljanja konfiguracijom,

- plan dokumentovanja,

- plan upravljanja podacima,

- plan upravljanja resursima,

- plan testiranja,

- plan obuke,

- plan bezbednosti,

- plan upravljanja rizicima i

plan odravanja.

Obim definie granice sistema, odnosno ta e biti obuhvaeno sistemom, a ta nee. On garantuje naruiocu da smo razumeli ta se od projekta zahteva. Rokovi se mogu izraziti preko strukture posla, miljokaza i vremenskih rokova, da bi se prikazalo ta se dogaa u svakoj taki tokom ivotnog ciklusa softvera.

U planu projekta dokumentuju se sva posebna ogranienja vezana za kabliranje, vremena izvravanja, vremena odziva, bezbednost itd. On takoe navodi standarde i metode koji se moraju koristiti npr. algoritmi, alati, jezici za kodovanje itd.Plan projekta navodi dokumente koji treba da se izrade, objanjava ko e ih i kada izraditi i on takoe mora da objasni nain prikupljanja, skladitenja, manipulacije i arhiviranja podataka. Da bi testiranje bilo efikasno plan projekta treba da sadri sveobuhvatan pristup testiranju u sklopu projekta.Konano, ako e projekti tim da odrava sistem i posle isporuke, plan projekta treba da razmotri i odgovornosti za izmene programa, popravke hardvera i auriranje pratee dokumentacije i materijala za obuku.

Modeli procesa i upravljanje projektom

Najuspeniji rukovodioci projektima, koji realizuju kvalitetne proizvode na vreme i u okviru zadatog budeta, jesu oni koji tehnike rukovoenja projektom prilagoavaju posebnim karakteristikama neophodnih resursa, odabranom procesu i dodeljenim ljudima. U ovom delu razmotriemo nekoliko optepoznatih projekta iz bliske prolosti i/ili iz sopstvenog iskustva nastavnika. Takoe emo da se osvrnemo na objedinjavanje upravljanja procesima i projektom.

vrsto vezivanje za
sidrine putokaze

Godine 1996. identifikovana su tri putokaza, zajednika za sve procesne modele softverskog razvoja, koji mogu da poslue kao osnova kako za tehniki proces tako i za upravljenje projektom:

ciljevi ivotnog ciklusa,

arhitektura ivotnog ciklusa,

inicijalna operativnost sistema.

Svrha putokaza ciljeva ivotnog ciklusa je da potvrdi da su se svi zainteresovani subjekti saglasili sa ciljevima posmatranog sistema. U sklopu arhitekture ivotnog ciklusa jeste da se definiu arhitekture sistema i softvera. Kljuni elementi koji odreuju inicijalnu operativnost sistema su spremnost samog softvera, spremnost lokacije na kojoj e se sistem koristiti kao i izbor i obuka tima koji e da koristi sistem.

ZAKLJUAK

U ovom delu emo ponoviti najznaajnije rezultate koji su prezentovani kroz materijal i podstai diskusiju. Pitanja i odgovoriDiskusijaIskustva slualaca