Planiranje I Upravljanje Projektom

LOGO
PRINCIPI RAZVOJA SOFTVERA
3. Planiranje projekta i upravljanje njime
Sadraj nastavne jedinice

3. Planiranje projekta i upravljanje njime

Praenje napretka projekta. Osoblje i organizaciju projekta Uloeni rad i rokovi Modelovanje procesa i planiranje projekta
www.fit.unimediteran.net
3.1. Praenje napretka

Softver je korstan ukoliko realizuje eljenu funkciju ili prua traenu uslugu. Naruioca softvera u procesu pregovaranja interesuje: Da li razumemo njegov problem i potrebe? Da li moemo projektovati sistem koji e reiti problem? Koliko nam je vremena potrebno da razvijemo sistem? Kolika je cena razvoja softvera? Odgovori na postavljena pitanja zahtevaju postojanje dobro osmiljenih rokova za aktivnosti na projektu. Projektni rokovi predstavljaju vremenski period zapoinjanja i zavretka aktivnosti i opisuju razvojni ciklus nekog softvera u okviru odreenog projekta, sa fazama ili etapama svake pojedinane aktivnosti za koje se procenjuju potrebni resursi i vreme trajanja.
3

Posao zapoinje razgovorom sa naruiocem i potencijalnim korisnicima. Proverava se njihovo zadovoljenje naim razumevanjem njihovih elja i potreba. Definiu se meuproizvodi tj. stavke koje naruilac oekuje tokom razvoja projekta: Dokumenti Demonstracija funkcija Demonstracija podsistema Demonstracija tanosti Demonstracija pouzdanosti, bezbednosti ili performansi Utvruju se aktivnosti koje e se sprovesti u cilju realizacije definisanih elemenata isporuke. Pri tome se koriste neke od tehnika za modelovanje procesa
4

Odreeni dogaaji se deklariu kao miljokazi i slue kao pokazatelji napredovanja projekta. Aktivnost predstavlja deo projekta koji se odigrava tokom nekog vremenskog perioda. Miljokaz predstavlja zavretak aktivnosti u odreenom trenutku. Paljivim ispitivanjem projekta, moe se podeliti razvoj na niz faza. Svaka faza se sastoji od koraka, a svaki korak na niz aktivnosti. Ovo analitiko razlaganje, naruiocu prua viziju svega to je obuhvaeno projektom. Projektni tim i naruioc e bolje shvatiti ta je sve obuhvaeno razvojem ili odravanje sistema.

Ovakva analiza se opisuje kao proces generisanja strukture poslova (work breakdown structure) u okviru projekta. Naruioc eli da ima uvid u napredak projekta u bilo kom trenutku razvoja projekta. Aktivnosti i miljokazi predstavljaju elemente koje naruilac i razvojni tim koriste za praenje projekta. Svaka aktivnost se opisuje sa etri parametra: Prethodnik, opisuje skup uslova koji omoguavaju zapoinjanje aktivnosti. Trajanje, vreme potrebno za kompletiranje aktivnosti Krajnji rok, datum do kojeg aktivnost mora biti okonana Krajnja taka, obino miljokaz, oznaava da je aktivnost zavrena

Struktura poslova ne govori o meuzavisnostima pojedinih grupa poslova ili delova projekta. Radi opisivanja zavisnosti, crta se graf aktivnosti. vorovi grafa predstavljaju miljokaze projekta, a grane koje povezuju vorove predstavljaju sadrane aktivnosti. Graf aktivnosti obezbeuje vizuelizaciju znaajnih karakteristika projekta, sa jasnim pregledom koje su aktivnosti uslovljene zavretkom prethodnih. Vano je uoiti da grafovi aktivnosti zavise od shvatanja paralelne prirode zadataka.

