1

PANEVROPSKI UNIVERZITET APEIRONFAKULTET POSLOVNE INFORMATIKE

Vanredne studijeSmjer „Poslovna Informatika”

Predmet

SOFTVERSKI INŽENJERING

„Planiranje i upravljanje projektom”

(seminarski rad)

Predmetni nastavnikProf. dr Zoran Ž. Avramović, dipl.inž.elek.

Student

Gojko SikimicIndex br. 31/10-VPI-S

Banja Luka, April 2011.

2

S A D R Ž A J

UVOD

1. PRAĆENJE NAPRETKA PROJEKTA 1.2. Struktura poslova i grafovi aktivnosti 1.3. Procjena gotovosti 1.4. Alati za praćenje napretka

2. OSOBLJE NA PROJEKTU 2.1 Uloge i karakterstike tima

3. POTREBAN RAD

4. UPRAVLJANJE RIZICIMA 4.1 Aktivnosti upravljanja rizicima

5. PLAN PROJEKTA

6. MODELI PROCESA I UPRAVLJANJE PROJEKTOM 6.1. Upravljanje u paketima 6.2. Model vodopada 6.3. Model evolucijskog razvoja 6.2. Model vodopada 6.3. Model evolucijskog razvoja 6.4. Model formalnog razvoja

Z A K L J U Č A K

L I T E R A T U R A

3

U V O D

Ovaj seminarski rad bavi se računarskim i tehničkim aspektima softverskog inženjerstva,ali podjednako i važnosti organizacijskog (managerskog) aspekta.Upravljanje softverskim projektom (engleski software project management) potrebno je zato da bi se softver razvio na vrijeme i u okvirima planiranih troškova. Posao upravljanja softverskim projektom povjerava se softverskom manageru. Softversko inženjerstvo je znanstvena i stručna disciplina koja se bavi svim aspektima proizvodnje softvera. Dakle, softversko inženjerstvo bavi se modelima, metodama i alatima koji su nam potrebni da bi na što jeftiniji način mogli proizvoditi što kvalitetnije softverske proizvode. Planiranje i praćenje projekta predstavlja redovan, svakodnevni i najegzaktniji posao softverskog menadžera.

4

1. PRAĆENJE NAPRETKA PROJETKA

Krajnji cilj svakog softvera jeste da sistem funkcioniše a da naručilac i korisnik budu zadovoljni sa dobijenim rješenjem, jer softver je koristan isključivo ako realizuje željenu funkciju ili pruža traženu uslugu. Dok se potvrde sredstva za realizaciju razvoja ili održavanja softvera korisnik obično želi da procjeni koliko će projekat da košta i traje. Prema tome tipičan projekat počinje od trenutka kada nam se naručilac obrati radi razmatranja uočene potrebe. Na primjer nama se obrate hidrolozi koji bi volili da imaju sistem povezan sa njihovom opremom za rad, mjerenje i nadgledanje voda pomoću kojeg bi mogli vršiti statističke analize prikupljenih podataka te tako lakše mogli predvidjeti i potencijalne opasnosti od poplava ili drugih katastrofa. Obično naručilac ima više pitanja na koje treba dati odgovor:-Da li razumijete moj problem i moje potrebe ?-Da li možete da projektujete sistem koji bi rješio moj probelm i zadovoljio moje potrebe ?-Koliko vremena je potrebno da se razvije takav sistem ?-Koliko će koštati izrada i razvoj takvog sistema ?

Odgovor na dva posljednja pitanja zahtjeva postojanje dobro osmišljenih rokova za aktivnost na projektu. Projektni rokovi opisuju razvojni ciklus nekog softvera u okviru određenog projekta , sa fazama ili etapama projekta od kojih je svaka razbijena ili usitnjena na izolovane zadatke ili aktivnosti i procjenjuje rokove i trajanje svakog zadatka ili aktivnosti. Prema tome rokovi predstavljaju vremensku osu koja prikazuje kada započinje aktivnost i kada se završavaju,tj. Kada ćemo imati krajnji proizvod na raspolaganju. Sistemski pristup obuhvata i analizu i sintezu: razbijanje problema na dijelove, formulisanje rješenja za svaki dio posebno i sklapanje tih djelova u koheretnu cjelinu. Identičan pristup možemo primjeniti i kod definisanja rokova za aktivnosti u okviru projekta. Posao započinjemo radom sa naručiocima i potencijalnim korisnicima da bismo što bolje shvatili njihove želje i potrebe. U isto vrijeme provjeravamo da li su oni zadovoljni našim poznavanjem njihovih potreba. Pri tome navodimo sve međuproizvode ,tj. Stavke koje naručilac očekuje da dobije tokom razvoja projekta.U međuproizvode spadaju:- dokumenti- demonstracija funkcija- demonstarcija podsistema - demonstracija tačnosti- demonstracija pouzdanosti,bezbjednosti ili performansi.Nakon toga utvrđujemo koje aktivnosti moraju da se sprovedu u cilju realizacije definisanih elemenata isporuke. Pri tome možemo izlagati šta tačno mora da se dogodi i koje aktivnosti zavise od drugih od drugih aktivnosti, proizvoda, odnosno resursa. Određeni događaji se deklarišu kao miljokazi i služe kao pokazatelji nepredovanja projekta. Na primjer nakon dokumentovanja zahtjeva, provjere njihove dosljednosti i kompletnosti i uručenja projektantima, specifikacija zahtjeva se može smatrati i miljokazom projekta.U našoj analizi projekta , moramo napraviti jasnu razliku između aktivnosti i miljokaza.Aktivnost je dio projekta koji se odigrava tokom nekog vremenskog perioda, dok miljokaz predstavlja završetak aktivnosti u određenom vremenskom trenutku.Prema tome aktivnost ima početak i kraj, dok miljokaz predstavlja kraj neke posebno izdvojene aktivnosti.

5

Pažljivim ispitivanjem projekta na ovaj način .možemo da podjelimo razvoja na niz faza. Svaka faza se sastoji od koraka , a svaki korak, ako je to neophodno , može biti predemet dalje podjele. Kao što je prikazano na slici 1.1.

Slika 1.1 Faze, koraci i aktivnosti u okviru projekta

KORAK 1 AKTIVNOSTI 1.1

FAZA 1 AKTIVNOSTI 1.2

AKTIVNOSTI 2.1KORAK 2 AKTIVNOSTI 2.2

AKTIVNOSTI 2.3

PROJEKATKORAK 1

FAZA 2

KORAK 2

