9.Planiranje softverskog projekta

planiranje softverskog projekta Boris Tikvenjac ITA/08

Softversko Inženjerstvo

Planiranje softverskog projekta

Predmetni nastavnik: polaznik:Goran Radić Boris Tikvenjac ITA/08 14.09.2009.

1/14


TABLE OF CONTENTS

CHAPTER TITLE PAGE

PLANIRANJE SOFTVERSKOG PROJEKTA ATACHMENT ___________________ 1/14

UVOD _______________________________________________________________ 3/14

AKTIVNOSTI UPRAVLJANJA (MANAGEMENT ACTIVITIES) :______________ 4/14

RESURSI PROJEKTA (PROJECT RESOURCES) ………….………………………… 5/14

…………………………………………………………………………………….……… 6/14

PLANIRANJE PROJEKTA (PROJECT PLANNING) _________________________ 7/14

PROCENA TROŠKOVA _________________________________________________ 8/14

PROCENA STRUČNJAKA ……………………………………………………………. 9/14

UPRAVLJANJE RIZIKOM (RISK MANAGEMENT) _________________________ 10/14

…………………………………………………………………………………………... 11/14

PROJEKTNI PLAN (THE PROJECT PLAN) ________________________________ 12/14

GRAPHIC PROJECT PLANING __________________________________________ 13/14

REFERENCES ________________________________________________________ 14/14

2/14


UVOD

Važna razlika između profesionalnog razvoja softvera i amaterskog programiranja se ogleda u potrebi za menadžmentom. Profesionalno softversko inženjerstvo se oslanja na software project management i na njega utiče raspoloživost budžeta i plan ograničenja koji su postavljeni od strane organizacije u razvoju softvera. Posao software project management-a je da obezbedi kvalitetan razvoj softverskog projekta u ispunjavanju plana ograničenja i isporučivanju softvera koji potpomaže poslovnim ciljevima. Softver menadžeri su odgovorni za planiranje i obezbeđivanje standarda u razvoju projekta. Međutim, dobro upravljanje ne može uvek da garantuje uspeh projekta, dok loše upravljanje dovodi do neuspeha projekta. Krajnje isporučivanje softvera često košta više od prvobitne procene i ne uspeva uvek da zadovolji sovje potrebe. Softversko inženjerstvo se razlikuje od drugih vrsta inženjeringa u nekoliko načina:

1. Softverski proizvod je ‘’nematerijalan’’ i neodređen – ne može se videti ni dodirnuti. Softverski project menadžeri ne mogu da vide napredak nego se oslanjaju na druge proizvedene dokumentacije potebne za praćenje napredovanja.

2. Ne postoje standardi softverskog projekta – još uvek nepostoji jasno razumevanje odnosa između softvera i proizvodnog tipa. Softverski proces se značajno razvija u poslednjih nekoliko godina, međutim, još uvek se ne može sa sigurnošću predvideti kada će određeni softverski proces izazvati neki problem u njegovom razovoju.

3. Veliki softverski projekti su često ‘’jednokratni projekti ‘’ (‘one-off’ projects ) - veliki softverski projekti se obično razlikuju od prethodnih projekata. Menadžeri nemaju velikih broj prethodnih iskustava pomoću kojih bi mogli smanjiti neizvesnost u softverskom planiranju. Prema tome, teško je predvideti probleme. Osim toga, brze tehnološke promene u računarima i komunikacijama i zastarelost prethodnog projekta, često povećavaju neizvesnost u sofverskom planiranju. Naučene lekcije iz tog pojekta ne mogu se upotrebiti i preneti na nove projekte.

Zbog ovih problema, nije iznenađujuće da neki od softverskih projekata kasne ili su prekoračili budžet ili promenili raspored planiranja. Često su softverski sistemi novi i tehnički inovativni. S obzirom na navedene teškoće, vrlo je iznenađujuće koliko se softverskih projekata dostavi na vreme i u okviru budžeta.

3/14


Aktivnosti upravljanja (Management Activities)

