U ovoj lekciji obrađivaćemo:

    • oblast Menadžment softverskog inženjerstva (Software Engineering Management)
    • specifičnosti upravljanja softverskom proizvodnjom
    • upravljanje okvirom projekta


Menadžment softverskog inženjerstva se bavi menadžmentom i merenjem softverskog inženjerstva. Menadžment softverskog inženjerstva se može definisati kao primena aktivnosti planiranja, koordinacije, merenja, monitoringa, kontrolisanja i izveštavanja radi obezbeđivanja da se razvoj i održavanje softvera izvodi sistematično, disciplinovano i kvanitfabilno.

Šema podoblasti koje pokriva Menadžment softver. inženjerstva je data na sledećoj slici:

Slika 1.

Podoblasti menadžmenta softverskog inženjerstva (Software Engineering Management)

Podoblast Initiation and Scope Definition se bavi odlukom o iniciranju projekta softverskog inženjerstva.

Podoblast Software Project Planning se bavi aktivnostima preduzetim radi pripreme za uspešno softversko inženjerstvo iz perspektive menadžmenta.

Podoblast Software Project Enactment se bavi generalno prihvaćenim aktivnostima menadžmenta softverskog inženjerstva koja se dešavaju tokom procesa softverskog inženjerstva.

Podoblast Review and Evaluation se bavi sa osiguranjem da je softver zadovoljavajući.

Podoblast Closure obuhvata aktivnosti nakon kompletiranja (post-completion) projekta softverskog inženjerstva.

Software Engineering Measurement se bavi sa efektivnim razvojem i implementacijom programa merenja u organizaciji softverskog inženjerstva (IEEE12207.0-96).

Specifičnosti upravljanja softverskom proizvodnjom

Postoje specifičnosti svojstvene upravljanju proizvodnjom softvera za razliku od drugih disciplina. Percepcija klijenta je takva da često postoji nedostatak razumevanja za kompleksnost sadržanu u procesu softverskog inženjerstva, posebno u relaciji uticaja promena zahteva. Neizbežno je da će sam proces softverskog inženjerstva generisati potrebu za novim zahtevima ili promenom postojećih. Kao rezultat toga, softver se više razvija iterativno nego kao sekvenca zatvorenih taskova. Softversko inženjerstvo neophodno inkorporira aspekte kreativnosti i discipline, i čini veoma teškim poslom, držati odgovarajući balans između ove dve suprotnosti. Stepen noviteta i kompleksnosti softvera je često ekstremno veliki. Postoji veliki stepen promena u razvojnoj tehnologiji.

Menadžment ljudskih resursa

Veliki uticaj na softversko inženjerstvo ima i menadžment ljudskih resursa. Pravila i procedure za zapošljavanje, trening, i motivaciju osoblja, kao i praćenje razvoja karijere zaposlenih predstavljaju dugoročno ključan faktor razvoja organizacije. Menadžment ljudskih resursa u oblasti softverskog inženjerstva predstavlja poseban izazov, s obzirom na brzinu promena tehnologije i potrebnu obučenost zaposlenih. Komunikacioni menadžment je posebno važan zbog potreba preciznog razumevanja, između članova tima i usled kompleksnosti zahteva i njihovog jasnog razumevanja. Potreba za jasnom sveukupnom vizijom ne samo softvera koji se razvija, već i softvera koji već postoji u organizaciji. Softver Reuse u tom slučaju igra veliku ulogu u održavanju i unapređivanju produktivnosti.

Uticaj Project Management-a

Uticaj Project Management-a ostvaruje se kroz oblasti:

    • Project Integration Management
    • Project Scope Management
    • Project Time Management
    • Project Cost Management
    • Project Quality Management
    • Project Human Resource Management
    • Project Communications Management


Menadžement i merenja

Oblast menadžment softverskog inženjerstva se sastoji od Software Project Management procesa, u prvih pet podoblasti, i Software Engineering Measurement procesa u poslednjoj podoblasti. Iako se ove dve oblasti često razmatraju odvojeno, postoje zajedničke veze koje ih dovode u sferu zajedničkog tretmana. Management Process predstavlja aktivnosti koje se sprovode u cilju obezbeđivanja da se proces softverskog inženjerstva izvodi na način u skladu sa ciljevima i standardima organizacije. Merenje (Measurement) predstavlja dodeljivanje vrednosti i značenja aspektima softverskog inženjerstva (proizvodima, procesima, i resursima) i modelima izvedenim iz njih.

Planiranje razvojnog projekta softvera

Ciklus razvoja softvera se sastoji iz više koraka, pri čemu se neki od njih ponavljaju sve dok se sistem ne završi, a naručilac i korisnik ne budu zadovoljni. Pre nego što se potvrde sredstva za realizaciju razvoja ili održavanja softvera, korisnik obično želi da proceni koliko će projekat da košta i traje. U tom smislu bitno je ispitati aktivnosti koje su neophodne za planiranje razvojnog projekta softvera i upravljanje njime. Upravljanje projektima odnosi se na definisanje i planiranje projekta, kao i na postupke kontrole i zaključivanja.