Da bismo vidjeli kako ta naliza funkcioniše , razmotrićemo faze , korake i aktivnosti date u tabeli 1.1, koje opisuju gradnju kuće. Za početak ćemo uzeti dvije faze : zemljane radove i gradnju same kuće. Nakon toga ćemo svaku fazu razbiti na manje korake, kao što su: :raščišćavanje i krčenje terena, sijanje trave i sađenje drveća. Gdje je neophodno, navedene korake možemo podijeliti na aktivnosti: na primjer, završetak unutrašnjosti uključuje dovršavanje unutrašnje vodovodne i električne instalacije, malterisanje, krečenje, stavljanje vrata i montaža uređaja. Svaka aktivnost predstavlja mjerljiv događaj, pri čemu imamo objektivni kriterijum na osnovu koga određujemo da li je aktivnost završena. Prema tome kraj svake aktivnosti može biti miljokaz.

6

Tabela 1.1 Faze, koraci i aktivnosti gradnje kuće

Tabela 1.1 Faze,koraci I aktivnosti gradnje kuće

Faza 1:Zemljani radovi Faza 2:Gradnja kuće

Korak 1.1. raščišćavanje i krčenje  

Korak 2.1:pripremanje gradilišta  

Aktivnost 1.1.1: Uklanjanje stabala Aktivnost 2.1.1: Premjer zemljišta

Aktivnost 1.1.2:Uklanjanje panjeva Aktivnost 2.1.2: Traženje dozvola

 Korak1.2:sađenje trave

Aktivnost 2.1.3: Kopanje jama za temelj jame

Aktivnost 1.2.1:Aeracija tla Aktivnost 2.1.4: Kupovina materijala

Aktivnost 1.2.2:Sijanje

Korak 2.2: Gradnja spoljašnosti  

Aktivnost 1.2.3: Zalijevanje i pljevljenje Aktivnost 2.2.1: Postavljanje temelja

 

Korak 1.3:Planiranje

žbunova i stabala

Aktivnost 2.2.2: Gradnja spoljašnih zidova

Aktivnost 1.3.1: Dobijanje žbunova i stabala Aktivnost 2.2.3:Postavljanje spoljašne vodovodne instalacije

Aktivnost 1.3.2: Kopanje rupa Aktivnost 2.2.4: Spoljašni elektro radovi

Aktivnost 1.3.3: Sadnja žbunova Aktivnost 2.2.5:Krečnje fasade i montiranje vrata

Aktivnost 1.3.4:Učvršćivanje stabala i zagrtanje đubrivom Aktivnost 2.2.6:Montiranje krova

 

Korak 2.3:Unutrašnji završni radovi

Aktivnost 2.3.1:Postavljanje unutrašnje vodov. Mreže

Aktivnost 2.3.2:Postavljanje unutrašnje elek. Instalacije

Aktivnost 2.3.3:Malterisanje i unutrašnja krečenja

Aktivnost 2.3.Postavljanje vrat i uređaja

Ovo analitičko razlaganje daje naručiocu i projektantu viziju svega što je obuhvaćeno gradnjom kuće. Slično tome , analizom razvoja ili održavanje softvera, identifikovanje faza, koraka i aktivnosti, postižemo da projektni tim i naručilac bolje shvate šta je sve obuhvaćeno gradnjom kuće ili održavanjem sistema.

1.1. Struktura poslova i grafovi aktivnosti

7

Analiza ove vrste nekada se opisuje kao proces generisanja strukture poslova (work breakdown structure, WBS) u okviru projekta, budući da opisuje projekat kao skup diskretnih ili odvojenih poslova. Treba imati u vidu da aktivnosti i miljokazi predstavljaju elemente koje naručilac i razvojni tim mogu da koriste za praćenje razvoja ili održavanja. Naručilac će možda htjeti da vidi napredak u bilo kojoj tački projekta. Kao učesnici u razvoju, možemo da ukažemo na aktivnosti, da bismo predstavili poslove koji su u toku i miljokaze, sa ciljem prezentacije stepena gotovosti posla. Međutim, struktura poslova ili dijelova projekta koji se istovremeno razvijaju.Svaku aktivnost možemo opisati sa četiri parametra:- prethodnikom- trajanjem- krajnjim rokom i - krajnjom tačkomPrethodnik je događaj ili skup događaja koji moraju da se dogode prije nego što posmatrana aktivnost započne. Prethodnik opisuje skup uslova koji omogućavaju započinjanje aktivnosti.Trajanje je vrijeme potrebno za kompletiranje aktivnosti.Krajnji rok je datum do kojeg aktivnost mora biti okončana, što je često određeno ugovorenim krajnjim rokovima.Krajnja tačka je obično miljokaz ili međuproizvod, označavajući da je aktivnost završena.Pomoću navedenih parametara možemo ilustrovati odnose između aktivnosti. Radi opisivanja zavisnosti možemo nacrtati graf aktivnosti. Čvorovi grafa predstavljaju miljokaze projekta, a grane koje povezuju čvorove predstavljaju sadržane aktivnosti. Slika 2.2 prikazuje graf aktivnosti za poslove opisane u fazi 2 date u tabeli 1.1.

Tabela 2.2 Miljokazi prilikom gradnje kuće1.1 Gotovo premjer1.2 Dobijene dozvole1.3 Završen iskop1.4 Spreman materijal2.1 Postavljeni temelji2.2 Gotovi spoljašni zidovi2.3 Završena spoljna vodovodna instalacija2.4 Završeni spoljašni elektro radovi2.5 Fasada završena2.6 Krečenje fasada završeno2.7 Postavljena vrata i uređaji2.8 Krov završen3.1 Završena unutrašnja vodo instalacija3.2 Postavljena unutrašnja elektro instalacija3.3 Malterisanje završeno3.4 Krečenje unutrašnjosti završeno3.5 Postavljene podne obloge3.6 Postavljeni vrata i uređaji

8

POČETAK Traženje dozvola Snimanje terena

Iskopavanje

Kupovina materijala

Postavanje spoljašnje Gradnja spoljašnjih zidova vodovodne instalacije

Postavljanje spoljašnje Postavljanje unutrašnje Postavljanje unutrašnjieelektrične instalacije vodovodne instalacije električne instalacije

Postavljanje fasade Malterisnje

Unutrašnje krečenje

Krečenje fasade Postavljanje krovnog Postavljanje podnih Pokrivača obloga

Postavljanje unutrašnjih

vrata i uredjajaPostavljanje spoljnih vrata i uredjaja

ZAVRŠETAK