Nemoguće je opisati standardni opis posla softver menadžera. Posao izuzetno varira u zavisnosti od organizacije i razvoja softverskog porizvoda. Većina menadžera preuzimaju odgovornost za neke ili sve sledeće navedene aktivnosti:

Pisanje predloga (proposal writing) Projektovanje i planiranje (project planning and scheduling) Troškovi projekta (project costing) Monitoring projekata i revizija (project monitoring and reviews) Kadrovske selekcije i evaluacije (personnel selection and evaluation) Pisanje izveštaja i prezentacija (report writing and presentations)

Prva faza projekta mora da podrazumeva pisanje predloga za sprovođenje projekta. Predlog opisuje ciljeve projekta i kako će on biti sproveden. To obično uključuje i cenu i raspored procene. Predlog daje sigurnost projektnom ugovoru u dodeljivanju posla nekoj određenoj oraganizaciji ili timu. Pisanje predloga je kritički zadatak kao egzistencija mnogim softverskim organizacijama od koje zavisi dodeljivanje posla ili potpisivanje ugovora. Ne može biti postavljen putokaz za taj zadatak; pisanje predloga je veština koja se stiče iskustvom.

1. Projektovanje (project planning) – se bavi identifikovanjem aktivnosti , rezultata i prekretnica u proizvodnji projekta. Plan mora biti nacrtan kao vodič od početka razvoja do ciljeva projekta. Procena troškova je u vezi sa aktivnošću koja se bavi procenom resursa koji su potrebni da se ostvari plan projekta

2. Monitoring projekata (project monitoring) – je nastavak aktivnosti projekata. Menadžer mora pratiti napredak projekta i uporediti stvarni i planirani napredak i troškove projekta. Iako većina organizacija ima formalne mehanizme za praćenje, vešti menadžer može često oblikovati jasnu sliku po završetku neformalnog razgovora sa učesnicima projekta.Neformalni monitoring često može predvideti i otkriti potencijalne probleme projekta kada se oni pojave. Na primer, svakodnevni razgovor sa učesnicima projekta može otkriti poseban problem u pronalaženju nekog softverskog otkaza. Umesto da čeka prijavu zastajanja u razvoju softvera, softver menadžer može da dodeli ovaj problem nekom stručnjaku-programeru ili da zatraži da se ovaj problem rešava u nekom drugom okruženju. Tokom projekta, normalno je da ima više formalnih mehanizama za praćenje i upravljanje projektima. Oni se brinu za prikaz ukupnog progresa i tehničkog razvoja projekta i razmatraju status projekta u poređenju sa ciljevima organizacije za izradu softvera. Razvojno vreme velikih softverskih projekata može da bude nekoliko godina. Za to vreme, organizacioni ciljevi zahtevaju određene promene. Ova promena može da znači da softver više nije potreban ili da su originalni projektni zahtevi neprikladni. Menadžement može da odluči da zaustavi razvoj softvera ili da promeni projekat kako bi se omogućile promene organizacionih ciljeva.

3. Projekt menadžeri obično imaju izabranu selekciju ljudi-programera koji rade na njihovom projektu. Idealan slučaj je kada se obučeni kadar sa odgovarajućim iskustvom nalazi na raspolaganju za rad na projektu. U većini slučajeva, menadžeri moraju da kombinuju i da se dogovaraju za ljude sa razlnolikom percepcijom u cilju pridobijanja idealnog tima.

4/14


Razlozi za to su: Budžet projekta ne može da pokrije regrutovanje visoko plaćenog obučenog kadra.

Uvek se regrutuje manje iskusniji jeftiniji kadar Kadar sa određenim iskustvom možda neće biti dostupan unutar organizacije.

Najkvalitetnijem kadru je možda zadati neki drugi projekti unutar organizacije. Tada se javlja problem kod regrutovanja novog kadra

Organizacija može da planira razvijanje veština svog kadra. Neiskusnom kadru može biti dodeljen projekat da uče i stiču iskustva

