upravljanje rizicima u projektima razvoja softvera

Upload: branko-zivkovic

Post on 08-Apr-2018

243 views

Category:

Documents


2 download

TRANSCRIPT

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    1/33

    Elektronski fakultet NiKatera za RaunarstvoStudentski projekti, VI semestar

    U p r a v l j a n j e

    r i z i c i m a u

    p r o j e k t i m a

    r a z v o j as o f t v e r a

    Student

    Branko ivkovi Prof. Dr. Ivan Milentijevi

    Br. Indeksa: 11981 Oliver Vojinovi

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    2/33

    2

    Sadraj

    Uvod .............................................................................................................................................................. 4

    1 Rizik ....................................................................................................................................................... 6

    1.1 Problem granice ............................................................................................................................ 6

    2 Upravljanje rizicima............................................................................................................................... 8

    2.1 Modeli upravljanja rizicima ......................................................................................................... 10

    2.1.1 Osnovni modeli ................................................................................................................... 10

    3 Klasifikacija rizika ................................................................................................................................ 13

    3.1 Poreklo rizika ............................................................................................................................... 13

    3.2 Uticaj rizika .................................................................................................................................. 14

    3.2.1 Hazardni rizici ...................................................................................................................... 14

    3.2.2 Ograniavajudi rizici ............................................................................................................ 15

    3.2.3 Nominalni rizici.................................................................................................................... 15

    3.2.4 Trivijalni rizici ...................................................................................................................... 15

    3.3 Nivoi rizika ................................................................................................................................... 16

    4 Identifikacija rizika .............................................................................................................................. 17

    4.1 Metode identifikacije rizika......................................................................................................... 17

    4.1.1 Intuitivne metode ............................................................................................................... 18

    4.1.2 Metode bazirane na istoriji ................................................................................................. 19

    4.1.3 Tip II: projektno-specifina ientifikacija rizika................................................................... 22

    5 Odgovori na rizik ................................................................................................................................. 26

    5.1 Specijalni tretman hazadrnih rizika ............................................................................................. 26

    5.2 Ograniavajudi rizici .................................................................................................................... 27

    5.3 Ogovaranje na uobiajene pretnje ........................................................................................... 27

    5.4 Plan odogovora na rizik ............................................................................................................... 28

    5.5 Izbegavanje rizika ........................................................................................................................ 28

    5.6 Transfer rizika .............................................................................................................................. 28

    5.7 Prihvatanje rizika ......................................................................................................................... 29

    5.8 Monitorig rizika ........................................................................................................................... 29

    5.9 Ublaavanje rizika ....................................................................................................................... 29

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    3/33

    3

    5.10 Strateki plan .............................................................................................................................. 30

    5.11 Eskalacija rizika ............................................................................................................................ 30

    5.12 Implementiranje odgovora na rizik ............................................................................................. 31

    6 Zakljuak.............................................................................................................................................. 32

    7 Literatura............................................................................................................................................. 33

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    4/33

    4

    Uvod

    Studije pokazuju da 80%-90% svih softverskih projekata propadne. ak vie o polovineprojekata premai svoj buet i plan raa za vie o 200%. [1] Kako se projekti razvoja softvera

    znaajno razlikuju o rugih vrsta projekata (graevinskih npr.), proces i alati koji se koriste abi se njima upravljalo moraju se prilagoditi.

    U ananjem poslovnom okruenju, a pogotovu u oblasti informacionih tehnologija, vladaglobalno trite koje namede nezapamdeno jaku konkurenciju. Poslovna klima je takva aorganizacije moraju a se takmie sa rugim organizacijama iz iste brane koje mogu biti bilogde u svetu pa je i pritisak na inoviranju i konstatnom plasiranju novih proizvoa nikaa vedi.Posleica je a je vreme za razvoj sve krade. Pore toga, koncept u kome su resursi upotpunosti posvedeni jenom projektu vie nije oriv to namede potrebu za rugaijimposmatranjem organizacione strukture i operacija. Nove tehnike za upravljanje kompleksnim i

    inaminim projektima koji se konstantno menjaju su iziskivale i novi pristup upravljanjuovakvim projektima. Procesi upravljanja i alati koji se tom prilikom koriste moraju se prilagoditi

    specifinostima IT projekata.

    U tabeli nie su naveene osnovne razlike izmeu IT i ostalih projekata *1+

    Komponenta projekta Non-IT Projekat IT Projekat

    Projekat Nije integrisan sa vedinombiznis funkcija

    Obino povezani sa biznis procesima iorganizacionim sistemima

    Projektna struktura esto samostalna Obino vie projekata sa vedim

    brojem meuzavisnosti

    Opseg Dobro definisan Manje efinisan i poloanpromenama

    Kontrola promena Dobro definisana Proces kontrole promene se moeefinisati ali se teko prati

    Zainteresovane strane Ima ih manje, lake seidentifikuju

    Ima ih vie; tee se ientifikuju

    Osoblje/resursi esto potpuno posvedeni(zavisi od organizacione

    strukture)

    Obino posvedeni elom ranogvremena; napredovanje posla

    oreuje koje de se vetineupotrebljavati

    Osoblje Najbolji ljui sa kritinimvetinama; proseni sa ostalimvetinama; vie ljui sa optimznajima

    Najbolji raspoloivi ljui; najedespecijalisti

    Veliki projekti Podeljeni u organizaciji ili Alocirani po specijalnosti (poruja sa

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    5/33

    5

    Komponenta projekta Non-IT Projekat IT Projekat

    formirani kao zasebne celine rizikom)

    Rizici Lake se ientifikuju; Loevoeni ali obino sa manje

    negativnih posledica

    Ne ientifikuju se lako; loe voeni iimaju veliki uticaj na

    projekat/organizacijuDokumentaovanje

    metrika

    Loe o zaovoljavajude Relativno obro ali se loe primenjuje

    Nauene lekcije Loe o zaovoljavajude Loe

    Procena bueta i

    rasporeda

    Dobra Loa

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    6/33

    6

    1 Rizik

    Rizik se, u svom izvornom znaenju, povezuje sa kockanjem. On prestavlja nesigurnost tj. vie

    mogudih ishoa nekog ogaaja koji mogu biti i pozitivni i negativni.

    Rizik oznaava i nesigurnost u poslovnim pouhvatima. Koliko go se organizacija truila a

    prikupi sve potrebne informacije i napravi etaljne planove, uvek de postojati neki nepoznati

    faktori koji mogu a utiu na rezultate preuzimanih aktivnosti. Veliki borj organizacija

    procenjuje verovatnodu gubitka i porei sa verovatnodom obitka. Ako je onos povoljan,

    uputa se u planirani pouhvat.

    Na osnovu ovoga mogli bismo a zakljuimo a rizik prestavlja verovatnodu neuspeha ali

    ovakav stav je nekompletan jer posmatra rizike kao skup problema. Rizine akcije se sprovoe

    samo ako postoji mogudnost za obit, uspeh i ostvarivanje ciljeva. Shono tome, rizik se moe

    opisati kao verovatnoda nauspeha prilikom tenji a se ostvare ciljevi.

    Kaa uzmemo u obzir i snagu loeg uticaja koji rizik moe imati na organizaciju uviamo a u

    procesu oluivanja o tome a li preuzeti neku akciju uestvuje vie faktora. Saa rizik

    moemo a posmatramo kao teinski faktor koji prestavlja kombinacju verovatnode

    pojavljivanja gubitka i znaaja koji taj gubitak ima. Taj faktor se naziva izloenost riziku.

    Procena verovatnode pojavljivanja rizika i njegovog uticaja je subjektivna i esto se opisuje

    lingvistikim merama kao to su visok, srenji i nizakkojim ogvaraju sleede numerike

    vrecnosti, respektivno: 0.0 0.3, 0.3 0.7, 0.7 1.0. [4]

    Poto rizik prestavlja nesigurnost nastupanja nekog ogaaja ili uticaja, treba naglasiti da

    gubici koji nastaju usle faktora koji su po naom kontrolom ne prestavljaju rizike. Ovo je i

    logino iz razloga to nestigurnost nastupa samo kaa neto ne moemo a kontroliemo.

    Shono tome, interni faktori ne prestavljaju izvor rizika ved su to samo eksterni ut icaji koji

    mogu da prouzrokuju gubitak.

    1.1 Problem granice

    Da li de neto biti posmatrano kao rizik zavisi o toga ko je posmatra i granica koje je postavio

    oko sebe. Ako je osoba ogovorna za sve procese u okviru svoje granice ona de jasno modi a

    ientifikuje rizike zbog toga to joj je stalo a iskoridenost resursa i postignuti rezultati budu na

    najviem mogudem nivou. Zbog toga vlasnik procesa namerno trai rizike. Konfliktne situacije

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    7/33

    7

    izmeu vlasnika procesa i rugih ljui u organizaciji esto mogu a nastanu ako neko ko nije

    vlasnik procesa ukae na rizik.

    Kao to je naveeno ranije, rizici nastaju usle faktora koji nisu po naom kontrolom. Na

    primer, programer de prikupljanje i definisanje zahteva posmatrati kao mogudi izvor rizika jer je

    to, u odnosu na njega, eksterni proces. Vii menaer u organizaciji istu situaciju ne bi

    posmatrao kao izvor rizika jer zna a bi unapreivanje komunikacije otklonilo potencijalni uzrok

    problema. Viimo a percepcija rizika u sebi sari percepciju granica. Rizik se uvek efinie u

    odnosu na neke granice.

    Kada je organizaija poeljena, pojavljuje se vie granica i samim tim vie internih rizika. Ko

    integrisanih organizacija interni rizici predstavljaju izazove upravljanja procesima. Intenzivna

    saranja, u ovom sluaju, naoknauje slabosti i kreira organizaciju ija sposobnost prevazilazi

    sumu individualnih procesa.

    Saa moemo efinisati ve vrste rizika:

    Definicija 1.1. Interni rizik je verovatnoda nastajanja gubitka prilikom ostvarivanja zacrtanih

    performansi i ciljeva a zbog neadekvatnog kapaciteta procesa i organizacione strukture. [2]

    Definicija 1.2. Eksterni rizik je verovatnoda nastajanja gubitaka prilikom ostvarivanja zacrtanih

    performansi i ciljeva zbog nesigurnosti koje vlaaju u eksternom okruenju. [2]

    Moe se jo oati i a, poto je rizik nesiguran uticaj, ljui i organizacije esto imaju

    optimistike tenencije a ih jenostavno ne uoe ili a se naaju a rizici jenostvno nede

    nastupiti.

    Na alje demo se baviti samo rizicima koji nastaju na projektima razvoja softvera.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    8/33

    8

    2 Upravljanje rizicimaUspeno upravljanje rizicima je neophoan uslov za uspeno upravljanje projektima uopte.

    Zbog velikog znaaja koji ima za ostvarivanje projektnih i organizacionih ciljeva, proces

    upravljanja rizicima je paljivo razraen i struktuiran u nekoliko moela koji predstavljaju, u

    oreenoj meri, razliite pristupe problemu.

    U organizacijama u kojima postoji svest o vanosti upravljanja rizicima, stvara se atmosfera koja

    pospeuje i olakava kreiranje etaljnih planova. Uz to, strateko upravljanje rizicima

    obezbeuje pravi pristup i smer za ostvarivanje planiranih aktivnosti. U takvim organizacijama

    ljui su svesni koristi koje prua upravljanje rizicima pa su i projekti manje ranjivi a ciljevi i

    rezultati se mogu planirati sa vedem sigurnodu.

    Definicija 2.1. Upravljanje rizicima je sistematski pristup reukovanju tete nastale kao posleica

    rizika, inedi projekat manje ranjivim a proizvo robusnijim. [2]

    Koristi nastale kao posedica upravljanja rizicima mogu se grupisati u dve kategorije: primarne ili

    direktne i sekundarne ili indirektne. [2]

    Neke od primarnih koristi su:

    1. Ciljevi su ostvareni2. Projekat je zatiden o najopasnijih rizika3. Projekat je manje rajniv prema rizicima4. Ljui su pripremljeni i spremni za reavanje problema5. Proizvodi su pouzdaniji6. Gubitak usle loeg kvaliteta se smanjuje7. A hoc upravljanje krizama se suzbija

    Sekundarnih koristi ima mnogo i one nastaju kao posledica primarnih. Neke od njih su:

    - Poboljano postavljanje ciljeva i planiranje- Pragmatino onoenje oluka- Alternativni prilazi- Optimizacija procesa- Proaktivne strategije- Kultura reavajnja problema- Timski ra i grupno razmiljanje- Bolje upravljanje procesima- Kontinualno poboljavanje

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    9/33

    9

    Svaki rizik ukazuje kako na problem tako i na mogudnost. Dok interni rizici skredu panju na

    mogudnosti za unapeivanje procesa, eksterni pokazuju na mogudnosti za rast biznisa. Obe

    situacije primoravaju organizaciju a konstano inovira i na taj nain raste.

    Definicina 2.2. Upravljanje rizicima ima za cilj a rizike sagleava kao mogudnosti za

    unapreenje i obezbeuje informacije za kreiranje planova za rast. [2]

    Project Management Institute (PMI) je kreirao pragmatine smernice za voenje procesa

    upravljanja rizicima koje predstavljaju jedan od najboljih setova smernica:

    1. Planiranje upravljanja rizicima2. Identifikovanje i procena rizika3. Kvalifikovanje rizika4. Kvantifikovanje rizika5. Razvoj i implementacija strategija za upravljanje rizicima6. Pradenje ponaanja rizika7. Kontrolisanje rizika8. Dokumentovanje i arhiviranje istorije rizika

    Slika ilustruje korake u procesu upravljanja rizicima [1]

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    10/33

    10

    2.1 Modeli upravljanja rizicima

    Upavljanje rizicima, kao i sam projekat, nije rutinska operacija pa je zbog toga i tako teko

    odrediti jasnu proceduru kojom bi trebalo voditi sam proces upravljanja rizicima. Striktna

    pravila su funkcionalna za svakonevne rutinske aktivnosti. Ako ne razmiljamo out of the box

    nedemo uspeti a registrujemo veliki broj rizika.

    Projekti se po svojoj priroi sutinski razlikuju o aktivnosti (tj. procesa) koje se kontinualno

    izvravaju i ponavljaju. Zbog specifinosti projekata i neizvesnosti koja ih prati, nemogude je

    kreirati striktne proceure za upravljanje rizicima ved je bolje formulisati fleksibilnije i liberalnije

    smernice koje se mogu prilino osleno pratiti.

    2.1.1 Osnovni modeli

    Osnovni modeli upravljanja rizicima su jednostavni, ne iziskuju mnogo finansijskih ulaganja i

    mogu posluiti kao temelj na kome de se izgraiti moel superstrukture za upravljanje rizicima

    te su stoga esencijalni. Oni se sastoje od minimalnog seta procesa upravljanja rizicima koji svaki

    softverski projekat mora da ima:

    Model 1: Organiski proces upravljanja rizicima

    Organiski model upravljanja rizicima se oslanja na instinkt ljudi koji rade na projektu. Njegove

    prenosti se ogleaju u mogudnosti a oseti rizik i brzini kojom na njega moe a ogovori. Sa

    ruge strane, struktuiraniji metoi pruaju vie u pogleu obima i snage kojom moe a se

    ogovori na rizike. Organiski proces upravljanja rizicima je praden akcijom i karakterie se

    veoma brzim SAT (Sense-Act-Take) sekvencama.

    Imajudi u viu naveene karakteristike procesa, moemo zakljuiti a se katastrofinim rizicima

    mora upravljati uz pomod SAT moela tj. organiskim procesom upravljanja rizicima.

    Definicija 2.3: Organiski model upravljanja rizicima oslanja se na ljudsku savest i kreativnu

    sposobnost za osedanje rizika i brzo reagovanje na njih. [2]

    Model 2: Izbor Ciljeva

    Formalno upravljanje rizicima u projektu poinje u fazi postavljanja ciljeva. Kaa se postave

    ciljevi celog projekta i ciljevi grupa projektinih aktivnosti, rizici koji ih prate moraju biti

    ientifikovani i razjenjeni. Na osnovu ientifikovanih rizika i efinisanih ciljeva vri se trae

    off analiza ija posleica moe biti i reefinisanje nekih ciljeva.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    11/33

    11

    Definicija 2.4: Formalno upravl janje rizicima poinje putem reefinisanja ciljeva kako bi

    prouzrokovali minimalne rizike. [2]

    Izbor ili reefinisanje ciljeva uz svest o rizicima sastoji se o sleedih 5 kategorija:

    1. Definisanje ciljeva projekta uz svest o rizicima2. Definisanje ciljeva proizvoda uz svest o rizicima3. Upravljanje zahtevima uz svest o rizicima4. Definisanje milestone-ova uz svest o rizicima5. Definisanje Work Break Down strukture uz svest o rizicima

    Model 3: Minimalno upravljanja rizicima

    Osnovni minimum u procesu upravljanja rizicima

    se sastoji iz 3 koraka: identifikacija rizika, analiza

    rizika i njihova komunikacija (slika 2.2). [2]

    U minimalnom upravljanju rizicima, projektni tim

    ne zapoinje kreiranje i sprovoenje planova za

    ublaavanje rizika, on samo obavetava sve

    zainteresovane strane o njihovom postojanju.

    Svaka dalja reakcija je dobrovoljna i nije

    obavezna po ovom procesu.

    Zbog toga to ne sari ublaavanje i pradenje

    rizika ova metoa moe na prvi pogled da dalujebeskorisno. Meutim, teko je zamisliti neku

    zainteresovanu stranu koja je svesna rizika a ne

    ini nita povoom toga. Akcije u ovom sluaju

    ne izostaju samo se proces upravljanja rizicima

    njima ne bavi.

    Model 4: Upravljanje rizicima srednjih razmera

    Po postizanju svasnosti o rizicima, sistem za upravljan je rizicima se moe proiriti tako a

    ukljui i planove ogovora na rizike i pradenje. Ovaj sistem se sastnoji o sleedih osnovnihelemenata [2]:

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    12/33

    12

    1. Sistem razjanjavanja rizika2. Identifikacija rizika3. Analiza rizika4. Plan odgovora na rizik5.

    Pradenje rizika

    Akcenat ko ovog procesa upravljanja rizicima je na akciji tj.

    planu odgovora na rizik. Struktuirani odgovor na rizik predstavlja

    veliki korak u odnosu na podizanje svesti o postojanju rizika i

    zahteva znaajne koliine uloene energije.

    Kada se postigne nivo upravljanja rizicima kod koga se za

    identifikovane rizike preduzimaju struktuirane akcije, pradenje

    postaje jenostavan sleedi korak jer aje kontrolu na rizicima i

    omogudava korigovanje i prilagoavanje izabrane strategije

    upravljanja rizicima.

    Pore naveenih, postoji jo nekoliko moela za upravljanje rizicima koji de biti pomenuti ali

    nede biti obrazlagani. Ti moeli su:

    Moel 5: IAMT ciklus (Ientifikacija, Analiza, Ublaavanje i Pradenje)

    Model 6: Upravljanje rizicima punih razmera

    U situacijama kaa se ispostavi a je rizik vedi nego to je njegov vlasnik previeo ili a je za

    upravljanje rizikom potrebno vie resursa nego to jenjegovom vlasniku na raspolaganju ili kaa

    vlasnika rizika nije mogude ientifikovati i u rugim situacijama pribegava se prebacivanju rizika

    na vii nivo mnamenta.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    13/33

    13

    3 Klasifikacija rizikaU procesu analize svih rizika koji se mogu pojaviti na projektu esto se eava a tim

    ientifikuje vie esetina rizika, nekaa ak i preko stotinu. U takvoj situaciji nemogude je voiti

    rauna o svim rizicima u isto vreme pa se pribegava klasifikovanju i grupisanju rizika po nekim

    atributima.

    3.1 Poreklo rizikaAko za kriterijum za klasifikaciju rizika izaberemo poreklo, interne rizike moemo a svrstamo u

    jednu a eksterne u drugu grupu.

    Interni rizici nastaju unutar organizacije pa su i njihvoi vlasnici takoe unutar organizacije. Oni

    se mogu kontrolisati, meriti i pratiti lake nego eksterni rizici.

    Nasuprot internim, eksterne rizike je tee kontrolisati, meriti i pratiti. U nekim sluajevima, ovi

    rizici jednostavno moraju da se prihvate i jedino to moe a se pokua je a se nekako izbegne

    njihov puni intenzitet. Meutim, ekstrni rizici su usko povezani sa ciljevima rasta i mogu da

    ukazuju na mogudnosti za uspeh zbogega treba a buu veoma paljivo analizirani.

    Planovi upravljanja rizicima i brzina ogovora mogu znaajno a se razlikuju u sluaju internih i

    eksternih rizika.

    Granica izmeu ove ve kategorije rizika esto nije jasno oreena i zavisi o strukture same

    ogranizacije. Ako je organizacija jasno podeljena u manje funkcinalne jedinice, onda i rizici koji

    se javljaju unutar organizacije mogu oreenim grupama ljui a deluju kao eksterni jer oni

    sami nemaju kontrolu nad tim rizicma. U savremenim organizacijama svi rizici koji nastaju

    unutar same organizacuije se posmatraju kao interni ok rizici sa strane konkurencije, trita,

    rutva, prironih pojava... prestavljaju eksterne rizike. Ovakvo posmatranje obavezuje nas da

    bolje upravljamo internim rizicima jer moemo blie a ih prouimo, previimo i spreimo.

    Dubljom analizom i razumevanjem ovih rizika moemo odi o inovacija i unapreivanja

    procesa.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    14/33

    14

    Neki od osnovnih izvora rizika ati su na sleedoj slici: *3+

    3.2 Uticaj rizika

    Sleeda velika kategorija rizika obuhvata hazarne, ograniavajude, nominalne i trivijalne rizike.

    3.2.1 Hazardni riziciHazarni (katastrofini, rizici-ubice) rizici su rizici koji imaju najvedi uticaj na projekat tj. imaju

    potencijal a nanesu najvie tete.

    U upravljanju hazarnim rizicima najbolje je primeniti Marfijev zakon: ako neto moe a poe

    naopako ona de i podi. Ovaj pristup najvie ogovara ovoj vrsti rizika jer ne potuje zakone

    verovatnode koji inae vae(katastrofini rizici esto imaju malu verovatnodu pojavljivanja).

    Ako se oluimo za preuzimanje hazarnih rizika moramo imati jako dobar razlog za to. Benefiti

    moraju biti veliki. Kada preuzmemo ove rizike, moramo pokrenuti kontinualni sistem za

    pradenje i implementirati sistem za rano otkrivanjeupozoravajudih signala mnogo pre nego to

    o katastrofe oe. Koristimo najbolje naune metoe kako bismo moelovali ovakve rizike

    rai to boljeg razumevanja njihove priroe i mehanizama funkcionisanja sa ciljem a

    povedamo svoju sposobnost za previanje njihovog razvoja. I pore toga to se ovi rizici vednalaze u bazi rizika i to de se i na njih primeniti rut inska analiza, tu ne treba stati. Svaki od

    katastrofinih rizika zavreuje da bude posmatran kao poseban zadatak.

    Na osnovu naveenog moemo zakljuiti a hazarne rizike ne treba tretirati kao bilo koji rugi

    rizik. Zbog ogromnog uticaja koji mogu imati na projekat, moraju biti pradeni konstantno i na

    njih se mora reagovati veoma brzo.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    15/33

    15

    3.2.2 Ograniavajui riziciKako upravljati rizicima ija je verovatnoda pojavljivanja 100%? U njma nema niega nesigurnog.

    Po efiniciji, ovo uopte i nisu rizici ved ogranienja. Ako ogranienja ne mogu biti otklonjena,

    reenja moramo traiti koridenjem sistemskog prilaza. Problem rizika se prevoi u problem

    sistemskog inenjeringa.

    3.2.3 Nominalni riziciKo ovih rizika ogovarajudi atribut za njihovo definisanje jeste standardni Risk Exposure

    Number (REN). Prioretizacija ovih rizika se moe izvriti koridenjem Paretovog zakona: 20%

    rizika nosi 80% uticaja. Nominalni rizici se dodatno mogu klasifikovati u kvadrante u

    verovatnoda-uticaj prostoru:

    Q1 Visoka verovatnoda Nizak uticajQ2 Visoka verovatnoda Visok uticajQ3 Niska verovatnoda Nizak uticaj

    Q4 Niska verovatnoda Visok utiaj

    3.2.4 Trivijalni riziciTrivijane rizike treba rati po strani.

    Svi naveeni rizici, hazarni, ograniavajudi, nominalni i trivijalni, prikazani su na sleedoj mapi:

    [2]

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    16/33

    16

    3.3 Nivoi rizika

    Rizici se mogu klasifikovati u skalu sa sleedim poslovnim nivoima: [2]

    Nivo kompanije (nivo 0)

    Nivo strateke poslovne jeinice (nivo 1)Nivo programa (nivo 2)

    Nivo projekta (nivo 3)

    Nivo procesa (nivo 4)

    Nivo rizika se u ovom sluaju onosi na nivo koji vlasnici rizika imaju u organizaciji kao i na nivo

    sa koga se rizicima moe upravljati. Bez obzira na to na kom nivou su ientifikovani, rizici se

    priruuju ogovarajudi onosiocima oluka koji i mogu da na njih reaguju.

    Faktori koji uzrokuju rizike se u pogleu svoje priroe i saraja razlikuju u zavisnosti o nivoa.

    Na nivou 0 ominiraju trini i finansijski rizici, ok su na niim nivoima z astupljeniji procesni i

    tehniki rizici.

    Uticaj rizika je tipino najvedi na nivou 0. Oni mogu oblikovati i stateko planiranje u

    organizaciji.

    Klaisifikacija rizika u odnosu na organizacioni nivo ustvri predstavlja vrednosno-orjenisano

    grupisanje rizika. U pogledu prikazivanja vlasniva na rizicima, ova klasifikacija je najjasnija.

    Pore naveenih, postoji jo klasifikacija rizika a ove de biti pobrojani samo neki o najedih:

    Procesi pod uticajem rizika Kljuni rezultati po uticajem rizika Ciljevi pod uticajem rizika Zahtevi pod uticajem rizika

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    17/33

    17

    4 Identifikacija rizikaProces identifikovanja rizika sastoji se iz dva aspekta. Prvo, potrebno je da detektujemo rizike i

    otkrijemo ge se kriju. Potom treba a ih prepoznamo, imenujemo, efiniemo i a im

    dodelimo atribute na osnovu nekog sistema za klasifikaciju. Tom prilikom pozicioniramo rizik i u

    globalnoj taksonomiji rizika i rangiramo ga na osnovu procene o posleicama koje moe a

    proizvede.

    esto se eava a prilikom pronalaenja rizika ljui posmatraju samo eo celokupne slike. To

    znai a se uoavaju ved poznati rizici koji se javljaju u procesima i aktivnostima koje se

    ponavljaju, meutim, najvedi eo najopasnijih rizika se upravo javlja u novim procesima i

    aktivnostima.

    Definicija 4.1: Identifikacija rizika je proces pretrage okoline, detektovanja rizika, prepoznavanja

    njihovih atributa i procenjivanja posledica koje mogu da imaju na projekat. [2]

    Rezulat procesa ientifikacije rizika je lista rizika koja sari minimalni set informacija o rizicima.

    4.1 Metode identifikacije rizika

    Postoje dva tipa metoda za ientifikovanje rizika. Tip I je generiki i porazumeva pretragu i

    internog i eksternog okruenja. Opseg potrage za rizicima ie ire o samog projekta i moe aobuhvati itavo poslovanje. Sari ve grupe metoa: intuitivne i one bazirane na istoriji.

    Intuitivne metode su neophodne za identfikovanje novih rizika dok se one bazirane na istoriji

    oslanjaju na poznate taksonomije rizika.

    Nabrojademo neke o metoa tipa I:

    A. Intuitivne metodea. Mapiranje umomb. Brainstorimingc. Out-of-the-box razmiljanjed. Analogije

    B. Metode bazirane na istorijia. 10 naedih rizikab. Lista rizikac. Upitnik baziran na taksonomiji

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    18/33

    18

    Za razliku od tipa I, Tip II predstavlja potragu za rizicima koja se sprovodi u jasno definisanom

    kontekstu i fokusira se na rizike povezane sa rezultatima. Ovo je formalna i struktuiranija

    metoda i sastoji se od 6 faza:

    Faza I Oreivanje konteksta

    Faza II Prikupljanje podatakaFaza III Otkrivanje rizika

    Mapiranje Upitnici Procena rizika Modeli rizika

    Faza IV Dodeljivanje atributa

    Faza V Validacija

    Faza VI Lista

    4.1.1 Intuitivne metode

    Mapiranje umom

    Ova metoda koristi sposobnost ljudskog mozga koja se sastoji u prepoznavanju novih simptoma

    rizika putem mapiranja poznatih simtoma na buude probleme. Mapiranje neka moe a se

    zasniva na nauenim lekcijama osobe koja se njime bavi a nekaa moe biti izveeno iz

    kompleksnih istraivanja. Jeno je sigurno, um koji ispituje je u stanju a na neki nain uoi

    povezanosti koje mogu dovesti do rizika.

    Brainstorming

    Brainstorming predstavlja oblik grupnog rada u kome lanovi tima zajeno pokuavaju a

    pronau rizike pri emu jeni ruge inspiriu novim iejama. Ova metoda je najkorisnija kada

    treba identifikovati skrivene rizike.

    Da bi se povedala efikasnost procesa potrebno je struktuirati ga tim treba a razmilja o planuprojekta. Korisno bi bilo posmatrati WBS i skenirati projektne aktivnosti. Ako tim razmilja o listi

    zahteva moe uoiti inenjerske rizike, ako razmilja o mrei aktivnosti ientifikovade rizike

    meuzavisnosti i tako alje. Svi planovi i elovi projektnih planova mogu znaajno pomodi timu

    u ovom procesu.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    19/33

    19

    Out-of-the-box razmiljanje

    Bolje demo uoiti rizike ako stvari posmatramo iz eksterne i holistike perspektive. Rizici se ne

    kriju u utabanim stazama, oni vrebaju iz zona u koje se ree ie. Osoba koja posmatra rizike

    mora a naui a menja perspektive iz kojih posmatra. Razmiljanje o raznim alternativama

    zahteva kreativnost i distanciranje u onosu na uobiajene navike i proceure.

    Analogija

    Ljudi sa iskustvom upravljanja projektima razvijaju intuitivne vetine koje im omogudavaju a

    detektuju rizike. Kada uporeuju novi i stari proces koji su analogni, postoji verovatnoda a de

    se isti tipovi rizika koji su postojali ko starog javiti i ko novog procesa. Pore ovoga, moemo

    upotrebiti i sline metoe ientifikacije rizikajer de se i simptomi rizika najverovatnije ponoviti.

    4.1.2 Metode bazirane na istoriji

    10 najedih rizika

    Liste rizika koje su sastavili poznati autori i istraivai mogu znaajno a oprinesu procesu

    identifikacije rizika. One mogu da predstavljaju celokupno profesionalno iskustvo neke osobe.

    Svaki o tih rizika prestavlja novu perspektivu, prozor u rugaije gleanje na situaciju tj

    mogudnost a reevaluiramo na proizvo. Vedina znaajnih rizika u projektima razvoja softvera

    moe biti ientifikovana putem analize projekta kroz perspekticu objavljenih lista rizika. Neke

    od najpoznatijih listi su:

    1. Capre Jones-ovi softverski rizici2. Rex Black-ovi rizici u kvalitetu3. SEI-ova taksonomija rizika4. Najpopularnijih 10 rizika

    Analizirajmo Caper Jones-ovu listu:

    Caper Jones upravljanju rizicima pristupa kao upravljanju bolestima. On prestavlja skup rizikla

    ili simptomakao to zravstveni ranici ientifikuju zravstvene rizike ko svojih pacijenata i

    primenjuju preventivne mere.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    20/33

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    21/33

    21

    zahteva u pogledu

    performansi

    klijentu

    - efinisati stanare koji trebaju biti pradeni kako bi se ispunilikriterijumi performansi

    - pripremiti dizajn za ispunjavanje kriterijuma performansi

    - simulirati preformanse u kritinim oblastima

    - testirati uz pomod ogovarajude koliine poataka kaa je tomogude

    7 Nerealni planovi - ispregovarati bolje planove

    - identifikovati zadatke koji se mogu izvoditi paralelno

    - obezbediti resurse rano

    - identifikovati oblasti koje mogu biti automatizovane

    - ako kritini put nije u okviru plana, pregovarati sa klijentom

    8 Rad na novoj

    tehnologiji (hardver i

    softver)

    - razmisliti o dostavi iz nekoliko faza

    - poeti sa isporukum kritinih moula- prilikom kreiranja plana aktivnosti predvideti vreme za

    upoznavanje sa tehnologijom- obezbeiti vrene za obuku u koridenju nove tehnologije9 Nedovoljno znanja o

    biznisu

    - povedati interakciju sa klijentom i obezbediti prenos znanja- simulirati ili napraviti protitip biznis transakcije za klijenta i

    obezbediti njegovo slaganje

    10 Nedovoljan link ili

    spor rad

    - postaviti ogovarajuda oekivanja sa klijentom- planirati iskoridenost linka unapred- planirati optimalno iskoridenje linka

    Lista rizika

    Liste rizika se formiraju na osnovu iskustva i u tome je ova metoa slina prethonoj. One se

    sastoje o razliitih simptoma, pokazatelja i/ili imena ranije ientifikovanih rizika. Mogu se

    posmatrati kao voii za traenje rizika.

    Ove liste se kreiraju na osnovu kolektivnih iskustava organizacije. Moe se formirati posebna

    lista za za svaku fazu projekta i za svaki proces.

    Upitnik baziran na taksonomiji

    Upitnik baziran na taksonomiji je preloen o strane Instituta za softversko inenjerstvo

    (Carnegie Mellon) kao formalni i struktuirani nain za inentifikovanje rizika. Na primer, sledi

    skup atributa rizika je predstavljen taksonomiji za fazu zahteva:

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    22/33

    22

    a. Stabilnostb. Potpunostc. Jasnostd. Validnoste.

    Izvodljivost

    f. Prethodnig. Skala

    Potom se za svaki atribut postavljaju oreana pitanja, kao na primer:

    Stabilnost

    [1] Da li su zahtevi stabilni?

    (ne) (1a) Kakav je uticaj na sistem?

    Kvalitet Funkcionalnost Raspored aktivnosti Integracija Dizajn Testiranje

    [2] Da li se menjaju eksterni interfejsi?

    Osoba koja ientifikuje rizike moe koristiti ovakva pitanja kako bi ientifikovao rizike. Ova

    metoda nudi struktuirani nain za pronalaenje rizika u poznatim porujima.

    4.1.3 Tip II: projektno-specifina identifikacija rizika

    Faza I: Postavljanje konteksta

    Postavljanjem konteksta moe a se napravi greka izostavljanja rizika koji se nalaze van

    postavljenog konteksa a koji mogu biti znaajni. To je oekivana greka koja moe biti

    prihvadena jer se za otkrivanje rizika koji nisu vezani za konkretan kontekst koriste metode tipa

    I.

    Projektni tim moe oreiti teme za razliite sasatanke za ientifikovanje rizika, na primer:

    Identifikacija rizika proizvoda Identifikacija rizika dizajna Identifikacija rizika projekta

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    23/33

    23

    Identifikacija rizika biznisa Identifikacija rizika testiranja Identifikacija rizika ispravljanja bug-ova

    Faza II: Prikupljanje podataka

    Osoba koja se bavi identifikacijom rizika ustanju je da prepozna samo deo simptoma koji

    ukazuju na rizike. Ona de prepoznati one rizike sa kojima se sretala ranije a to je samo eo

    ukupnih rizika koji postoje na projektu. Kaa je pribeleila sve inikatore potencijalnih rizika,

    osoba prelazi na njihovu evaluaciju. Procenjuje se verovatnoda a de rizici prerasti u s tvarni

    ogaaj. Procenjuje se i uticaj rizika na ciljeve projekta.

    Da bi se uoili i rizici kojih osoba koja se bavi ientifikacijom rizika nije svesna, ona saziva

    brainstorming sastanak svih zainteresovanih strana. Razliite osobe koje uestvuju na sasta nkude ientifikovati razliite rizike tako a je ukupan broj uoenih rizika znatno vedi. Da bi se ovaj

    broj jo povedao poeljno je a menaer projekta voi sastanak i a se svi uesnici obro

    pripreme a za to je potrebno da imaju relevantne informacije. Sleeda lista sari opseg inputa

    koji mogu biti korisni u identifikovanju rizika.

    1. Korporativni ciljevi2. Projektni ciljevi3. Pretpostavke4. Ogranienja5. Zahtevi klijenata6. Povratne informacije od strane klijenata7. Benchmark studije8. Metriki poaci9. Osnove kapaciteta procesa10.Nalazi interne revizije kvaliteta11.Revizije menamenta12.Inspekcija i izvetaji testiranja13.Lista poznatih rizika14.Taksonimija rizika15.Sistem klasifikacije rizika16.Atributi rizika17.Istorija rizika18.Baza rizika

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    24/33

    24

    Faza III: Otkrivanje rizika

    Postoji nekoliko naina za otkrivanje rizika:

    Mapiranje koristedi ogovarajude inpute osoba koja se bavi ientifikacijom rizika skenira

    okruenje u potrazi za inikatorima rizika. Izmeu inikatora rizika i ogaaja rizika stojikompleksni proces mapiranja. Indikatori su samo pokazivai na ogaaje rizika. Za povedanje

    uspenosti procesa mapiranja se mogu koristiti razliiti alati.

    Upitnici prestavljaju jenostavan i brz nain za ientifikovanje rizika. Dovoljno je zamoliti

    ljude da navedu top 10 rizika koji se kasnije svi mogu uneti u bazu podataka.

    Modeli rizika ova kompleksna metoa omogudava ublju analizu i primenjuje se za

    pronalaenje skrivenih rizika koji nisu ientifikovani mapiranjem i koridenjem upitnika.

    Faza IV: Dodeljivanje atributa

    Kada je uoen ogaaj rizika on treba a bue opisan na koncizan i sarajan nain. Takoe,

    treba da mu se doda i jedinstveni identifikator, npr ID broj. Evo primera dodaljivanja atributa:

    1. Ime odeljenja organizacije2. Ime projekta3. lanovi tima osobe koja je ientifikovala rizik4. Datum identifikovanja rizika5. ID rizika6. Ime rizika7. Opis ogaaja rizikaPosle eisnisanja rizika vri njegova primarna evaluacija. Poaci te evaluacije su:

    8. Opis posledica ako nastupi rizik9. Verovatnoda nastupanja rizika (p) (skala: 0 o 10)10.Uticaj rizika (i) (skala: 0 do 10)11.Izloenost rizika (p) x (i)Sekundarni podaci i atributi:

    12.Poreklo (interno ili eksterno)13.Tip (poslovni ili tehniki)14.Najpogoeniji proces15.Najpogoeniji rezultat

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    25/33

    25

    16.Okia rizika17.Oekivano vreme nastupanja18.Vidljivost19.Priroda (hazarni, nominalni, trivijalni, ograniavajudi)20.

    Vlasnik rizika

    Faza V: Validacija

    Tokom braingstorming-a tim se truio a izlista najvedi mogudi broj rizika. Takav skup rizika

    sari efekte koje treba ukloniti, kao to su:

    Pogrean opisPogreno ime

    Pogrena klasifikacijaIrelevantnost u odnosu na projekatDvoznanostPonavljanja

    Nejasne razlike

    Valiaciju treba a vri tim koji je ientifikovao rizike zato to rugi moa nede modi a

    razumeju kontekst pa samim tim i a isprave pogrene iskaze.

    Faza VI: Lista

    Proizvo procesa ientifikacije rizika je lista valinih rizika. Ti rizici de, rai preglenosti, biti

    smeteni u tabelu zajeno sa ogovoarajudim atributima. Ova lista prestavlja osnovu za alju

    analizu.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    26/33

    26

    5 Odgovori na rizik

    Ogovor na rizik sastoji se iz ve faze. U prvoj fazi se pronalazi reenje ok se u rugoj onoimplementira uz pomod ogovarajudeg plana. Prva faza se obino izvrava bez problema jer je

    to isto intelektualni proces. Neolunost nastaje kaa plan treba sprovesti u elo. To se eava

    zbog toga to akcija uvek ukljuuje i promenu u koju treba uloiti dodatnu energiju i

    posvedenost.

    5.1 Specijalni tretman hazadrnih rizikaKomuniciranje rizika

    Od svih identifikovanih rizika, hazardni se prvi obrauju. Prvi korak je iskomunicirati rizik svim

    zainteresovanim stranama. Ovo je bitno isto kao i napad na rizik punih razmera.

    Pronalaenje reenja

    Postoje va aspekta u reavanju rizika: jean je smanjivanje anse a se rizik materijalizuje a

    rugi ojaavanje procesa koji su na uaru rizika. Oba aspekta trebaju biti oatno razraenakroz analizu alternativa i izbor najbolje opcije. Ako je rizik veoma hitan, mora se pronadi brzo

    privremeno reenje za kojim treba a slei ra na trajnijim reenjima.

    Akcioni plan

    Akcioni plan treba a sari sleede elemente:

    Zadatak

    Planirani poetakPlanirani kraj

    Resursi

    Stvarni poetakStvarni kraj

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    27/33

    27

    Neki rizici mogu imati svojstvo zlatnog sata, kao na primer ko rtvi saobradajne nesrede. U

    ovakvim sluajevima potrebna je vrlo brza reakcija za koju se ne mora pripremati celokupan

    akcioni plan.

    Organizacioni odgovor na hazard

    Hazardni rizici mogu imati uticaj na celokupnu organizaciju. Plan odgovora na rizik je u ovom

    sluaju samo inicijalni ogovor koji mora a bue praden oa tnim planovima. Odogovornost

    za savladavanje ovakvih rizika se prenosi na proces korporativnog planiranja.

    5.2 Ograniavajui riziciAko je verovatnoda pojavljivanja rizika 100% ona to nije rizik ved ogranienje. Izazov ili

    problem, ako se sigurno javlja, moe postati rizik samo po jenim uslovom: ka nismo u

    mogudnosti a ga reimo. Takoe, naa sposobnost moe a varira u vremenu to opet onosi

    nesigurnost. To znai i a ne moemo sa sigurnodu znati a li smo u stanju a reimo problem.

    Ovakvi problemi se mogu posmatrati kao ograniavajudi rizici.

    U upravljanju ovim rizicima koriste se tehnike sistemskog inenjeringa a projekat se tretira kao

    sistem sa ogranienjima. Ovaj pristup zahteva tretiranje svih ograniavajudih rizika na holistiki

    nain ali pore toga trai i a se ogovori i na iniviualne rizike.

    5.3 Odgovaranje na uobiajene pretnjeU ovu kategoriju spaa velika vedina ientifikovanih rizika.

    Na nivou projekta, ogdovara se na svaki rizik. Sa druge strane, na nivou organizacije postoji

    preveliki broj rizika a bi na svaki moglo pojeinano a se ogovori. Alternativa je a se rizici

    grupiu u kategorije i a se razmilja o tipovima rizika. Organizacija ne ogovara na pojeinane

    rizike ved na tipove rizika to voi o njihove prevencije.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    28/33

    28

    5.4 Plan odogovora na rizik

    Postoji vie tipova ogovora na rizike i vedina njih spaa u makar jenu o sleedih kategorija:

    Izbegavanje rizikaTransfer rizika

    Prihvatanje rizika

    Monitoring rizika

    Ublaavanje rizikaStrateki plan

    5.5 Izbegavanje rizika

    Ge go je to mogude, rizici moraju biti izbegnuti. To znai a treba napusiti oreene planove

    ili zaatke. Problem se javlja kaa su rizici povezani sa ciljevima. U tom sluaju se i ciljevi trebaju

    preispitati.

    5.6

    Transfer rizika

    Transfer rizika podrazumeva promene u prioritetima zadataka ili odogovornostima osoba koje

    su zaueneza postizanje nekih ciljeva. Na ovaj nain se rizici prenose na one lnove projektnog

    tima koji imaju najvie znanja, iskustva ili vetina za upravljanje konkretnim rizikom. Atributi

    rizika takoe mogu znaajno a se promene usled transfera. Na primer, uticaj rizika i

    verovatnoda pojavljivanja mogu ramatino a se smanje.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    29/33

    29

    5.7 Prihvatanje rizika

    Kada se rizici prihvate, njihovi uzroci i posledice se analiziraju i ljudi ih razumeju. Organizacija

    postaje jaka i oluna jer se javlja nova soliarnost u suoavanju sa rizicima.

    5.8 Monitorig rizika

    U ovom procesu se koriste vremenski planovi upravljanja rizicima. Reakcija na rizike mora biti

    pravovremena jer ne elimo a se bavimo rizicima koji jo nisu aktivni zbog toga to postoje

    rugi izazovi koje treba reiti. Za takve rizike efiniemo prihvatiljve nivoe i posmatramo i

    pratimo njihove okiae. Kombinacija ova dva faktora oreuje pravi trenutak za akciju.

    5.9 Ublaavanje rizika

    Cilj planova za ublaavanje rizika je maksimalno smanjivanje izloenosti riziku. Oni imaju ve

    komponente.

    Uloga prve komponente je a smanji verovatnodu poojavljivanja rizika. Da bi se ovo postiglo vri

    se analiza uzroka i razvija se plan za ublaavanje faktora koji izazivaju rizik.

    Druga komponenta ima za cilj a ublai gubitak ili tetu koja nastaje usle pojavljivanja rizika.

    To se postie ojaavanjem procesa ili kreiranjem robusnijeg proizvoda.

    Jasno je a ovakav prilaz sa ve razliite strane aje bolje rezultate o bilo kog pojeinanog

    pristupa. Uloga ovih planova nije a otklone rizike ali su i pore toga vrlo korisni jer povedavaju

    svest o rizicima.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    30/33

    30

    5.10 Strateki plan

    Uravljanje rizicima na nivou korporacije se razlikuje od onog na nivou projekta jer se u ovom

    sluaju rizici moraju prerupreiti. Zbog toga se kreiraju strateki planovi koji ue traju i imaju

    znaajno vede buete.

    Skeniraju se i interno i eksterno okruenje i u potrazi za rizicima. Pore toga, vri se i SWAT

    analiza u punim razmerima kako bi mogli a se postave novi strateki ciljevi.

    5.11 Eskalacija rizika

    Kada vlasnik rizika shvati da

    rizik ustvari ne pripada

    njegovom procesu ili cilju,

    on eskalira rizik do

    oovarajude osobe. Ako se

    rizik prenese do osobe koja

    je na istom nivou kao i

    prvobitni vlasnik re je o

    transferu rizika. Ako se

    prebacuje osobi koja se

    nalazi na vioj poziciji u

    organizacionoj strukturi

    govorimo o eskalaciji.

    Poenta eskalacije je da se

    rizik prebaci vlasniku koji

    upravlja vedim borjem

    procesa koji su na udaruistog rizika. Ekslacija se

    eava i kaa vlasnik rizika

    oseda a zbog nedostatka resursa, autoriteta ili iz drugih razloga nije u stanju da adekvatno

    ogovori na rizik. Meutim, ako ne postoji obostrano razumevanje izmeu starog i novog

    vlasnika rizika, ekslacija de biti neuspena. Sleeda skica iliustuje eskalaciju sa nivoa projekta na

    nivo organizacije. Ilustracija je ata na priloenoj slici *2+

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    31/33

    31

    5.12 Implementiranje odgovora na rizik

    Praktina strana ogovora na rizik je kreiranje organizacije koja je senzitivna u pogledu rizika. To

    je proces izgraivanja ogovarajude organizacione kulture, kulture koja rizike posmatra kao

    nagovetaje mogudih buudih problema i koja eli te probleme a rei. Izgranja kulture

    efikasnog upravljanja rizicima je ustvari kreiranje i usavravanje celokupne poslovne kulture u

    organizaciji.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    32/33

    32

    6 Zakljuak

    Za upravljanje rizicia u projektima razvoja softvera se moe redi a u isto vreme prestavlja i vi

    umetnosti i nauku. Za uspenost je neophono imati i osta znjanja i iskustva sa jene strane i

    kreativnosti i intucije sa ruge to sve mora biti pradeno poznavanjem kompleksnih procedura i

    alata.

    Cilj ovog rada je bio da da pregled osnovnih koncepata i metoda koji se koriste za upravljanje

    rizicima u projektima razvoja softvera i moe se koristiti kao polazna osnova za upoznavanje sa

    ovom tematikom. U njemu su opisani pojam rizika, elementi i modeli procesa upravljanja

    rizicima, naini klasifikacije rizika, metoe entifikacije rizika kao i naini koji se mogu primeniti

    prilikom odgovora na rizike.

  • 8/7/2019 Upravljanje rizicima u projektima razvoja softvera

    33/33

    7 Literatura[1] James Taylor, Managing Information Technology Projects: Applying Project Management

    Strategies to Software, Hardware, and Integration Initiatives, AMACOM, 2004, ISBN

    0814408117

    [2] C. Ravindranath Pandian,Applied Software Risk Management - A Guide for Software Project

    Managers, Auerbach Publications, 2007, ISBN 0-8493-0524-1

    [3] Robert T. Futrell, Donald F. Shafer, Linda I. Safer, Quality Software Project Management,

    Prentice Hall PTR, 2002, ISBN 0-13-091297-2

    [4] Pankaj Jalote, Software Project Management in Practice, Addison Wesley, 2003, ISBN 0-201-

    73721-3