Graf aktivnosti obezbjeđuje vizualizaciju značajnih karakteristika projekta. Na našem primjeru se sada jasno vidi da niti jedna od vodoinstalaterskih aktivnosti ne može da počne prije nego što se dostigne miljokaz 2.2., ili drugim rječima aktivnost 2.2 je prethodnik unutrašnjim i spoljašnim vodoinstalaterskim radovima. Pored ovoga slika prikazuje mogućnost paralelnog izvršavanja aktivnosti. Tako imamo da su neke od unutrašnji i spoljašnjih aktivnosti potpuno nezavisne i mogu da se izvršavaju istovremeno. Grafovi moraju da održavaju paralelizme koji su mogući u stvarnosti. Međutim, u razvoju softvera gdje ima vještijih i manje vještijih, teoretski paralelizam možda ne održava onaj koji je i moguć u stvarnosti. Ograničavanje broja ljudi na projektu za poslijedice ima da ista osoba radi više stvari, jednu za drugom, iako bi se one mogle, kod većeg razvojnog tima, paralelno raditi.

9

1.2.

1.1

1.3

1.4

2.1

2.2

2.3

3.3

3.1

2.4

2.5

2.6

3.2

2.7

2.8

3.6

3.53.

4

1.2. Procjena gotovosti

Graf aktivnosti možemo učiniti još korisnijim dodavanjem informacija o procjeni vremena koje je potrebno za završetak svake od aktivnosti. Za posmatrane aktivnosti, odgovarajuću granu grafa označavamo brojem koji predstavlja procjenjeno vrijeme realizacije. U tabeli 1.2. možemo vidjeti procjene za svaku aktivnost,tj. svakoj aktivnosti možemo da dodamo procjenu broja dana potrebnih za dovršavanje svake aktivnosti.

Tabela 1.2 Aktivnosti i potrbno vrijeme

Korak 1:pripremanje gradilišta Potrebno vrijeme (u danima)

Aktivnost 1.1: Premjer zemljišta 3

Aktivnost 1.2: Traženje dozvola 15Aktivnost 1.3: Kopanje jama za temelj jame

10

Aktivnost 1.4: Kupovina materijala 10

Korak 2: Gradnja spoljašnosti 15

Aktivnost 2.1: Postavljanje temelja 20

Aktivnost 2.2: Gradnja spoljašnih zidova 12Aktivnost 2.3:Postavljanje spoljašne vodovodne instalacije 12Aktivnost 2.4: Spoljašni elektro radovi

8

Aktivnost 2.5:Krečnje fasade i montiranje vrata 5

Aktivnost 2.6:Montiranje krova 7

Korak 3:Unutrašnji završni radovi 10

Aktivnost 3.1:Postavljanje unutrašnje vodov. Mreže 13

Aktivnost 3.2:Postavljanje unutrašnje elek. Instalacije 17

Aktivnost 3.3:Malterisanje i unutrašnja krečenja 8

Aktivnost 3.4.Postavljanje vrat i uređaja 7

10

Kao rezultat dobijamo graf 1.3. Grafički opis projekta govori mnogo o vremenskim rokovima projekta. Na primjer ako smo procjenili da su za završetak neke aktivnosti potreban 3 dana, onda se ne možemo nadati da ćemo stići do određenog miljokaza prije ta predviđena 3 dana.

POČETAK 15 3

10

10

15 10 12

10

15

8 9

5 18 7

0 0

ZAVRŠETAK

Ovakva analiza putanja između miljokaza u projektu se naziva se metod kritične putanje- CPM (Crititical Path Method). Putanje mogu da pokažu minimalno potrebno vrijeme za završetak projekta, dajući nam procjenu trajanja svake aktivnosti. Pored toga, CPM otkriva aktivnosti koje su najkritičnije za završetak projekta na vrijeme.U svakom od grafova možemo izračunati dva vremena: realno potrebno vrijeme i raspoloživo vrijeme.Stvarno potrebno vrijeme ili stvarno vrijeme aktivnosti je vrijeme koje je potrebno za okončanje aktivnosti, dok raspoloživo vrijeme predstavlja vrijeme koje je, u okviru vremenskih rokova, raspoloživo za njeno okončanje.

11

1.2.

1.1

1.3

1.4

2.1

2.2

2.3

3.3

3.1

2.4

2.5

2.6

3.2

2.7

2.8

3.6

3.53.

4

Letentno vrijeme ili klizanje aktivnosti predstavlja razliku između raspoloživog i stvarno potrebnog vremena za okončanje aktivnosti:

Latentno vrijeme=raspoloživo vrijeme – stvarno potrebno vrijeme

Drugi način posmatranja latentnog vremena je poređenje najarnijeg i najkasnijeg započinjanja aktivnosti, a da se pri tome ne prouzruokuje kašnjenje u projektu.

Latentno vrijeme=vrijeme najkasnijeg započinjanja – vrijeme najranijeg započinjanja

1.3. Alati za praćenje napretka

Postoje mnogi alati koji se koriste za praćenje napretka projekta. Neki od tih alata su ručni, drugi predstavljaju jednostavne aplikacije za rad sa tabelama, a postoje i sofisticirani alati sa kompleksnim grafičkim predstavama. Da bismo vidjeli koje sve vrste alata mogu da budu korisne pri projektovanju, razmotrićemo strukturu posla prikazanu na sliici 1.2.Na ovom projektu, rukovodilac je predstavio rad u pet koraka: Planiranje sistema,projektovanje sistema,kodiranje,testiranje i isporuka. Mi ćemo se posvetiti na prva dva koraka radi jednostavnosti predstavljanja.Korak 1 je podjeljen na četiri aktivnosti: pregled specifikacija, pregled budžeta, pregled rokova i izrada plana projekta. Slično tome, dizajn sistema čine: dizajn visokog nivoa, izrada prototipa, projektovanje korisničkog interfejsa i detaljni dizajn.

Gradnja komunikacionog

softvera

Kodiranje 3.0

Testiranje 4.0

Isporuka 5.0

Planiranje sistema 1.0Projektovanja

sistema 2.0

Pregled specifikacije 1.1

Dizajn visokog nivoa 2.1

Pregled budžeta 1.2

Izrada prototipa 2.2

Pregled raspooreda 1.3

Korisnički interfejs 2.3

Izrada plana 1.4 Detaljni dizajn 2.4

Slika 1.2. Primjer strukture posla.Mnogi softverski sistemi za upravljanje projektima crtaju strukturu posla i pomažu rukovodiocu projekta u praćenju napretka po svakom koraku i aktivnosti. Takav dijagram pomaže rukovodiocu projekta da da jasnije vidi i razumije koje aktivnosti mogu da se izvode paralelno

12