Softver menadžer mora radi u okviru ovih ograničenja prilikom izbora kadra za projekat. Sa druge strane, problemi se otklanjaju ukoliko jedan član projekta ima nekog iskustva o tipu sistema koji se razvija. Bez ovog iskustva doćiće do pojave mnogobrojnih jednostavnih grešaka.

4. Menadžer projekta je obično odgovoran o izveštavanju o projektu obema stranama,klijentima i organizacijama koje su potpisale ugovor.Projektni menadžeri moraju pisati konciznu,koherentnu dokumentaciju koja izdvaja kritične informacije iz detaljnih izveštaja projekta. Oni moraju biti

sposobni da prezentuju i predstavljaju ove informacije u pregledu progresa. Prema tome, najbitnija veština projekt menadžera je uspešna i efikasna, usmena i pismena komunikacija sa svim učesnicima u projektu.

Resursi projekta (Project Resources)

Projektni resursi su prikazani u piramidalnom razvoju na sledećoj slici:

Razvojno okruženje, hardver i softverski alati se nalaze u temelju piramide i obezbeđuju infrastrukturu za razvojnu delatnost. Na višem nivou se nailazi na višekratnu upotrebu softverskih komponenata - softverski gradivni blokovi koji mogu drastično smanjiti troškove razvoja i ubrzati isporuku softvera. Na vrhu piramide se nalazi primarni ljudski resurs. Svaki resurs je specifiran sa četiri karakteristike:

opis resursa stanje intelektualne dostupnosti vreme – kada će resursi biti upotrebljeni trajanje vremena primenjenog resursa

5/14


LJUDSKI RESURSI (HUMAN RESOURCES)Planer priprema procenu obima odabirom veštine potrebne za kompletan razvoj. Obe organizacione pozicije (npr. menažder, stariji softverski inženjer) i specijalizovane pozicije (npr. telekomunikacije, baze podataka, klijent/serveri) su uključene. Za relativno male projekte (jedna osoba – godina ili manje), pojedinac može obavljati sve poslove softverskog inženjerstva, uz uslov konsultovanja sa stručnjacima. Broj ljudi potreban za softverski projekat se može utvrditi tek posle izrade procene razvoja truda (osoba – meseci).SOFTVERSKI RESURSI ZA VIŠEKRATNU UPOTREBU ( REUSABLE SOFTWARE RESOURCES) Bennatan [BEN92] predlaže četiri kategorije softverskih resursa koje treba razmotriti u planiranju projekta:

1. Off-the-shelf components – je komponenta postojećeg softvera koji može biti kupljen ili nabavljen od treće strane ili interno razvijan u prošlim projektima. COTS (commercial off-the-shelf) su komponente nabavljene od strane nekog drugog učesnika spremne za upotrebu u trenutnom projektu.

2. Full-experience components – je komponenta postojeće specifikacije, dizajna, koda i testa podataka razvijanih u prethodnim projektima koja je slična sa softverom koji bi se izgradio u aktuelnom projektu. Ovu komponentu predstavljaju članovi ekipe aktuelnog softvera sa velikim iskustvom u oblasti primene predstavljanja ovih komponenti. Komponenta sa punim iskustvom ima veoma nizak nivo rizika u projektu.

3. Partial-experience components – je komponenta postojeće specifikacije, dizajna, koda i testa podataka razvijanih u prethodnim projektima, koja zahteva značajne modifikacije. Članovi ekipe aktuelnog softvera imaju delimično ili ograničeno iskustvo u oblasti primene predstavljanja ovih komponenti. Delimično poznavanje neophodnog modifikovanja ove komponente ima korektan nivo rizika u projektu.

4. New components - su sofverske komponente koje moraju biti izrađene od strane softverskog tima posebno za potrebe aktuelnog projekta.

Sledeće smernice za višekratno upotrebljavanje komponenti koje su navedene kao resurs su: Ako off-the-shelf komponente zadovoljavaju zahtevima projekta, dobaviti ih. Troškovi za