Dodavanjem informacija o proceni vremena koje je potrebno za dovretak svake aktivnosti, grafovi postaju znaajno kvalitetniji. Za aktivnost (granu grafa) dodajemo broj koji predstavlja procenjeno vreme realizacije. Grafiki opis projekta govori mnogo o vremenskim rokovima. Analizom putanja meu miljokazima projekta, metodom kritine putanje (Critical Path Method), mogu se odrediti aktivnosti koje su najkritinije za zavretak projekta na vreme. Za svaku aktivnost definisanoj grafom moe se izraunati stvarno potrebno vreme i raspoloivo vreme. Stvrano potrebno vreme je vreme potrebno za okonanje aktivnosti. Raspoloivo vreme predstavlja vreme koje je u okviru vremenskih rokova raspoloivo za njeno okonanje.
8

Postoje mnogi alati koji se koriste za praenje napretka projekta. Postoje jednostavni, sloeni i visokosofisticirani alati sa kompleksnim grafikim predstavama. Mnogi sofverski sistemi za upravljanje projektima crtaju strukturu posla i pomau rukovodiocu projekta u praenju napretka po svakom koraku i aktivnosti. Mnogi od njih imaju mogunost crtanja gantograma tj. Grafiki prikaz projekta na kom su aktivnosti prikazane paralelno, dok je stepen dovrenosti oznaen bojom ili sliicom. Ovakvi dijagrami pomau rukovodiocima da razumeju koje se aktivnosti mogu izvoditi paralelno, i da se uoi koje aktivnosti pripadaju kritinoj putanji.
3.2. Osoblje na projektu

Da bi se utvrdili rokovi za projekat i procenili rad i trokovi, mora se znati: Broj ljudi koji e raditi na projektu Poslovi na kojim e biti angaovani Specijalnosti svake angaovane osobe Iskustvo na ranijim projektima za svaku osobu
10

Za kljune aktivnosti procesa razvoja projekta, neophodno je angaovati adekvatno osoblje: Analiza zahteva Dizajn sistema i programa Implementacija programa Testiranje Obuka Odravanje Osiguranje kvaliteta
11

Dodeljivanje radnika svakoj aktivnosti pre svega zavisi od veliine projekta, iskustva i obuenosti osoblja. Dodelom razliitih odgovornosti razliitim grupama ljudi, omoguava se provere i izbalansiranost. Ovim se omoguava otkrivanje greke u ranim fazama razvoja. Na primer, testeri, projektanti i programeri ne treba da budu isti radnici. Nakon donoenja odluke o ulogama i broju izvrilaca pojedinih uloga, neophodno je doneti odluku o ljudima koje e uloge izvravati.
12

Podobnost osoba koje e biti zaduene za pojedine uloge u razvoju projekta donosimo analizirajui: Sposobnost izvravanja posla Interesovanje za posao Iskustvo na razvoju slinih softvera Isustvo sa alatima, jezicima za razvoj i tehnikama Obuenost Sposobnost komunikacije s drugim lanovima razvojnog tima Sposobnost podele odgovornosti Svaka od navedenih karakteristika utie na sposobnost i produktivnost pojedinca da obavlja odreeni posao. Varijacije u karekteristikama objanjava na primer zato jedan programer moe da napie zadati program za jedan dan, dok je drugom potrebna jedna nedelja
13

Deo komunikacije u okviru softverskog projekta se odigrava na sastancima. Sastanci modu da imaju negativne posledice za projekat. Uobiajne zamerke u vezi sa sastankom su: Svrha sastanka nejasna Uesnici sastanka su nepripremljeni Odsutnost vanih ljudi Skretanje sa teme rasprave Meusobno raspravljanje o nebitnim stvarima Odluke donete na sastanku se ne sprovode Rukovodilac treba jasno da saopti ko treba da prisustvuje sastanku Sastanak treba da ima dnevni red u pisanoj formi Predsedavajui preuzima odgovornost za usmeravanje diskusije
14

Razliiti ljudi imaju razliite stilove za interakciju sa saradnicima radi razumevanja problema. Neke osobe detaljno analiziraju sve mogue opcije prije donoenja odluke, dok se drugi oslanjaju na dobar osjeaj. Raznolikost stilova rada moemo posmatrati kroz stil komunikacije i stil odluivanja.
INTUITIVAN
INTROVERT
INTUITIVAN INTROVERT: Pita dugo Priznaje oseanje RACIONALAN INTROVERT: Pita dugo Odluuje logino
INTUITIVAN EKSTROVERT: Saoptava drugima Priznaje oseanje RACIONALAN EKSTROVERT: Saoptava drugima Odluuje logino
EKSTRAERT
15 RACIONALAN