i da uoči aktivnosti koje pripadaju kritičnoj putanji. Na ovakvim dijagramima se takođe može jasnije vidjeti informacije o resursima a u većini primjera su to ljudi potrebni za rad u svakoj od faza posla. Detaljnijim pregledom ovakvih dijagrama može se vidjeti da neki članovi tima u određenom vremenskom periodu rade, ali nedovoljno da bi uradili zadatak koji se od njih zahtjeva. S druge strane , jasno je prikazan period tokom kojeg postoji višak članova tima:na našem primjeru je to od početka juna do kraja septembra. Dodjela resursa u slučaju razmatranog projekta je očigledno neuravnotežena. Izmjenom ulaznih podataka grafikona, moguće je promjeniti dodjele resursa radi pokušaja smanjenja preopterećenosti, pronalazeći najbolje opterećenje resursa za ispunjenje postavljenih rokova.Projekcija zauzetosti tima

 

 

 

 

 

 

 

 

 

     

 

 

   

 

 

             

 

 

 

 

 

 

 

JAN FEB MAR APR MAJ JUN JUL AVG SEP OKT NOV DEC

Slika 1.3. Histogram resursa

2. OSOBLJE NA PROJEKTU

Radi lakšeg određivanja rokova nekog projekta,tj. Radi preciznijeg određivanja potrebnih resurse i vremena za kvalitetno izvršavanje procesa, potrebno je da barem otprilike znamo broj

13

  Opterećen

  Preopterećen

  Neopterećen

ljudi koji nam je potreban na projektu, vrijeme koje je potrebno, kao i koja sve znanja ti ljudi treba da posjeduju za uspješno izvršavanje zadatka.

2.1. Uloge i karakterstike tima

Ključne aktivnosti u procesu razvoja softvera su sljedeće:- Analiza zahtjeva;- Dizajn sistema;- Dizajn programa;- Implementacija programa;- Testiranje;- Obuka;- Održavanje;- Osiguranje kvaliteta.Važno za napomenuti je da ne izvršava svaki zadatak ista osba ili grupa ljudi. Dodjeljivanje radnika zadatcima zavisi od veličine projekta, obučenosti i iskustva osoblja. Postoji velika prednost dodjeljivanja različitih odgovornosti različitim grupama ljudi, čime se omogućavaju spontane provjere prilikom rada i na taj način možemo doći do otkrivanja grešaka u ranim fazama razvoja sistema. Iz ovih razloga veoma je bitno da projktant programa i projektant sistema ne budu ista osoba. Projektanti programa su duboko upleteni u kod programa čime nekada zanemaruju širu sliku oko toga kako sistem treba da radi.Nakon donošenja odluke o ulogama članova projektnog tima prelazimo na odluke o ljudima koji su za svaku od njih potrebni. Osoblje projkta može a i dobro je da se razlikuje. Razlikovati se može i po sljedećim kriterijumima:- Sposobnost izvršavanja posla;- Interesovanje za posao;- Iskustvo na sličnim poslovima,alatima,jezicima i tehnikama;- Obučenost;- Sposobnost komunikacije;- Sposobnost podjele odgovornosti ;- Sposobnost rukovođenja.Svaka od nabrojanih pojedinosti može da utiče na sposobnost kupca da produktivno obavlja zadati posao. Ove sposobnosti pomažu da objasnimo činjenice da jednom programeru za pisanje zadatog podprograma je potreban jedan dan, dok je drugom za taj isti posao potrebna cijela sedmica dana. Ove razlike mogu da postanu kritične i to ne samo za zadate podrokove nego i za uspjeh kompletnog projekta.Kako bi razumjeli učinak svakog radnika, moramo poznavati njegovu sposobnost da izvrši na vrijeme posao koji mu je povjeren. Neki radnici su dobri u sagledavanju šire problematike koju projekat nosi, ali možda nisu dobri u praćenju detalja koji su od njih traženi u sklopu samog projekta ili njegovog dijela. Takvim pojednicima više odgovara da rade projektovanje ili testiranje nego samo pisanje koda. Ponekad je sposobnost proporcionalna opuštenosti. Osjećaj opuštenosti je veoma bitan iz razloga jer su ljudi obično produktivniji ako imaju samopouzdanje u onome što rade.Zainteresovanost za posao takođe može da u dobroj mjeri odredi nečiju uspješnost u izvršavanja projektinih zadataka. Ovde često imamo primjer da veoma dobri radnici izgube interesovanje za posao jer uđu u neku vrstu nevoljnog ponavljanja zadatka gdje dolazi do zasićenja i smanjenja fokusa na radne zadatke. Prema tome novina na poslu predstavlja faktor generisanja interesovanja za posao. Međutim uvijek imamo ljude koji više vole da rade ono što zanju da rade i da to iz dana u dan ponavljaju, nego da se zainteresuju i istražuju nove

14

teritorije. Bez obzira veoma je bitno da se određeni zadatak radi sa entuzijazmom, bez obzira na razloge.U svakom razvojnom projektu ili održavanju softvera, članovi tima moraju imati jaku komunikaciju kako unutar svoga tima tako sa korisnicima a posebno sa naručiocem. Na napredovanje projekta ne utiče samo stepen komunikacije nego i sposobnost pojedinca da prenese svoje ideje. U opštem slučaju ako projekat ima n zaposlenih ,onda postoji n(n-1)/2 parova koji možda žele da komuniciraju, kao i 2n-1 mogućih timova koji se mogu formirati za rad na manjim djelovima projekta. Prema tome imamo da projekat koji angažuje 10 ljudi ima 45 komunikacijskih kanala, i od kojih se može organizovati 1023 tima koji se mogu obrazovati radi razvijanja podsistema.Veoma bitna je i podjela odgovornosti i povjerenje unutar samog tima. Ekipa ljudi koja radi na jednom aspektu razvoja, mora imati povjerenje da će drugi članovi tima valjano obaviti svoj dio posla. Pored ovoga unutar tima mora doći do prihvatanja rezultata drugih ne ponavljajući njihov rad,tj. Ne kontrolišući ih.

A B Komunikacijski kanala sa dvije osobe

A

B CKomunikacijski kanala sa tri osobe

A

B C

D E

Komunikacijski kanala sa pet osoba

Slika 2.1 Komunikacijski kanali u sklopu projekta

Kontrola je posebno pitanje pri upravljanju projektom. Neki ljudi su dobri u prenošenju zadataka drugim , i taj aspekt u većini slučajeva zavisi i od zadovoljstva koje ljudi osjećaju prilikom obavljanja posla. Oni kojima ne prija da prisiljavaju kolege da pridržavaju rokova ili im ne prijaju sastanci sa naručiocem, nisu dobri kandidati za aktivnosti koje podrazumjevaju rukovođenje drugima.

Stilovi radaRazličiti ljudi imaju različite stilove za interakciju sa saradnicima radi razumjevanja problema koji u toku rada iskrsavaju. Tako da u startu možemo što se stilova tiče napraviti podjelu da postoje ljudi koji detaljno analiziraju sve mogućeinformacije prije donošenja odluke, dok sa