nabavku i integraciju off-the-shelf komponenti su daleko manji od razvoja ekvivalentnog softvera. Pored toga, rizik je relativno nizak

Ako su full-experience komponente dostupne, rizici povezani sa modifikacijom i integracijom, su prihvatljivi. Plan projekta treba da ukazuje na upotrebu ovih komponenti

Ako su partial-experience komponente na raspolaganju, njihova upotreba za aktuelni projekat mora biti prvo analizirana. Ako je velika modifikacija potrebna, komponente mogu biti pravilno integrisane sa drugim elementima softvera ali uz veliku prisutnost rizika. Troškovi partial-experience komponenti ponekad mogu biti veći i od troškova za razvoj novih komponenti.

RESURSI RAZVOJNOG OKRUŽENJAAmbijent koji podržava softverski projekat se često naziva životna sredina softverskog inženjerstva (software engineering environment – SEE), obuhvata hardver i softver. Hardver obezbeđuje platformu koja podržava alat (softver) potreban za rad. Pošto većina softverskih organizacija imaju više izbornih jedinica koje zahtevaju pristup SEE, projekt planer mora propisati time window potreban za hardver i softver za potvrdu da će ta sredstva biti dostupna. Kod projektovanja računarskih sistema (koji zahtevaju specijalizovani hardver i softver), softverski tim može da zahteva pristup elementima hardvera razvijan od strane drugih inženjerskih timova.

6/14


Project Planning

Efektivno upravljanje softverskog projekta zavisi od detaljnog planiranja napredka projekta. Menadžer projekta mora da predvidi probleme koji se mogu pojaviti i pripremiti probna rešenja tih problema. Plan, izrađen na početku projekta, treba da se koristi kao vodič kroz projekat. Ovaj plan treba da prikaže nabolje rešenje u davanju raspoloživih informacija. On se razvija kako projekat napreduje i kako se dostupnost informacijama povećava. U praćenju napredka, softver se koristi samo u obavljanju određene željene funkcije ili u pružanju potrebnih servisa. Dakle, tipičan projekt počinje kada se primeti neka potreba u razgovoru sa korisnikom-klijentom. Na primer, velika nacionalna banka vas može pitati za pomoć u izgradnji informacionog sistema koji omogućava klijentima banke da pristupe svojim podacima o računu, bez obzira gde se oni nalazili. Obično, kupci imaju nekoliko pitanja a to su:

da li ste razumeli moje potrebe i moj problem? može li se izraditi dizajn sistema koji će rešiti moj problem i zadovoljiti moje potrebe? koliko vremena treba da se razvije takav sistem? koliko će koštati izrada jednog takvog sistema?

Odgovori na poslednja dva pitanja zahtevaju dobro promišljen raspored projekta. Raspored projekta opisuje ciklus razvoja softvera za određeni projekat nabrajajući pojedinačne faze projekta ili podelu svake faze projekta na diskretne zadatke i aktivnosti koje trebaju biti urađene:Prvo rastaviti problem u svojstvo delova i osmisliti rešenje za svaki njegov deo, a zatim ih sastaviti zajedno, u obliku jedne koherentne celine. Korišćenjem ovog pristupa utvrđuje se raspored projekta. Razgovor počinje sa klijentima i potencijalnim korisnicima u cilju obostranog shvatanja šta se želi uraditi u projektu. U isto vreme, dolazi do povratne infomacije od korisnika, koji se upoznaju sa načinom rada i rasporedom postupka. Spisak sa svim rezultatima projekta i stavkama koje korisnik očekuje dostavlja se i prikazuje:

dokumentima demonstracijom funkcija demonstracijom podsistema demonstracijom preciznosti demonstracijom pouzdanosti, bezbednosti i performansi