Popularan nain organizacije strukture projekta je sa glavnim programerom koja je prvi put koriena u IBM. Samo jedna osoba je potpuno odgovorna za projektovanje i razvoj sistema. Svi drugi lanovi tima podnose izvetaj glavnom programeru. Glavni programer ima poslednju re prilikom donoenja svih odluka. Mogue je formirati tim za realizaciju nekog posebnog zadatka. Glavni programer mora imati sposobnost brzog donoenja odluke.
16

Alternativa metodi glavnog programera je metoda bez egoizma. Ovaj pristup posmatra svakog uesnika kao potpuno ravnorpavno Struktura tima poiva na demokratskim principima gde se lanovi tima izjanjavaju o odlukama, bilo da se tiu projektnih reenja ili tehnika za testiranje. Koja struktura je pogodnija? Ukoliko vie ljudi uestvuje na projektu, vea je potreba za formalnom organizacijom. Ukoliko se radi o projektima sa velikim stepenom izvesnosti, stabilnosti, uniformnosti, efikasnija je hijerarhijska struktura. Ako projekat ukljuuje znaajan stepen neizvesnosti, demokratiniji pristup je bolji
17
3.3. Potreban rad

Jedno od prelomnih gledita planiranja u upravljanju projektom je ocenjivanje koliko e projekat da kota Prekoraenje trokova moe dovesti do odustajanja od projekta, dok potcenjivanje moe dovesti do neisplativosti. Predvianje trokova, rokova i potrebnog rada moraju se uraditi u ranim fazama ivotnog ciklusa projekta. Direktno utiu na dodeljivanje resursa i mogunost realizacije. Procene treba revidirati vie puta tokom realizacije projekta. Lederer i Prasad (1992) su istraivali na koji se nain procenjuju trokovi u 115 razliitih organizacija. 35% ispitanih organizacija su imale umereno nezadovoljavajui ili vrlo nezadovoljavajue procene.
18
3.3. Potreban rad

Kljuni uzroci loih procena su: este izmene od strane korisnika Predvieni zadaci Korisnici ne razumeju svoje zahteve Nedovoljna analitinost prilikom izrade procene Loa koordinacija tokom projektovanja, administracije i drugih funkcija Nedostatak adekvatnih metoda za procenjivanje
19
3.3. Potreban rad

Aspekti projekta koji imaju kljunu ulogu za dobru procenu su: Sloenost predloenog reenja Integracija sa postojeim reenjima Sloenost pojedinanih programa u sistemu Veliina sistema izraena brojem funkcija ili programa Sposobnost lanova projektnog tima Oekivana uestanost ili obim moguih izmena u zahatevima Iskustvo projektnog tima u radu sa programskim jezicima Sistem za upravljanje bazom podataka Broj lanova projektnog tima
20
3.3. Potreban rad

Mnoge metode za procenu potrebnog rada zasnivaju se na strunoj proceni. Neformalne metode, se zasnivaju na iskustvu rukovodioca sa slinim projektima. Njena tanost zasnovana je na kompetencijama, iskustvu, objektivnosti i opaanju onog ko vri procenu. Ovakava ocena predstavlja priblinu ocenu rada potrebnu za izgradnju celokupnog sistema. Kompletna ocena se dobija analizom odozdo nagore ili odozgo nadole.
21
3.3. Potreban rad

Veoma esto se za procenu potrebnog rada koriste analogije. Na osnovu slinosti predmetnog projekta sa prethodnim uspeno zavrenim projektom moe se izvriti procena rada. Ako je sistem A slian sistemu B, onda cena izrade sistema A treba da bude slina ceni izrade sistema B. Proces upravljanja analogijom se moe formalizovati ako od nekoliko strunjaka traimo da naprave tri pretpostavke: Pesimistiku (x) Optimistiku (y) Najverovatniju (z) Procena srednje vrednosti beta raspodele verovatnoe rauna se po formuli (x+4*z+y)/6
22
3.3. Potreban rad