15

druge strane imamo kolege koji prilikom donošenja odluka se oslanjaju na svoje “dobre osjećaje”. Omiljene stilove rada možemo podjeliti po dva aspekta:način na koji se razmjenjuju misli i rađaju ideje I uticaj emocija na donošenje odluka.Tokom razmjene ideja, imamo ljude koje drugima saopštavaju svoja razmišljanja, dok drugi od kolega traže sugestije prije nego formiraju vlastiti stav. Po Carl Gustav Jung-u švajcarskom psihologu i psihijatru prve nazivamo ekstrovertima, a druge introvertima. Jasno je da stil komunikacije utiče na način interakcije sa drugim učesnicima u projektu. Slično tome intuitivne osobe zasnivaju svoje odluke na osjećaju i emotivnoj reakciji na probleme. Druge osobe su racionalne, i donose odluke prije svega ispitujući činjenice i pažljivo razmatrajući sve mogućnosti. Ovu raznolikost stilova najbolje možemo vidjeti na grafikonu XXXX.

INTUITIVAN

INTUITIVAN INTUITIVAN

INTROVERT EKSTROVERT

Pita druge Saopštava drugima

Priznaje osjćanje Priznaje osjećanj

RACIONALAN RACIONALAN

INTROVERERT EKSTROVERT

Pita druge Saopštava drugima

Odlučuje logično Odlučuje logično

RACIONALAN

Slika 2.2 Stilovi rada.

Racionalni ekstroverti teže da saopštavaju svoje ideje i ne dozvoljavaju da „osjećaj“ utiče na njihove odluke. Oni saopštavaju svojim kolegama samo ono što oni žele da znaju. Njihovo rasuđivanje se oslanja na logiku a ne na emocije.

Racionalni introverti takođe izbjegavaju emotivne rasprave, ali su skloni da dio vremena posvete razmatranju svih mogućih opcija i rješenja prije nego odnesu konačnu odluku. Racionalni introverti su skupljači informacija i oni se ne osjećaju ugodno pri donošenju odluke ukoliko nisu uvjereni da u rukama imaju sve činjenice.

Intuitivni ekstroverti većinu svojih odluka zasnivaju na emotivnom reakcijama, težeći da ih obrazlože drugima umjesto da traže argumente. Oni se u kreativnosti oslanjaju na intuiciju i veoma često na neobičajene prilaze rješavanja problema. Intuitivni introvert je takođe kreativan, ali tu kreativnost primjenjuje samo nakon prikupljanja dovoljno informacija na

16

osnovu kojih se može donjeti konačna odluka. Na grafikonu stilova rada gdje je stil komunikacije na horizontalnoj a stil odlučivanja na vertikalnoj osi,imamo da što je neko više ekstrovertan njegov grafikon pada više na desno i obratno, što je neko introvertan njegov profil će vući na lijevu stranu.

Organizacija projekta

Projektni timovi za razvoj i održavanje softvera ne sastoje se od ljudi koji nezavisno ili nekoordinisano rade. Naprotiv , članovi tima treba da su organizovani na način koji doprinosi što bržoj izradi kvalitetnih proizvoda. Izbor odgovarajuće strukture projekta zavisi od nekoliko činilaca, a to su:- biografija i stilovi rada članova tima- broj ljudi u timu- stilovi rukovođenja koje primjenjuje naručilac i razvojni tim.Dobri rukovodioci projekta su svjesvni ovih pitanja i traže članove tima koji su dovoljno fleksibilni za interakciju sa svim učesnicima bez obzira na stil rada.IBM je taj koji je prvi 1972 godine počeo da praktikuje da jednu organizacijsku strukturu čini tim koji na čelu ima glavnog programera. U pristupu sa glavnim programerom, samo jedna osoba je potpuno odgovorna za projektovanje i razvoj sistema. Svi drugi članovi tima podnose izvještaj glavnom programeru koji uvijek ima posljednju riječ prilikom donošenja svih odluka. Glavni programer nadgleda druge ,zadužen je za dizajin i raspoređivanje posla. Glavni programer ima i svog asistenta koji je zamjenik na projektu.

Slika 2.3 Organizacija tima sa glavnim programerom

17

Glavni programer

Pomoćnik glavnog programera

Stariji programeri Bibliotekar Tim za testiranjeAdministracija

Mlađi programeri

Iz svega navedenog jasno je da glavni programer mora da bude dobar u brzom donošenju odluka, tako da je glavni programer vjerovatno ekstrovert. Problem se može desiti ako su svi ostali članovi tima introverti jer tada nećemo imati sjajnu perspektivu projekta. Alternativa tome je ideja programiranja „bez egoizma“. Glavna karakteristika ove vrste programiranja jeste da odgovornost umjesto da bude koncetrisana u jednoj tački ona bude podjeljena na sve članove tima bez obzira na složenost njihovog posla. Ovakva struktura je više demokratskog tipa i razlučuje sam proces od pojednica.Pomenuta dva tipa organizacione strukture mogu i da se kombinuju tamo gdje je to prikladno ili neophodno.

3. POTREBAN RAD

18

Najvažnije pitanje koje se provlači kroz planiranje projekta jeste shvatanje koliko će projekta približno da košta. Prekoračenje troškova može da dovede do odustajanja od samog projekta, dok potcjenjivanje troškova implicira rad bez finansijske nadoknade.

Dobra procijena troškova pomaže rukovodiocu da utvrdi potreban broj ljudi za razvoj i rad na projektu. Iz budžeta projekta pokriva se više vrsta troškova : sredstav, osoblje, alati i metode. Pod ovim troškovima su obuhvaćena sljedeća sredstva: hardver, telefone, prostor, namještaj, grijanje ..itd. Međutim uvije mogu da se pojave prikriveni troškovi koji nisu očigledni ni rukovodiocu niti razvojnom timu. Na primjer neke studije ukazuju na to da jednom programeru je potrebno 9,3 kvadratnih prostora sa 2,8 kvadratnih metara horizontalnog prostora. Prostor takođe zahtjeva pregrade od poda do plafona radi zaštite od buke. DeMArco i Lister u svom radu sugerišu da programeri koji su oslobođeni od telefonskih poziva i nezvanih gostiju, pokazuju veću efikasnost od onih programera koji stalno prekidaju svoj rad.Kod većine projekata, najveći udio u troškovima ima uloženi rad. Moramo da odredimo koliko dana ljudskog rada mora da se uloži za dovršenje projekta. Uloženi rad sigurno predstavlja troškovnu komponentu sa najvećim stepenom neizvjesnosti. U prethodnim poglavljima vidjeli smo kako na potrebno vrijeme za dovršenje zadatka utiču stil rada, organizacija projekta, sposobnost, interesovanje, iskustvo, obuka i druge karaktersitke radnika. Pored ovoga kada grupa članovav tima radi i međusobno mora da komunicira i da se konsultuje, potreban uloženi rad se uvećava vremenom provedenim na sastancima i obuci.