Zatim se utvrđuju željene aktivnosti koje su potrebne za izradu projekta. U analizi projekta mora se jasno razlikovati aktivnost od prekretnice. Aktivnost je deo projekta koji se odvija tokom perioda, dok je prekretnica završetak aktivnosti – posebno u nekoj tački vremena. Dakle, aktivnost ima početak i kraj, a prekretnica je kraj posebno naznačene aktivnosti. Na primer, korisnik će možda želeti da sistem bude u on – line pratnji putem operatera koji će davati uputstva i instrukcije u vezi sistema. Razvoj kroz tutorijale (guidelines)- razvoj uputstva koji je povezan sa programom aktivnosti, koji kulminira u demonstracijama od tih funkcija klijenta/korisnika.

7/14


Procena troškova

Jedan od ključnih aspekata projektovanja i upravljanja je razumevanje odnosa cene i veličine projekta, odnosno verovatnoća u proceni troškova izrade projekta. U slučaju prekoračenja troškova, može doći do otkaza projekta i otkaza ugovornog dela prema klijentu, dok u slučaju nedostatka sredstava (finansijskih), može doći do otkaza i projektnog tima, zbog neadekvatnog i neracionalno utrošenog vremena i rada u odnosu na novčanu naknadu.

Na procenu troškova utiče mnogo razloga: česti zahtevi za promenu od strane korisnika previd zadataka nedostatak razumevanja sopstvenih zahteva korisnika nedovoljna analiza kada se razvija procena, nedostatak koordinacije u razvoju sistema,

tehničkih usluga, radnih operacija, upravljanju podataka i ostalih funkcija tokom razvoja nedostatak adekvatnih metoda i smernica za ocenjivanje projekta

Dobre procene troškova u ranom razvoju projekta pomažu glavnim projektantima u određivanju broja programera, koji će učestvovati u projektu, i obezbeđuju odgovarajuće osoblje koje će se aktivirati u projektu ukoliko bude bilo potrebe. Sledećih nekoliko aspekata imaju ključnu ulogu u proceni troškova:

složenost primene predloženog sistema potrebna integracija sa postojećim sistemima kompleksnost programa u sistemu veličina sistema izražava se kao broj funkcija ili programa sposobnost članova projektnog tima iskustvo projektnog tima sa aplikacijama i programskim jezicima predviđanje frekvencije i obima potencijalnih promena u zahtevima korisnika sistem za upravljanje bazom podataka broj članova projektnog tima obim programiranja ili dokumentovanja standarda dostupnost alata kao što su generatori aplikacija iskustvo projektnog ima sa hardverom

Budžet projekta obuhvata nekoliko vrsta troškova: objekti osoblje metode alati

Troškovi objekata obuhvataju: hardver, prostor, telefone, modeme, nameštaj, grejanje i klimatizaciju, kablove, diskove, papire, fotokopir i sve druge stavke koje će sačinjavati fizičko okruženje u kome će programeri raditi.

Postoje ponekad i skriveni troškovi koje programeri ne mogu odmah uočiti.

8/14


Na primer, studije pokazuju da programerima treba minimum prostora i tišine da bi mogli efikasnije da rade. IBM je 1978 uveo standard radnog prostora za rad programera i to da je za kvalitetniji rad potrebno minimalno 30 m/2. Radni prostor takođe mora biti zaštićen od buke odnosno zvučno izolovan. DeMarco and Lister’s (1987) sugerišu da je rad programera bez telefonskih poziva i nepozvanih posetioca, daleko efikasniji od onih, koji su predmet čestog prekidanja u toku rada. Drugi projektni troškovi uključuju kupovinu softvera i alata za podršku u razvoju projekta. Pored alata za dizajniranje i kodiranje sistema, projekt može zahtevati softver za organizovanje dokumentacije, praćenje zahteva, testiranje koda, praćenje promena, generisanje test podataka, podršku grupnih sastanaka i još mnogo toga. Ovi alati se nazivaju CASE alati (Computer – Aided Software Engienering) i služe u ispunjavanju korisničkih zahteva ili su standardni deo razvojnog procesa softverske kompanije.

PROCENA STRUČNJAKA