Metod Delfi koristi strunu procenu da drugaiji nain. Od strunjaka se trai da u tajnosti naprave pojedinana predvianja, koristei postupak po vlastitom izboru. Zatim se rauna srednja procena i ona se predstavlja grupi. Svaki strunjak ima mogunost da ako to eli, revidira svoju procenu. Proces se ponavlja sve dok nijedan strunjak ne elida izvri reviziju. Varijacije Neki korisnici metode Delfi, raspravljaju o srednjoj proceni, pre nego to se napravi nova procena, dok u ostalim trenucima ne dozvoljavaju raspravu. Nekada se omoguava da anonimna obrazloenja procene svih eksperata cirkuliu izmeu njih.
23
3.3. Potreban rad

Istraivai su napravili modele koji izraavaju odnos izmeu potrebnog rada i faktora koji na njega utiu. Ovi modeli se opisuju pomou jednaina, u kojima je napor funkcija , a inioci (iskustvo, veliina, tip aplikacije) nezavisne promenljive. Veina modela potvruje da je veliina projekta najjuticajniji faktor u jednainama u kojim se rad izraunava kao E=(a+bSc)m(x)
S je procenjena veliina sistema, a, b i c su konstante x je vektor faktora trokova xq do xn m je korekcioni faktor koji zavisi od njih
24
3.4. Upravljanje rizicima

Rukovodioci softverskih projekata preduzimaju sve korake kako bi osigurali da se projekti zavre na vreme i u okviru ogranienja u pogledu rada i trokova. Upravljanje projektom podrazumeva mnogo vie od praenja rada i vremena. Rukovodioci moraju odrediti da li neki neeljeni dogaaj moe da se desi tokom razvoja ili odravanja. Moraju napraviti planove izbegavanja tih dogaaja, a ako su neizbeni, plan minimizovanja negativnih posledica. Rukovodioci moraju upravljati rizicima kako bi bili u stanju upravljati svojim projektom
25

Rizik se razlikuje od drugih dogaaja na osnovu tri pokazatelja: Uticaj rizika. Odreeni dogaaj mora da stvori situaciju u kojoj se projektu deava neto negativno: gubitak vrmena, kvaliteta, novca, kontrole, razumevanja itd. Verovatnoa rizika. Mora se imati predstava o verovatnoi pojave razmatranog dogaaja. Kontrola rizika. Predstavlja skup radnji koje se preduzimaju u cilju redukovanja ili eliminisanja rizika Efekte identifikovanih rizika moemo kvantifikovati mnoenjem uticaja rizika sa njegovom verovatnoom, ime dobijamo tzv. Izloenost riziku Na primer: ako je verovatnoe rizika 0.3, a troak projektovanja po novim zahtevima 50.000 dolara, onda je izloenost riziku 15.000 dolara
26

Postoje dva glavna izvora rizika: Opti rizici. Predstavljaju rizike koji su zajedniki za sve softverske projekte (pogreno shvatanje zahteva, odlazak kljunih izvrilaca, nedovoljno vremen za testiranje ...) Rizici specifini za projekat. Predstavljaju pretnje koje su posledica slabih taaka konkretnog projekta. Npr dobavlja je obeao isporuiti mreni softver do odreenog datuma, ali postoji rizik da do isporuke ne doe na vreme.
27

Upravljanje rizicima obuhvata vie koraka. Prvo se procenjuje rizik, kako bi se razumelo ta se sve moe desiti tokom razvoja sistema Procenjivanje se sastoji od tri aktivnosti: identifikovanja rizika, analize rizika i dodeljivanja prioriteta svakom riziku Za identifikaciju rizika se koriste vie razliitih tehnika U toku analize identifikovanih rizika, treba razumeti nain, uzrok i potencijalno mesto pojave razliitih dogaaja. Odreivanju prioriteta rizicima obavlja se na osnovu shvatanja njegove prirode
28