Upravljanje projektom

Svakim projektom treba upravljati. Što je projekat veći i kompleksniji, to postoji sve veća potreba za formalnim, standardizovanim i strukturiranim procesom. Prvobitni načini razvoja bili su neformalno vođeni od strane pojedinaca.

Uvođenje formalnog pristupa i stepen njegove primene zavisi i od veličine projekta. Možda je moguće držati u mislima čitav projekat i upravljati njime, ako taj projekat traje do 200 sati i u njega su uključene dve ili tri osobe. Projektom koji traje 1000 sati i uključuje 5 osoba, više nije moguće upravljati na isti način. Projekat u koji je uključeno 10 osoba i za njegovo izvršenje je potrebno 5000 sati, zahteva formalniji pristup upravljanju, a projekat sa 20 ljudi i 20000 sati - još formalniji, itd.

Koristi planiranja

Greške koje se kasnije javljaju tokom projekta, najčešće je prouzrokovao manje kvalitetan postupak planiranja. Većina projekata ima dogovorene krajnje rokove. Rokovi danas postaju sve kraći i kraći. Ugovaranje rokova koji su agresivno kratki prisiljava menadžere projekta da započnu projekat što je ranije moguće.

Pre nego što započne projektni posao, potrebno je provesti okvirni postupak planiranja, da bi se osiguralo zajedničko razumevanje i slaganje oko projektnih poslova. To nikako nije izgubljeno vreme ili suvišni posao, već je vreme u kojem menadžeri projekta osiguravaju da projektni tim i klijent stvore zajedničku percepciju rezultata projekta, vremena kad će projekat biti završen, koliko će koštati, ko će obavljati posao i na koji način.

Zatim, neophodnost postizanja slaganja i zajedničkog shvatanja projektnih ciljeva, rezultata, opsega, rizika, troškova, pristupa, ..., određivanje valjanosti originalnog poslovnog slučaja. Npr. projekat koji zahteva 10000 radnih sati može imati poslovnog smisla. Ako detaljniji postupak planiranja rezultira s tačnijom procenom od 20000 radnih sati, projekat više možda neće imati poslovnog smisla.  

Jedna od koristi je i osiguravanje dostupnosti resursa kad oni budu potrebni.

Definisanje osnovnih odrednica visokog nivoa opštosti, uz pomoć kojih se može ocenjivati uspeh projekta. Ocenjivanje postupaka upravljanja projektom unapred, uz klijentovu pomoć.

Manji projekti

Logično je da manji projekti zahtevaju kraći ciklus planiranja od većih projekata. Trud koji je potreban da bi se izvršilo planiranje zavisi od količine informacija i nivoa detaljnosti koju treba obraditi i dokumentovati. Trajanje definisanja posla zavisi od trajanja pronalaženja i dokumentovanja informacija, kao i o trajanju pridobijanja saglasnosti i odobrenja od strane klijenta. Pre nego što ciklus životnog veka projekta započne (analiza, projektovanje, konstrukcija, itd.), treba postaviti brojna pitanja dobijena postupkom planiranja. Za manje projekte mnogi od tih uslova su zadovoljeni implicitno ili neformalno, ali što je projekat veći, to postaje važnije formalno i eksplicitno zadovoljavanje postavljenih kriterijuma.

Upravljanje okvirom projekta

Opseg je način kojim se opisuju granice projekta. Opseg definše šta će se realizacijom projekta isporučiti, a šta ne. Razlozi neuspeha projekta su da tim nije utrošio dovoljno vremena za definisanje posla i/ili nije postojao definisan posao upravljanja opsegom. Čak i ako je menadžer projekta učinio dobar posao pri definisanju opsega, teži deo dolazi u fazi upravljanja samim projektom u dogovorenim granicama (opseg projekta). Bez pravilne definicije opsega kroz definisanje radnih koraka, nemoguće je efikasno upravljati opsegom projekta. Dozvola izmene opsega projekta uključuje izlazak izvan opsega koji je početno dogovoren u “definiciji projekta“. Ako je opseg nejasan ili ostavlja prostor za interpretaciju, klijent može proglasiti izmenu u opsegu, a menadžeru projekta će biti teško upravljati opsegom projekta.

Svrha upravljanja promenama opsega je zaštita tekuće, odobrene definicije projekta i tekućih, odobrenih poslovnih zahteva. Kada je projekat definisan, određene pretpostavke su načinjene o projektnim rezultatima koji će biti realizovani. Ako se isporuke menjaju tokom projekta (obično to znači da klijent želi dodatne stavke), kalkulacija troškova, angažman resursa i trajanje više neće važiti. Menadžer projekta ima pravo da upozori klijenta da će trošak, angažman sati i/ili trajanje biti modifikovani (obično povećani), tako da odgovore zahtevima klijenta za ovaj dodatni posao. Ovaj novi ukalkulisani trošak, angažman i trajanje sada postaju odobreni i uključeni u opseg projekta.

Dodaj komentar Sviđa mi se - (1) Ne sviđa mi se - (1)    

  • Software Engineering Management 1
  • Software Engineering Management 2
  • Software Engineering Management 3