Mnogo pokušaja i metoda (effort/metods) procene oslanjaju se na stručne procene. Neke tehnike su neformalnog oblika, na osnovu iskustva menadžera sa sličnim projektima. Tačnost predviđanja se zasniva na sposobnosti, iskustvo, objektivnost i percepciju za procenu. U svom najjednostavnijem obliku, procena obuhvata pretpostavku o potrebnom naporu u izgradnji čitavog sistema ili njegovih podsistema. Kompletna procena može se izračunati top-down ili bottom-up analizom šta je potrebno za izgradnju sistema. U mnogim slučajevima analogija se koristi za procenu napora. Ukoliko već imamo izgrađen sistem, onda možemo koristiti sličnost kao osnovu za procenu. Analogija procesa se može izvesti potraživanjem od nekoliko stručnjaka da formulišu tri predviđanja:

1. pesimista (a one pessimist) X2. optimista (a one optimist) Y3. najverovatnija predpostavka Z

Tada je procena sredstvo beta raspodele verovatnoće i određuje sledeću jednačinu:(X+4Y+Z) / 6

Rešenje pomoću ove tehnike (jednačine) normalizuje procenu pojedinačne procene

Druge forme procene se definišu na sledeće načine:

Delfi tehnikom

1. Eksperti su zamoljeni da tajno prave pojedinačna predviđanja, na osnovu svoje ekspertize i pomoću bilo kog procesa koji izaberu

2. Posebna procena se proračunava i prezentuje grupi3. Svaki stručnjak ima mogućnost provere drugih procena, ukoliko to želi4. Proces se ponavlja dok ga stručnjak ispravlja i razmatra

Wolverton : izrađen jedan od prvih modela pokušaja (effort) procene razvoja softvera. Cena softvera u matričnom redu prikazuje ime i tip softvera, a kolona određuje njegovu težinu. Težina zavisi od dva faktora: old (O) i new (N) u zavisnosti da li je easy (E), moderate (M) ili hard (H). Matrični elementi su troškovi po liniji koda.

9/14


1. Particija predloženih modula u softverskom sistemu2. Procena veličine svakog modula u pogledu linija koda3. Izračunavanje cene modula korišćenjem matrice4. Suma svih modula

U principu, praktični model se oslanja uglavnom na procenu stručnjaka koji daju ocenu o nepravilnostima u razvoju projekta. Razvoj praktičnog modela se oslanja na iskustvo stručnjaka u načinu određivanja sličnosti između projekata. Međutim, projekti koji se pojavljuju kao vrlo slični nemogu biti drugačiji odnosno različiti. Isto tako, često postoje karakteristike koje čine da se jedan projekat razlikuje od drugog, alit e karakteristike nisu uvek vidljive. Procena stručnjaka zavisi od varijabilnosti, subjektivnosti i od aktuelnosti podataka. Podaci na kojima je bazirana procena stručnjaka moraju da prikazuju aktuelne prakse i moraju redovno da se ažuriraju.Štaviše, većina tehnika stručnih procena su jednostavne, zanemarujući pritom da objedine veliki broj faktora koji mogu uticati na napore (effort) procene potrebne za izradu projekta. Iz tog razloga stručnjaci i istraživači su se okrenuli algoritamskim metodama procene napora.

Upravljanje rizikom (Risk Management)

Mnogi ‘’softver projekt’’ menadžeri preduzimaju korake u osiguranju svog projekta u vremenu izrade i u okvirima napora (effort) i troškova ograničenja. Međutim upravljanje zahteva mnogo više napora od praćenja i raspoređivanja projekta. Menadžer treba da utvrdi da li će se neke nepravilnosti pojaviti u toku razvoja i održavanja projekta i da planira njihovo izbegavanje, ili ako su one neizbežne, da minimizira njihove negativne posledice. Projektni menadžeri često koriste risk management u cilju razumevanja i kontrolisanja rizika u svojim projektima.

Boehm je identifikovao nekoliko stavki rizika i predstavio nekoliko tehnika upravljanja rizikom:

