Obvladovanje generi nih rizikov na projektih razvoja programske opreme
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

Obvladovanje generičnih rizikov na projektih razvoja programske opreme PowerPoint PPT Presentation


  • 80 Views
  • Uploaded on
  • Presentation posted in: General

Obvladovanje generičnih rizikov na projektih razvoja programske opreme. Pripravila: Irena Krajnc, NKBM. Kratka vsebina. Statistika Izvedba projektov Vzroki za uspeh in neuspeh projektov Upravljanje z uporabniškimi zahtevami Pomanjkljivo sodelovanje z uporabniki

Download Presentation

Obvladovanje generičnih rizikov na projektih razvoja programske opreme

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Obvladovanje generi nih rizikov na projektih razvoja programske opreme

Obvladovanje generičnih rizikov na projektih razvoja programske opreme

Pripravila: Irena Krajnc,NKBM


Kratka vsebina

Kratka vsebina

  • Statistika

    • Izvedba projektov

    • Vzroki za uspeh in neuspeh projektov

  • Upravljanje z uporabniškimi zahtevami

    • Pomanjkljivo sodelovanje z uporabniki

    • Razvoj uporabniških zahtev

    • Upravljanje s spremembami

  • Projektno vodenje

    • Podpora vodstva in sponzorstvo projekta

    • Upravljanje s tveganji

    • Strokovno znanje in zasedba vlog v projektnem teamu

  • Nadzor projekta

    • Generalni indikatorji statusa projekta

    • Opozorilni znaki in korektivne akcije

    • Bazični ukrepi za vzpostavitev kontrole projekta


  • Izvedba projektov

    Izvedba projektov

    • Povprečna prekoračitev sredstev je za velike organizacije 178%, za srednje 182% in za majhne 214%

    • Povprečna prekoračitev rokov je za velike organizacije 230%, za srednje 209% in za majhne 239%

    • Povprečen % dokončanih funkcionalnosti je za velike organizacije 42%, za srednje 65% in za majhne 74%


    Vzroki za uspeh

    Vzroki za uspeh

    Vzroki za uspeh % vprašanih Skupina

    Sodelovanje uporabnikov 15.9 % A

    Podpora in sponzorstvo vodstva 13.9 % B

    Čiste in stabilne uporabniške zahteve 13.0 % B

    Ustrezno planiranje 9.6 % B

    Realistična pričakovanja 8.2 % A

    Krajša obdobja 'mejnikov' 7.7 % B

    Usposobljen team 7.2 % C

    Jasno lastništvo projekta 5.3 % AB

    Jasna vizija in cilji projekta 2.9 % AB

    Trdo delo teama 2.4 % C

    Ostali vzroki 13.9 % C


    Vzroki za neuspeh

    Vzroki za neuspeh

    Vzroki za neuspeh % vprašanih Skupina

    Pomanjkljivo sodelovanje z uporabniki 12.8 % A

    Nepopolne zahteve in specifikacije 12.3 % A

    Spreminjajoče se zahteve in specifikacije 11.8 % A

    Pomanjkanje podpore in sponzorstva vodstva 7.5 % B

    Nekompetentnost teama 7.0 % C

    Pomanjkanje sredstev 6.4 % B

    Nerealistična pričakovanja 5.9 % A

    Nejasni cilji 5.3 % B

    Nerealistično postavljanje rokov 4.3 % AB

    Nepreizkušena tehnologija 3.7 % C

    Ostalo 23.0 % D


    Pomanjkljivo sodelovanje z uporabniki

    Pomanjkljivo sodelovanje z uporabniki

    • Kritični dejavnik

      • kdo je pravi in odgovorni uporabnik.

      • uporabniške zahteve

    • Pogoste napake

      • spregledamo razliko med skupinami uporabnikov (vodje, operativci)

      • prevelika ‘kreativnost’ programerjev

      • nepotrebno obremenjevanje programja

      • vključitev šele v uporabniškem testu - t.i. sprožilec – poraba časa in stroški projekta začnejo nekontrolirano naraščatiprav v tej točki.

    • Preprečevanje:

      • vgrajevanje manjših, uporabniško orientiranih neformalnih revizij

      • razmerje med odpravljenimi in obstoječimi težavami.


    Razvoj uporabni kih zahtev

    Razvoj uporabniških zahtev

    • Proces definiranja zahtev

      • zbiranje kandidatov za zahteve

      • specificiranje zahtev

      • analiza zahtev

      • razvrščanje zahtev po njihovi pomembnosti

  • Predvidevanje in občutek za posledice

    • kaj se lahko zgodi zanesljivo, verjetno ali zelo malo verjetno

    • kakšne analize bo mogoče pridobiti iz podatkov čez nekaj let

    • s katerimi zunanjimi subjekti je IS povezan

    • kako občutljiv bo naš sistem za spremembe od zunaj


  • Upravljanje s spremembami

    Upravljanje s spremembami

    • dobro definirane uporabniške zahteve

    • discipliniranje uporabnikov

    • 'Change board'

      • v kakšni meri se bo produkt izboljšal,

      • koliko uporabnikov potrebuje novo oz. spremenjeno funkcionalnost

      • kakšni so ti uporabniki (operativni ali pisarniški delavci, ki si lahko pomagajo tudi z drugimi orodji)

      • stroški

      • podaljšanje trajanja projekta

      • časovno zaporedje

      • ali jo je mogoče združiti

      • vpliv na stabilnost produkta

      • dodatni viri


    Podpora vodstva in sponzorstvo projekta

    Podpora vodstva in sponzorstvo projekta

    • večinoma formalne narave

    • močna ( vsaj formalno ) na začetku projekta, skozi življenjsko dobo projekta pa vedno bolj popušča

    • možna menjava vodstva

    • premajhno znanje vodstva s področja poslovne informatike in vodenja projektov

    • potrebno je poznavanje vsaj generalnih indikatorjev statusa projekta


    Strokovno znanje in zasedba vlog v projektnem teamu

    Strokovno znanje in zasedba vlog v projektnem teamu

    • V fazi razvoja uporabniških zahtev je narejenih cca 20 % 'GO – NO GO' odločitev(Stroški za odpravo napake od 1: 50 do cca 1 : 200 )

      • primerni visoko strokovno usposobljeni razvijalci

      • neizkušeni člani teama - opazovalci in kot neformalni revizorji rezultatov

  • V fazi designa, kodiranja in testiranja

    • neizkušeni člani teama lahko oz. morajo v teh fazah aktivno sodelovati

    • okrepiti zasedbo

  • Strokovne funkcije nadzora projekta

    • izkušen kader


  • Generalni indikatorji statusa projekta

    Generalni indikatorji statusa projekta

    • pogostost menjave planov/mejnikov

    • doslednost v organizacijski strukturi projekta v primerjavi z originalnimi plani

    • nihanja v projektni zasedbi in ocene velikosti sistema

    • težavnost pristopa do informacij o projektu

    • količina nadur za doseganje posameznega cilja

    • nivo poznavanja in kontroliranja podrobnosti razvijanega sistema s strani projektnega vodje in sponzorja projekta


    Opozorilni znaki in korektivne akcije

    Opozorilni znaki in korektivne akcije

    • problemi z zahtevami in specifikacijami

      • število uporabniških zahtevkov, ki še niso specificirani je višje od povprečja na podobnih projektih in ne upada

      • število postavljenih uporabniških vprašanj je višje od števila odgovorjenih oz. narašča

      • veliko število modifikacij že izdelanih specifikacij

      • veliko število zahtevkov za spremembe oz. naraščanje števila

  • problemi z designom sistema

    • število razvitih komponent sistema je manjše kot je predvideno v planu za to fazo - slabe smernice vodje teama, neizkušenost razvijalcev, nova tehnologija oz. pogoste spremembe zahtevkov


  • Opozorilni znaki in korektivne akcije1

    Opozorilni znaki in korektivne akcije

    • problemi z implementacijo sistema

      • število kodiranih, testiranih in integriranih komponent sistema je manjše kot je predvideno v planu za to fazo

      • število kodiranih, testiranih in integriranih komponent sistema je dosti večje kot je predvideno v planu za to fazo

      • odpravljene napake se znova pojavljajo

  • problemi pri testiranju sistema

    • faza testiranja je zaradi zakasnitev predhodnih faz občutno skrajšana

    • nizka količina odkritih napak


  • Opozorilni znaki in korektivne akcije2

    Opozorilni znaki in korektivne akcije

    • problemi pri planiranju razvoja

      • razvojne aktivnosti so neenakomerne, storilnost pade takoj po doseganju mejnika

        • osebje dela na projektu samo delno

      • konstantno zamikanje rokov

        • strokovnost teama je bila precenjena oz. smernice niso dovolj stabilne

      • zamik rokov zaradi zamenjave članov teama

        • dva nova člana z visokim nivojem znanja in izkušenj namesto vsakega ključnega člana

        • ena oseba namesto neizkušenegačlana teama, znanje in izkušnje vsaj en nivo višje


    Bazi ni ukrepi za vzpostavitev kontrole projekta

    Bazični ukrepi za vzpostavitev kontrole projekta

    • Ustavitev trenutnih aktivnosti na prizadetem delu sistema in ocenitev škode

    • Zmanjšanje števila osebja na upravljiv nivo

    • Zamenjava članov teama z izkušenimi razvijalci

    • Zaključek predhodnih (!) aktivnosti

    • Povečanje in razširitev vodstvenega nadzora

    • Povečanje števila vmesnih produktov

    • Zmanjšanje obsega projekta

    • Revizija projekta z neodvisnimi revizorji in UPOŠTEVANJE njihovih priporočil


    Zaklju ek

    Zaključek

    • Vprašanja in odgovori


  • Login