Da bismo se pozabavili potrebom izrade tačnih procjena, softverski inžinjeri su razvili tehnike za snimanje odnosa između potrebnog rada i karakteristika radnika, projketnih zahtjeva, kao i drugih činilaca koji imaju uticaj na vrijeme, potrebni rad i troškove razvoja softverskog sistema.Postoje mnoge tehnike i metode procjene potrebnog rada kao što su:

Stručni sud koji počiva na stručnoj procijeni rukovodioca zasnovanoj na iskustvu na sličnim projektima. On ima sposobnost tačnog predviđanja troškova zasnovanu na kompetenciji, iskustvu, objektivnosti stečene na sličnim projektima.

Algoritamske metode gdje su istraživači napravili model koji izražava odnos između potrebnog rada i faktora koji na njega utiču. Ovakvi modeli su obično opisani pomoću matematičkih jednačina u kojiam je napor funkcija, a više činilaca (iskustvo, veličina i tip aplikacije) nezavisno promjenjive .Većina ovih modela potvrđuje to da je najuticajniji faktor, veličina projekta.

Metode mašinskog učenja kao pomoćnim sredstvom za generisanje dobrih prognoza ima jdnu od tehnika mašinskog učenja“rasuđivanje na osnovu slučaja“,tj. CBR (Case-Based Reasoning) koja se bavi predviđanjem po analogiji. Ova tehnologija se koristi u krugovima koji se bave vještačkom inteligencijom.

4. UPRAVLJANJE RIZICIMA

19

Prije svega potrebno je naglasiti da nema jedinstvene definicije rizika. Razlog tome je postojanje mnogobrojnih vrsta rizika i svaka od njih bi se mogla na drugi način objasniti. Iako nije dogovorena ta opšta definicija, postoje zajednički elementi u svim definicijama a to su izloženost, neizvjesnost i gubitak.

Najkraće se može reći da rizik predstavlja neizvjesnost ishoda događaja. Drugačije se može opisati kao vjerovatnoća da će se opasnost (hazard) pretvoriti u katastrofu

Rizik razlikujemo od drugih događaja u projektu na osnovu tri pokazatelja:

Gubitak po događaju. Određeni događaj mora da stvori situaciju u kojoj se projektu dešava nešto negativno: gubitak vremena, kvaliteta, novca, kontrole, razumevanja..itd. Na primjer ako se zahtjev drastično izmjene nakon što je projekat već urađen onda sam projekat može da pati od gubitka kontrole i razumevanja, ako su novi zahtjevi vezani za funkcije ili osobine koje nisu bliske projektnom time. Takođe radikalna promjena u zahtjevima vjerovatno dovodi do gubitka vremena i novca ako projektna rješenja nisu dovoljno fleksibilna da mogu brzo i lako da se izmjene.Gubitak koji rizik nosi naziva se uticaj rizika.

Izvjesnost pojave događaja. Moramo imati bar neku predstavu o vjerovatnoći pojave razmatranog događaja. Na primer, pretpostavimo da se projekat razvoja na jednoj magini i da treba, nakon što se sistem potpuno iztestira da bude prenjet na drugu. Ako je druga mašina potpuno novi model koji dobavljač tek treba da isporuči, nužno je procjeniti vjerovatnoću da ona ne bude isporucena na vrjeme. Izvjesnost pojave rizika, iskazana vrjednošću od 0 (što je nemoguć događaj) do 1 (izvjestan događaj), naziva se vjerovatnoća rizika. Kada je vjerovatnoća rizika jednaka 1, tada rizik predstavlja problem jer je će se vjerovatno i desiti.

Stepen do kojeg je moguće izmjeniti ishod. Za svaki rizik, moramo odrediti šta je moguće učiniti na smanjenju ili izbjegavanju njegovog uticaja. Kontrola rizika obuhvata skup radnji koje se preduzimaju u cilju redukovanja iii eliminisanja rizika. Na primjer ako zahtjevi mogu da se izmjene nakon dizajna, uticaj izmjene je moguće smanjiti fleksibilnijim projektnim rješenjima. Ako druga mašina još nije spremna nakon testiranja softvera, možemo da pronađemo drugi model koji ima istu funkcionalnost i performanse i da na njemu izvršavamo softver do isporuke novog modela.

Postoje dva glavna izvora rizika: opšti rizici i rizici koji su specifični za razmatrani projekat. Opšti rizici predstavljaju rizike koji su zajednički za sve softverske projekte, kao što su recimo pogrešno shvatanje zahtjeva, odlazak ključnih izvršilaca, ili nedovoljno vrijeme za testiranje. Rizici specifični za projekat predstavljaju prijetnje koje su poslijedica slabih tačaka konkretnog projekta. Na primer, dobavljač je obećao da će isporučiti mrežni softver do određenog datuma, ali postoji rizik da do isporuke neće doći na vrijeme.

4.1 Aktivnosti upravljanja rizicima20

Upravljanje ruzicima sastoji se od više važnih koraka. Prvo se procjenjuje rizik datog projekta, kako bismo vidjeli šta se sve može desiti tokom razvoja ili održavanja projekta. Procijena se sastoji od sljedeće tri aktivnosti:- Identifikacija rizika,- Analiza rizika,- Dodjeljivanje prioriteta svakom od njih.

Za identifikaciju rizika možemo da koristimo više različitih tehnika.Ako imamo da je sistem koji gradimo na neki način sličan nekom od prethodnih sistema, znači da već imamo spisak mogućih problema. Analizom tog spiska lako možemo ustanoviti izglede da novi sistem bude kopija starog sistema te da su im rizici isti. Ukoliko se radi o novom sistemu,onda je potrebno uraditi raščlanjivanje procesa na manje dijelove te za manje dijelove sistema uraditi analizu ili predviđanje problema koji mogu da iskrsnu.Na kraju treba analizirati identifikovane rizike, sa ciljem da se shvati, način, uzrok, i potencijalno mjesto pojave rizičnih događaja.Po identifikaciji svih rizika, dodjeljujemo im prioritete na osnovu vlastitog shvatanja njihove prirode. Ovde treba obratiti pažnju da inače ograničene resurse usmjerimo na rizike od kojih realno postoji i najveća prijetnja. Izloženost rizika se računa na osnovu vjerovatnoće pojave događaja koji nosi određeni rizik i poslijedice tog rizika. Ova analiza nam pomaže da navedemo rizike prema redoslijedu prioriteta, gdje je rizik koji nas najviše zabrinjava dodjeljen najviši prioritet. Poslije ovoga moramo preuzeti korake za kontrolu rizika, koji rizike ne mogu eliminisati ali ga mogu svesti na najmanju moguću mjeru. Tako da imamo tri vrste strategije za umanjenje rizika a to su:- Izbjegavanje rizika- Prenošenje rizika,dodjeljivanje rizika drugim sistemima ili ugovaranje osiguranja radi pokrivanja finansijskog gubitka- Podrazumjevanje rizika.Sve navedene mjere su dio odluke u sklopu plana za upravljanje rizicima, tako da i naručilac i razvojni tim imaju uvid u načine izbjegavanja problema.