1. Nedostatak kadrova – kvalitetno osoblje, usklađivanje poslova, team building, morale building, unakrsna obuka, raspoređivanje ključnih ljudi

2. Nerealni rasporedi i budžeti – višeizvorni (multisource) detalji procena troškova i rasporeda, dizajna i troškova, inkrementalnog razvoja, ponovna upotreba softvera, requirement scrubbing

3. Razvijanje pogrešne funkcije softvera – organizaciona analiza, analiza misije, operativne koncepcije formulisanja, nadziranje korisnika, izrada prototipa, prerana izrada korisničkog priručnika (user’s manual)

4. Pogrešno razvijanje korisnićkog interfejsa – izrada prototipa, scenarija, analize zadataka

5. Gold plating - requirement scrubbing, izrada prototipa, costbenefit analiza, odnos dizajna i cene

6. Nastavljajući tok zahteva promene – visok prag zahteva promene, sakrivanje informacija, inkrementalni razvoj (odložene promene u kasnijim koracima)

7. Nedostatci u obavljanju extrenih zadataka – provera referenci, naknadna revizija, naknadni ugovor, konkurentnost dizajna i prototipa, team building-a

10/14


8. Nedostatci u externim komponentama – testiranje performanse sistema, kontrolisanje, provera referenci, analiza kompatibilnosti

9. Nedostatak real-time performansi – simulacija, testiranje perfomansi, modeliranje, izrada prototipa, tehnika projektivanja i iskorištenja, podešavanje

10. Strainin computer science capabilities (naučno ispitivanje kompjuterskih mogućnosti) – tehnička analiza, cost-benefit analiza, izrada prototipa, provera referenci

Kvanitifiovanje efekata rizika može se identifikovati umnožavanjem uticaja rizika u verovatnoći rizika, prilagođivanjem izloženosti riziku. Verovatnoća rizika tokom vremena je varijabilna, tako da je posao menadžera da prati ove vrednosti tokom razvoja projekta i da kreira plan za događaje u skladu sa tim.Postoje dva glavna izvora rizika:

1. Opšti rizici – oni su zajednički za sve projekte, kao što je naprimer, nerazumevanje potrebe, gubitak ključnog osoblja, ili nedovoljno vreme za testiranje

2. Specifični projekt rizici – nagoveštaji koji rezultiraju ranjivost projekta. Na primer, prodavac može obećati izradu mrežnog softvera do određenog datuma, ali postoji rizik da mrežni softver neće biti spreman na vreme.

Risk management uključuje nekoliko važnih koraka:

1. Procena rizika projekta – razumevanje šta se može desiti u toku razvoja ili održavanja. Procena se sastoji od tri aktivnosti: identifikacija rizika, analiziranje i određivanje prioriteta za svakog od njih.

2. Ako se izrađuje sličan sistem – može se iskoristiti spisak problema koji se mogu pojaviti, korišćenjem dokumentacije izrade prethodnog sistema

3. Napraviti proveru – da li će projekat biti izložen navedenim rizicima4. Proširenje spiska – analizom svake aktivnosti u razvoju projekta dekomponovanjem

procesa na manje delove, kada su u pitanju noviji sistemi5. Analiziranje pretpostavki – donošenje odluke o tome kako će projekat biti urađen, ko

će voditi projekat i koje resurse će koristiti i najzad, procenjivanje pretpostavki radi utvrđivanja rizika

6. Analiza rizika – identifikovanje rizika i razumevanje kada, zašto i gde se mogu pojaviti

7. Dodeljivanje prioriteta rizicima – nacrt prioritetnih rizika omogućuje odvajanje određenih resursa kojima preti neki rizik

Izloženost riziku je proračun između uticaja rizika i verovatnoće rizika, tako da se mora proceniti svaki aspekat navedenih rizika. Izloženost rizika pomaže u davanju najvišeg prioriteta rizika, koji se nalazi u listi prioriteta.

Projektni plan (The Project Plan)