Drugi korak je kontrola rizika, koja obuhvata umanjenje rizika, planiranje rizika i razreavanje rizika. Za umanjenje rizika postoje tri strategije Izbegavanje rizika, izmenom zahteva u vezi sa peroformansom ili funkcionalnoi Prenoenje rizika, dodeljivanjem rizika drugim sistemima Podrazumevanje rizika, prihvatanje i kontrola u okviru resursa projekta Korisno je kreirati plan za upravljanje rizikom kako bi naruilac i razvojni tim imali uvid u nain za izbegavanje problema, i u postupke u sluaju njihove pojave. Naohodno je i nadgledati projekat uz periodinu procenu rizika, verovatnoe pojavljivanja i mogueg uticaja
29

Identifikacija rizika Procenjivanje rizika
Analiza rizika
Upravljanje rizikom
Dodeljivanje prioriteta
Smanjenje rizika Planiranje upravljanja rizicima Razreavanje rizika
Kontrola rizika
Slika 3.15. Koraci urpavljanja rizicima

30
3.5. Plan projekta

Da bi se naruiocima predstavili trokovi u vezi projekta, rokovi, organizacija, kao i rezultati analize rizika i upravljanje njima, obino se pravi plan projekta. Plan u pisanom obliku sadri korisnikove potrebe/zahteve i nae namere vezane za zadovoljenje tih potreba/zahteva. Naruilac analizira plan da bi dobio infomracije o aktivnostima tokom razvoja procesa, to mu omoguuje da lake prati napredak projekta. Plan moe biti osnov za potvrdu uinjenih pretpostavki, posebno u delu trokova i rokova.
31
3.5. Plan projekta

Dobar plan projekta mora da ima sledee elemente: 1. Obim projekta, kojim se definie ta e biti obuhvaeno sistemom i potvruje razumevanje korisnikih zahteva. 2. Rokove projekta, koji se prikazuju strukturom posla, miljokazima, i vremenskim jedinicama, kako bi se omoguilo adekvatno praenje napretka projekta 3. Organizaciju projektnog tima, odreuje osobe, uloge, nain i obim njihovog angaovanja 4. Tehniki opis predloenog sistema, sadri hardver, softver, prevodoce, interfejse i softver posebne namene 5. Standarde koji se u projektu koriste, postupke i predloene alate i tehnike 6. Plan osiguranja kvaliteta, kojim se opisuju pregledi, inspekcije, testiranja u cilju procene i obezbeenja kvaliteta
32
3.5. Plan projekta

Dobar plan projekta mora da ima sledee elemente: 7. Plan upravljanja konfiguracijom, pomae uspostavljanje bolje kontrole nad vie primeraka softvera. Plan ukazuje naruiocu nain praenja izmena u zahtevima, dizajnu, kodu, planovima testiranja i dokumentaciji. 8. Plan dokumentovanja, definie nain dokumentovanja, koja dokumenta trebaju biti kreirana, kada se izrauju i nain izmene tih dokumenata 9. Plan upravljanja resursima, definie nain korienja resursa. 10. Plan testiranja, obezbeuje efikasno testiranje, definiui nain generisanja podataka za test, testiranje pojedinanih modula, testiranje integrisanja modula i tesitranje sistema kao celine.
33
3.5. Plan projekta

Dobar plan projekta mora da ima sledee elemente: 11. Plan obuke, obezbeuje kvalitetno korienje sistema organizovanjem nizom obuka krajnjih korisnika u toku razvoja projekta i radom nad sistemom 12. Plan bezbednosti, specifikuje nain zatite podataka, korisnika i hardvera, obuhvatajui poverljivost, raspoloivost i integritet 13. Plan upravljanja rizicima, prepoznaje rizike i definie nain njihovog otklanjanja ili umanjenja 14. Plan odravanja, sadri nain odravanja sistema nakon isporuke, odgovornost za izmenu koda, prepravke hardvera i auriranje pratee dokumentacije
34
3.6. Modeli procesa i upravljanje projektom

Boehm (1996) je identifikovao tri osnovna miljokaza, zajednika za sve procesne modele razvoja softvera, koji mogu da poslue kao osnova i za tehniki proces i za upravljanje projektom: Ciljevi ivotnog ciklusa Arhitektura ivotnog ciklusa Inicijalna operativnost sistema
35