5. PLAN PROJEKTA

21

Kako bi se naručiocima što bolje prezentovali rezultati analize rizika i predložilo adekvatno upravljanje njima, kao i predviđanje troškova u vezi sa projektom, rokove i organizaciju, obično pravimo plan projekta. Plan u pisanom obliku sadrži korisnikove potrebe/zahtjeve i naše namjere za zadovoljenje tih potreba/zahtjeva. Naručilac analizira plan da bi dobio informacije o aktivnostima tokom razvojnog procesa, što mu omogućuje da lakše prati projekat. Dobar plan treba da sadrži sljedeće elemente: 1. Obim projekta, 2. Rokove projekta, 3. Organizaciju projektnog tima, 4. Tehnički opis sistema, 5. Tehnike, postupci i alati koji su potrebni za projekat, 6. Plan osiguranja kvaliteta, 7. Plan upravljanja konfiguracijom, 8. Plan dokumentovanja, 9. Plan upravljanja podatcima,10. Plan upravljanja resursima,11. Plan testiranja,12. Plan obuke,13. Plan bezbjednosti,14. Plan upravljanja rizicima,15. Plan održavanja.

Obim definiše granice sistema ,tj. šta će sve biti obuhvaćeno sistemom. On zasigurno garantuju naručiocu da samo razumjeli šta se od projekta zahtjeva. Rokovi se iskazuju putem strukture posla, miljokaza i vremenskih rokova. Plan projekta pokazuje članovima tim kako trebaju biti organizovani i šta se od njih očekuje. Izrada tehničkih opisa primorava nas primorava nas da formulišemo odgovore i razmotrimo probleme dok predviđamo dalji tok projekta. Tehnički opis sadrži hardver i softver, kao i interfejse, opremu, prevodioce..itd. Plan takođe navodi na standarde koji se moraju koristiti a to su:-algoritmi,-alati,-tehnike pregleda i inspekcije,-jezici za kodiranje,-tehnike testiranja.

U velikim projektimam imamo primjere postojanja posebnog plana za obezbjeđenje kvaliteta, u kojome se opisuje kako pregledi, inspekcije, testiranje i druge tehnike pomažu pri procjeni kvaliteta i obezbjeđuju da on odgovara potrebama naručioca.Tokom razvoja nastaje veći broj dokumenata, posebno u slučaju velikih projekata kod kojih informacija o projektnim rješenjima mora da bude dostupna svim članovima projektnog tima.

Plan pored svega ovoga treba da ima ulazne podatke, proračune i izlazne podatke, pa stoga plan projketa treba da objasni inačin prikupljanja tih podataka.Konačno, ako će projektni tim da održava sistem i poslije isporuke, plan projekta treba da razmotri i odgovornost za izmjene koda, popravke hardvera i ažuriranje prateće dokumentacije i materijala za obuku.

6. MODELI PROCESA I UPRAVLJANJE PROJEKTOM

22

Do sada smo vidjeli kako različiti aspekti projekta mogu da utiču na potreban rad, troškove i vremenske rokove kao i na sadržane rizike. Najuspješnije rukovodioci projekta jesu oni koji tehnike rukovođenja projektom prilagođavaju posebnim karakteristikama neophodnih resursa odabranom procesu i dodjeljenim ljudima.

6.1. Upravljanje u paketima

Kompanija Digital Equipment Corporation utrošila je više godina na razvoj sistema Alpha AXP a nova arhitektura sistema i prateci proizvodi učinili su od njega najveći projekat u njohovoj istoriji. Softverski dio je obuhvatao izradu četiri operativna sistema i 22 grupe za inžinjere softvera koji su radili na projektovanju alata za migraciju, mrežnih sistema, prevodilaca, baze podataka okruženja za integraciju, kao i same aplikacije. Za razliku od drugih razvojnih projekata, glavni problemi sa projektom Alpha bio je prerano dostizanje miljokaza. Prema tome, poucno je da vidimo kako je projektom upravljano i kakav je bio uticaj procesa upravljanja na finalni proizvod.Tokom razvoja rukovodioci projekata razvili su model koji je prisvojio četiri principa, i koji je nazvan Enrollment Management ili prijemno upravljanje:- uspostavijanje dovoljno široke zajedničke vizije;- potpuno dodjeljivanje zadataka i dobijanje posebnih saglasnosti učesnika;- energično vršenje inspekcija i objezbeđivanje povratnih informacija;- potvrdu svakog unapređenja i učenje tokom napretka programa

lično poslovni ciljevijavno ciljevi projekta

Pregled povjerenjePodsticanje odgovornost

Slika 6.1.Modeli prijemnog upravljanja

Slika 6.1 Ilustruje predstavljeni model. Vizija je korišćena za prijem odgovarajućih programa tako da svi dijele zajedničke ciljeve. Svaka grupa ili podgrupa projekta definisala je sopstvene ciljeve zavisno od globalnih ciljeva navedenih za projekat, uključujući

23

Prihvatanje učenja Vizija prijem

Inspekcija Angažovanje Podrška Povjerenje

poslovne ciljeve kompanije. Dalje, kako su rukovodioci razvijali planove, oni su provjeravali zadatke grupama, tražeći od njih da se angažuju prilikom formulisanja zadataka i da komentarišu i zadatke i nametnuta ograničenja u vezi sa rokovima. Svaki od rezulatat bio je mjerljiv i identifikovan sa određenim vlasnikom(odgovornom osobom za njegovo sprovođenje). Vlasnik nije nužno bio osoba koja je obavljala posao, već je predstavljao osobu koja je odgovorna da se posao uradi do kraja. Rukovodioci su imali zadatak konstantnih inspekcija kako bi se zadatak završio na vrijeme.Koordinisanje svih hardverskih i softverskih grupa bilo je teško, a rukovodioci sushvatili da treba da nadgledaju kako tehničke događaje, tako i događaje u projektu.

6.2. Model vodopada