Plan projekta je akt koji sadrži komunikaciju analize i upravljanja rizicima, procenu troškova projekta, raspored i organizovanje. Plan se u pisanoj formi dostavlja klijentu/kupcu u cilju opisa projekta.

11/14


Korisnik se putem projektnog plana informiše o aktivnostima u procesu razvoja i o napredovanju projekta, tokom razvoja.Dobar projektni plan obuhvata sledeće stavke:

Okvir projekta – definiše granice, daje objašnjenje o tome šta će biti uključeno u izradi projekta. To je detaljan prikaz projektnog tima o razumevanju izrade željenog sistema kupca

Raspored projekta – se može izraziti pomoću rasparčane radne strukture (breakedown structure), rezultata i vremenskog roka koji pokazuju sva dešavanja u svakom trenutku u toku životnog ciklusa projekta. Gantov grafikon može korisno prikazati paralelnu prirodu nekih zadataka razvoja

Organizacija projektnog tima – organizovanje razvojnog tima i njihovih zadataka na projektu Tehnički opis predloženog sistema – bavi se pitanjima i odogvorima u predviđanju i

napredovanju razvoja projekta. Opis sadrži liste hardvera, softvera, kompajlera, interfejsa, softvere i opremu specijalnih namena, kao i svih posebnih ograničenja - kabliranja, vremena izvršavanja, vremena reakcije, bezbednosti i drugih aspekata funkcionalnosti i performansi

Projektne standarde, procedure, tehnike i alate – uključuje algoritme, alate, pregled ili inspekciju tehnika, opis jezika dizajna, jezik kodiranja i tehnike testiranja

Plan obezbeđenja kvaliteta – opisuje kako recenzija, inspekcija, testiranje i druge tehnike pomažu u proceni kvaliteta i osigurava da zadovolji potrebe kupaca uglavnom velikih potreba.

Plan upravljanja konfiguracijom – pomaže da se kontrolišu više kopija softvera i prikazuje kupcu/klijentu plan praćenja promena u zahtevima, dizajnu, kodu, plan testiranja i lsične dokumente koji prate velike projekte

Plan dokumentacije - prave se u toku razvoja, posebno za velike projekte u kojima sve informacije o dizajnu moraju biti dostupne članovima projektnog tima. Plan sadrži listu dokumenata, objašnjava proces njihovog kreiranja i opisuje način na koji će dokumenti biti izmenjeni, usklađeno sa planom upravljanja konfiguracije

Plan upravljanja podacima – objašnjava proces prikupljanja, skladištenja, obradjivanja i arhiviranja podataka

Plan upravljanja resursima – objašnjava kako će se koristiti resursi Plan testiranja – zahteva mnogo planiranja da bi bio efikasan, a opisuje ukupan pristup

testiranja projekta. Konkretno, plan bi trebalo da opiše testiranje podataka, testiranje svakog programskog modula, testiranje integracije modula sa svim ostalim delovima, testiranje celog sistema i opis grupe ili tima koji će to izvršavati

Plan obuke – obično se priprema tokom razvoja, tako da obuka može da počne čim sistem bude spreman (a nekad i pre). On objašnjava sadržaj i opis obuke, opisuje svaku klasu pratećeg softvera i dokumentacije i opisuje potreban nivo stručnosti za svakog učenika ponaosob

Plan bezbednosti – objašnjava kako će sistem štiti podatke, korisnike i hardver, podrazumeva poverljivost, raspoloživost i integritet i objašnjava kako svaki aspekt bezbednosti utiče na razvoj sistema

Plan upravljanja rizicima Plan održavanja – opisuje odgovornosti za promenu koda, popravku hardvera, ažuriranje,

prateću dokumentaciju i materijale za obuku korisnika

12/14


13/14


REFERENCES

Software Engineering FIFTH EDITION Roger S. Pressman, Ph.D.

Software Project ManagementA P R A C T I T I O N E R ’ S A P P R O A C H

14/14

Documents

9.Planiranje softverskog projekta