POGREŠKE I SAVJETI PRI UPRAVLJANJU SOFTVERSKIM PROJEKTOM

1. POGREŠKE I SAVJETIPRI UPRAVLJANJUSOFTVERSKIM PROJEKTOM Luka Drvoderić

2. Sadržaj • Uvod • Uobičajene pogreške i savjeti vođenja projekta • Razvoj softvera nije industrijski proces • Trajanje projekta i troškovi nisu zamjenjivi • Najbolji podaci za usporedbu su vlastiti • Izgubljenost u detaljima • Promjene koštaju • Planiranje i nadgledanje projekta • Samo procjena ≠ projektni plan • Razvoj softvera više je od samog kodiranja • Zaključak

3. Uvod • Je li upravljanje razvojem softvera jednostavno poput čitanja uputa što činiti, a što ne činiti? • Činjenice pokazuju da većina projekta • Prekoračuje budžet • Ne zadovoljava planove • Ne ispunjava zahtjeve korisnika • Upravljanje zahtjeva sposobnog lidera s iskustvom naprednog planiranja i nadgledanja projekta • Kakva bi trebala biti naša očekivanja? • Što trebamo nadgledati? • Kako trebamo reagirati?

4. Razvojsoftvera nije industrijski proces • Industrijski proces • Dodavanje dodatne proizvodne linije ili povećanje brzine stroja smanjuje proizvodno vrijeme • Jednostavno je odrediti izlaz procesa, što činiti i kako • Razvoj softvera je istraživački proces • Dodatna stavka procesa češće • Manje pridonosi jasnom uvidu što i kako treba raditi • Više povećava troškove i degradira kvalitetu konačnog proizvoda • Upravljanje procesom zahtjeva više napora i vremena • Što su zahtjevi apstraktniji • Što je razvojni tim manje upoznat s tematikom i okolinom

5. Trajanje projekta i troškovi nisu zamjenjivi • Veza između trajanja i troškova je nelinearna (eksponencijalna) • Postoji područje optimalnog odnosa trajanja i troškova koje ograničuje ono što je nemoguće ili pak nepraktično • Nerealno planiranje trajanja je broj jedan razlog neuspjeha većine projekata

6. Najbolji podaci za usporedbu su vlastiti • Uloženo vrijeme, novac, prestiž i trud nisu ništa u usporedbi sa skandaloznim odnosom kompanija koje • ne prikupljaju podatke • ne analiziraju podatke • ne koriste plan troškova i kvalitete podataka • Odgovoran pristup daje kompozitnu sliku razvoja • Identificira slabosti i jakosti • Procjene povezuje s realnošću • Poboljšava ostvarive ciljeve • Onim što mjerimo možemo racionalno upravljati • “Industrijski” podaci mogu biti korisni ali nam ne mogu dati jasnu sliku o postupcima u našoj organizaciji kao ni o kvaliteti upravljanja projektom

7. Izgubljenost u detaljima • U početku planiranja softverskog projekta važno se fokusirati na bitna, temeljna pitanja • Znamo li dovoljno da učinimo inteligentnu procjenu projekta? • Jesu li projektni plan, troškovi i kvaliteta zahtjeva ostvarivi? • Možemo li kadrovski voditi projekt? • Postoji li sporazum ukoliko se promijeni tok izvođenja procesa? • Većina projekata ne uspijeva upravo zato što se ne obraća pažnja na važna pitanja prije nego se krene u detalje • Važno je usmjeriti se na bitno i izbjegavati preplavljivanje informacijama koje nismo u mogućnosti procesirati

8. Promjene koštaju • Softverski projekt je osjetljiv balans između • Zadataka koje je potrebno ostvariti • Kadra koji obavlja zadatke • Vremena u kojem je posao obavljen • Promjena jednog od ovih parametara utječe na preostala dva • Što se promjene zahtijevaju kasnije to je razvoj skuplji • Razvoj softvera je istraživački proces • Prethodno planirati i osigurati naknadu za promjene u proračunu i satnici (ozbiljni projekti imaju prostora za eventualno loš početak ili neočekivane događaje) • Za svaku promjenu ocijeniti njezin učinak na troškove i satnicu potrebnu za prilagodbu ukoliko se promjena prihvati

9. Planiranje i nadgledanje projekta • Svaki projekt treba imati projektni plan koji specificira • Što se projektom isporučuje • Kadrovsku podjelu • Satnicu projekta • Plan se mora definirati uzimajući u obzir rezultate prethodnih projekata • krajnje odluke moraju biti realistične i ostvarive u skladu s mogućnostima • Važno je ustrajno nadgledati projekt kada je on u tijeku • Tendencija preskakanja miljokaza i pomicanja izvještavanja u budućnosti nije dobra navika • Suočavanje s problemima lakše je u ranijoj fazi kada još postoje alternative koje se mogu uzeti u obzir

10. Samo procjena ≠ projektni plan • Kod procjene projekta uvijek su prisutna nesigurnost • Veličine projektnih zahtjeva • Produktivnosti razvojnog tima • Nedostatak informacija za egzaktno predviđanje • Procjenom možemo približno vrednovati nesigurnost troškova i trajanja • Analizirati najgori, najbolji i najčešći slučaj • Predstaviti postotnu procjenu sigurnosti • Procjena daje samo globalnu sliku projekta i razine rizika • Projektni plan daje detaljniju sliku o pojedinim zadacima, ulogama, odgovornostima i kritičnim situacijama

11. Razvoj softvera više je od samog kodiranja • Koliko odabir programskog jezika utječe na produktivnost projekta? • Jezik koji se koristi u razvoju mora biti odgovarajući za ostvarenje postavljenih ciljeva • Vještina baratanja razvojnog tima programskim jezikom važnija je od samih mogućnosti programskog jezika • 70 % napora na projektu odnosi se na prikupljanje zahtjeva, analizu, projektiranje, upravljanje, konfiguriranje, dokumentiranje, testiranje • Smanjenje napora kodiranja za 50 % prouzročit će tek 15 % smanjenja ukupnog napora uloženog u projekt

12. Zaključak • Što je važno imati na umu pri vođenju projekta? • Razvoj softvera nije industrijski proces • Trajanje projekta i troškovi nisu razmjenjivi • Najbolji podaci za usporedbu su vlastiti • Izbjegavaj izgubljenost u detaljima • Promjene koštaju • Nadgledanje projekt u izvođenju • Samo procjena ≠ projektni plan • Razvoj softvera više je od samog kodiranja • Zašto je važno planirati? • Planiranjem dolazimo do realnih projektnih mjera • Otkrivamo da li smo efikasniji od konkurenata • Otkrivamo da li točnost procjena unapređuje razvoj • Saznajemo koje su normalne performanse za kvalitetu i produktivnost projekta

13. Literatura • QSM The intelligence behind successful software projectshttp://www.qsm.com/ • Software Engineeringhttp://www.csc.liv.ac.uk/~mjw/teaching/soft-eng/ • Software project managementhttp://en.wikipedia.org/wiki/Software_project_management