Model vodopada (engleski waterfall model) nastao je u ranim 70-tim godinama 20. vjeka, kao neposredna analogija s procesima iz drugih inžinjerskih struka (na primjer,mostogradnja). Softverski process je građen kao niz vremenski odvojenih aktivnosti u skladu sa slikom 6.2

dokument o zahtjevima

design sistema

moduli

sistem

Slika 6.2: Softverski proces prema modelu vodopada

Prednosti modela vodopada su sljedeće:• Model omogućuje lagano praćenje stanja u kojem se softverski proces nalazi.

24

Specifikacija

Oblikovanje (design)

Programiranje i testiranje modula

Integrisanje modula i testiranje sistema

Puštanje u rad i održavanje

• Model je dobro prihvaćen od managementa.Mane modela vodopada su sljedeće:

• Navedene faze u praksi je teško razdvojiti, pa dolazi do naknadnog otkrivanja grešaka i vraćanja u prethodne faze.• Zbog tendencije da se zbog poštovanja rokova u odredenom trenutku “zamrzne” pojedina faza, može se desiti da je sistem u trenutku puštanja u rad već neažuran i zastario.Model treba koristiti za velike sisteme gdje postoje jasni zahtjevi.

6.3. Model evolucijskog razvoja

Model evolucijskog razvoja (engleski evolutionary development) nastao je kao protuteža modelu vodopada.

Na osnovu približnog opisa problema razvija se polazna verzija sistema koja se pokazuje korisniku.

Na osnovu korisnikovih primjedbi, ta polazna verzija se poboljšava, opet pokazuje, itd. Nakon dovoljnog broja iteracija dobiva se konačna verzija sistema. Unutar svake iteracije, osnovne aktivnosti se obavljaju simultano i ne daju se razdvojiti.

Prednosti modela evolucijskog razvoja su sljedeće:• Model je u stanju proizvesti brzi odgovor na zahtjeve korisnika.• Postoji mogućnost da se specifikacija postepeno razvija u skladu sa sve boljim korisnikovim razumijevanjem problema.

Mane modela evolucijskog razvoja su sljedeće:• Proces nije transparentan za menadžere, naime oni ne mogu ocijeniti koliki dio posla je napravljen i kad će sistem biti gotov.• Konačni sistem obično je loše struktuisan zbog stalnih promjena, te je nepogodan za održavanje.• Zahtijevaju se posebni alati i natprosječni softverski inžinjeri.

Model se uspješno koristi za razvoj web sjedišta, te za male sisteme s kratkim životnim vijekom, pogotovo za sisteme s nejasnim zahtjevima.

6.4. Model formalnog razvoja

Model formalnog razvoja (engleski formal systems development) zasniva se na korištenju takozvanih formalnih metoda za razvoj softvera. Zahtjevi se precizno definišu na formalni način, korištenjem nedvosmislene matematičke notacije. Zatim se ta formalna specifikacija transformiše do programa, nizom koraka koji čuvaju korektnost. Cijeli proces prikazan Slikom 6.4.

Slika 6.4: Proces formalnog razvoja softvera.

Prednosti modela formalnog razvoja su sljedeće:• Nakon izrade formalne specifikacije, sve daljnje faze razvoja softvera mogle bi seautomatizovati.

25

Neformalna spec.

Formalna spec. Formalne transformacije

Integrisanje i testiranje sis.

• Postoji “matematički” dokaz da je program tačna implementacija polazne specifikacije; nema velike potrebe za testiranjem.

Mane modela formalnog razvoja su sljedeće:• Izrada formalne specifikacije zahtijeva velik trud i znanje.• Dokazi korektnosti transformacija postaju preglomazni za iole veće sisteme.• Korisnici ne mogu pratiti razvoj.

• Postojeći specifikacijski jezici nisu pogodni za interaktivne sisteme.Model se za sada relativno malo koristi u praksi, te se preporučuje jedino za sisteme gdje se zahtijeva izuzetno velika pouzdanost i sigurnost. Moguće je da će se model znatno više koristiti u budućnosti ukoliko se razviju bolji specifikacijski jezici te bolji alati za automatske transformacije.

Z A K L J U Č A K

26

Softverski projekat se po mnogo čemu razlikuje od klasičnog tehničkog projekta kao što jegradnja mosta ili broda.• Prizvod je “neopipljiv”. Teško je vidjeti rezultat. Teško je procijeniti koliki dio posla je obavljen.

Menadžer se mora pouzdati u apstraktne dokumente.• Nema standardnog procesa. Postoje razne metode i alati, no ne zna se šta je najpogodnije uzadanim okolnostima.• Projekat je obično “neponovljiv”. Stara iskustva obično nisu primjenjiva. Pojavljuju se nepredvideni problemi. Tehnologija se brzo mijenja.Zbog ovih osobina, upravljanje softverskim projektom je izuzetno težak menadžerski zadatak, te zahtijeva izuzetno dobrog menadžera Poslovi softverskog menadžera medu ostalim uključuju sljedeće:• pisanje prijedloga projekta,• procjenjivanje troškova projekta,• planiranje i praćenje projekta,• izbor i ocjenjivanje saradnika,• pisanje izvještaja i prezentacija..Planiranje i praćenje projekta predstavlja redovan, svakodnevni i najegzaktniji posao softverskog menadžera. Planiranje i praćenje uključuje sljedeće:• definisanje projektnih aktivnosti, njihovog trajanja i meduzavisnosti,• odredivanje kalendara početka i završetka svake aktivnosti,• rasporedivanje ljudi i drugih resursa na aktivnosti,• praćenje izvršenja aktivnosti,• povremena revizija svih parametara.

Menadžer treba posvetiti posebnu pažnju kritičnim aktivnostima, zato jer bi njihovo kašnjenje uzrokovalo kašnjenje cijelog projekta.Kroz kompletan seminarski rad provlači se vrijeme kao glavni faktor uspješnog izvršenja ili ne dostizanja traženih rezultata.Vrijeme je jako bitno I veoma utiče na zadovoljstvo kupca/naručioca koji zahtjeva da se držimo dogovorenih termina.Ovaj rad bi završio vašom rečenicom sa predavanja u čiju tačnoszt sam se uvjerio bezbroj puta u obavljanju svog posla kao projektnog menadžera , a to je da “kašnjenje u bilo kojoj tački u odnosu na miljokaze bilo da su to obični redovni sedmični sastanci imaju za rezultat tačno toliko kašnjenje čitavog projekta”.

27

L I T E R A T U R A

Softversko inzenjerstvo:Teorija i praksa/Shari Lawrence Pfleeger,Joanne M.AtleeSoftversko inzenjerstvo: Robert Manger

28