Svrha miljokaza ciljevi ivotnog ciklusa je potvrda da su svi zainteresovani subjekti saglasni sa ciljevima posmatranog sistema. Kljuni zainteresovani subjekti deluju kao tim za odreivanje granica sistema. Nakon toga analiziraju razliite scenarije korienja sistema. Scenariji mogu biti iskazani prototipom, ekranskim prikazima, tokovima podataka, a mogu ukljuiti i bezbednostne aspekte.
36

Rezltat je inicijalni plan ivotnog ciklusa koji definie: Ciljeve. Zato se posmatrani sistem razvija? Miljokazi i rokovi. ta e i do kada biti uraeno? Odgovornosti. Ko je odgovoran za funkciju? Pristup. Kako e posao biti uraen sa tehnike strane i strane rukovoenja? Resursi. Kolikoje potrebno pojedinanih resursa? Izvodljivost. Da li se moe uraditi i da li postoji opravdani poslovni razlog da se to uradi?
37

Arhitektura ivotnog ciklusa je usklaena sa ciljevima ivotnog ciklusa. Namena miljokaza u okviru arhitetkure ivotnog ciklusa je da se definiu arhitekture sistema i softvera. Izbor arhitekture mora da odraava rizike definisane u sklopu plana upravljanja rizicima. Arhitektura mora omoguiti dugoroni razvoj sistema i kratkorone sistemske zahteve Inicijalna operativnost sistema odreuje spremnost sistema, softvera i lokacije na kojoj e se sistem koristiti, izbor i obuka tima koji e koristiti sisitem.
38

Boehm predlae upotrebu spiralnog modela Win-Win kao dopunu miljokazima. Ovaj model predstavlja proireni bazni spiralni model. On podstie uesnike da u sledeem stadijumu sistema konvergiraju ka zajednikom razmevanju ciljeva, alternativa i ogranienja Boehm je primenio pristup Win-Win na program STARS Ministarstva odbrane SAD, iji je cilj bio razvoj skupa prototipskih okruenja za softversko inenjerstvo.
39
Rezime
Upoznali smo se sa kljunim konceptima upravljanja prijektima, ukljuujui planiranje projekta, procenjivanje trokova i rokova, upravljanje rizicima i organizacija tima. Planiranje projekta ukljuuje ulazne informacije od svih lanova tima, a razumevanje procesa planiranja i tehnika procenjivanja prua sliku o tome kako e se podaci upotrebiti za donoenje odluka na nivou celog tima. Uoili smo razliit nain komunikacije i kako oni uestvuju na meusobne interakcije prilikom obavljanja posla. Razumevanjem stilova lanova tima moemo ih angaovati za odreene uloge.
40

Planiranje I Upravljanje Projektom

Uploaded by

Document Information

Original Title

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

Planiranje I Upravljanje Projektom

Uploaded by

Copyright:

Available Formats

LOGO

PRINCIPI RAZVOJA SOFTVERA

3. Planiranje projekta i upravljanje njime

Sadraj nastavne jedinice

3.1. Praenje napretka

3.1. Praenje napretka

3.1. Praenje napretka

3.1. Praenje napretka

3.1. Praenje napretka

3.1. Praenje napretka

3.1. Praenje napretka

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.2. Osoblje na projektu

3.3. Potreban rad

3.3. Potreban rad

3.3. Potreban rad

3.3. Potreban rad

3.3. Potreban rad

3.3. Potreban rad

3.3. Potreban rad

3.4. Upravljanje rizicima

3.4. Upravljanje rizicima

3.4. Upravljanje rizicima

3.4. Upravljanje rizicima

3.4. Upravljanje rizicima

3.4. Upravljanje rizicima

Smanjenje rizika Planiranje upravljanja rizicima Razreavanje rizika

Slika 3.15. Koraci urpavljanja rizicima

3.5. Plan projekta

3.5. Plan projekta

3.5. Plan projekta

3.5. Plan projekta

3.6. Modeli procesa i upravljanje projektom

3.6. Modeli procesa i upravljanje projektom

3.6. Modeli procesa i upravljanje projektom

3.6. Modeli procesa i upravljanje projektom

3.6. Modeli procesa i upravljanje projektom

You might also like