You are on page 1of 10

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

6. Koncepte t menaxhimit t projekteve t zhvillimit t


software
Menaxhimi i projektit siguron dorezimin e nje sistemi cilesor, ne kohe dhe brenda buxhetit.
Dorezimi brenda buxhetit kerkon qe menaxheri te vleresoje dhe te caktoje burimet e nevojshme
(njerez, trajnime, mjete). Respektimi i afateve kohore kerkon qe menaxheri te planifikoje punet
e nevojshme dhe te kontrolloje statusin e projektit bazuar ne detyrat dhe produktet e punes.
Realizimi i nje zgjidhjeje cilesore kerkon qe menaxheri te arrije te krijoje nje mekanizem te
raportimit te problemeve dhe te kontrolloje statusin e produktit lidhur me defektet dhe rreziqet.
Te tre perberesit (cilesi, buxhet, kohe) jane thelbesore per suksesin e projektit.
Projektet kane kompleksitet dhe i nenshtrohen ndryshimit. Produktet komplekse kane
nevoje per nje numer te madh pjesmarresish me aftesi te ndyshme dhe me formime te
ndryshme. Tregjet konkurrues dhe kerkesat evoluese shkaktojne ndryshime ne zhvillim,
rishperndarje te burimeve, etj. Kjo veshtireson gjurmimin e statusit te projektit. Ndryshimi ne
nje pjese te projektit shpesh prek pjese te tjera te tij. Psh shtimi i nje karakteristike te re tek nje
element qe do ti dorezohet klientit kerkon me shume kohe dhe me shume burime. Shkurtimi i
zgjatjes se projektit shpesh sjell mosshperndarje te disa karakteristikave te sistemit.
Menaxhimi i projektit mund te konsiderohet si procesi i drejtimit te nje projekti nga
fillimi ne fund duke perdorur modele menaxhimi. Aktivitetet kryesore te menaxhimit te projektit
jane:
Planifikimi: specifikimi i rezultateve qe do te arrihen dhe i aktiviteteve dhe detyrave qe
duhen per te prodhuar keto rezultate, krijimi i orarit dhe i vleresimit te burimeve te
nevojshme (njerez, fonde)
Organizimi: percakton organizimin e projektit dhe identifikon rolet dhe pergjegjesite.
Rolet shoqerohen me punet qe jane idenfitikuar gjate planifikimit.
Kontrolli: aktivitete per tu siguruar qe po idenfitikohen aktivitetet qe po devijojne nga
planifikimi. Rikonfirmimi i performances qe pritet nga njerezit, kontrollimi i veprimeve
qe duhen kryer dhe rezultateve qe priten, adresimi i problemeve qe dalin, shkembimi i
informacionit mes njerezve qe kane nevoje per te.
Perfundimi: lidhet me perfundimin e projektit. Perfshin dorezimin e sistemit tek klienti
sipas kritereve te pranimit qe jane percaktuar ne marreveshjen fillestare te projektit,
instalimi i sistemit ne mjediset e klientit, rishikimi i historise se projektit per te mesuar
nga pervoja, etj.
Projektet drejtohen nga menaxheret e projekteve. Menaxheret nuk prodhojne produkte
specifike dhe te prekshem. Ata koordinojne burimet ne menyre qe te tjeret te prodhojne
produktet e duhura. Menaxhimi i nje projekti zhvillimi software kerkon aftesi drejtuese dhe
sociale, per te parashikuar probleme te mundshme dhe per te reaguar si duhet ndaj tyre.
Menaxheret nuk prodhojne rezultate te prekshme, pro ata kane funksion dhe rol ky ne
perfundimin e suksesshem te projektit.
Menaxheret nuk marrin vendime teknike dhe shpesh nuk e kane formimin teknik per ta
bere nje gje te tille. Ata jane pergjegjes per koordinimin dhe administrimin e projektit, per te
siguruar sistem me cilesi te larte dhe brenda buxhetit dhe afateve kohore. Mjetet qe kane ne
dispozicion menaxheret per te permbushur detyren e tyre jane planifikimi, kontrolli, menaxhimi
i rrezikut, perballimi i problemeve.

1
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

5.1 Formimi i ekipit t puns


Disa projekte IT kan t njjtin ekip pune q nga fillimi e deri n fund t projektit. T tjer kan
personel t ndryshueshm n faza t ndryshme t projektit. Pavarsisht se kur (n fillim t
konceptimit t projektit apo pasi sht br nj prcaktim dhe planifikim i tij), duhet t
formohet ekipi. Do t ishte ideale nse ekipi do t prfshihej n prcaktimin, organizimin,
planifikimin dhe ekzekutimin e projektit. Kjo nuk sht gjithmon e realizueshme n botn reale,
por sht mir q ky t jet objektivi gjat krijimit t ekipit. Disa nga arsyet pr kt jane:
- ekipi mund t ofroj ekspertiz q menaxheri vet nuk e ka.
- ekipi ofron ide dhe perspektiva t ndryshme nga ato t menaxherit
- ekipi ofron kontakte dhe informacione q kan lidhje me projektin me pjes t tjera t
organizates
- ekipi prbn m shum mendje dhe kapacitete pr t kryer projektin.
Por arsyeja m e rendesishme pr t formuar nj ekip q n fillim sht pronsia. Nqs ekipit i
jepet nj plan i hartuar dhe i percaktuar pr ta implementuar, ai nuk do t ishte entuiziast pr
detyren sepse ai nuk ka qen pjes e modelimit, zhvillimit dhe planifikimit t tij. Njerezit jane me
t prirur t marrin pjese plotesisht n nj projekt, kur ata kan qen pjes e prcaktimit,
organizimit dhe planifikimit t tij. Ata kan ndjenj pronsie mbi projektin dhe zakonisht
punojn shum q ai t kt sukses. Mqs menaxheri i projekteve IT zakonisht menaxhon nj
ekip mbi t cilin ka pak autoritet formal organizimi, atehere sht e rendesishme q ai t jet n
gjendje t krijoje nj ndenje dedikimi tek ekipi i tij, n mnyr q t kt me t lehte
menaxhimin pr ta mbyllur n kohe, buxhet dhe me cilesine e kerkuar projektin.
Hapi i par n percaktimin e ekipit sht t prcaktohet natyra e njerzve q krkohen dhe
jo njerzit specifik. Mund t fillohet duke br vzhgime mbi mjedisin n t cilin do t
zhvillohet projekti e me konkretisht n:
1. elementt organizativ. Cilat departamente, divizione, seksione t kompanis duhet t
prfshihen dhe ekipin e projektit?
2. elementt teknik. Cilt jan specialistt teknik q duhet t prfshihen n ekip? A ka
tipe t ndryshme teknologjish q duhet t prfshihen apo do t ket koordinime
(mnyra inxhinierike, gjuh programuese, paisje)
3. elementt logjistik. Ku do t jen t vendosur antart e ekipit? Do t jen afr
fizikisht, apo n distanc? Si do t koordinohen veprimet e tyre?
4. element personal. Cfare tipi marrdhniesh formale ose jo formale ekzistojn
ndrmjet antarve t ekipit (ose antarve potencial)
Pasi konsiderohen elementt e msiprm, duhet t filloj identifikimi i roleve dhe prgjegjsive.
Kjo gje duhet br duke mos pasur n mend nj person specifik. Pr t krijuar ekipin duhet t
percaktohen kompetencat e mundshme dhe ato t lidhen me rolet perkatese. Nqs pcaktohet
nj rol inxhinier software, puna e t cilit sht t prcaktoj krkesat e prdoruesit, do t duhet
q pr kt rol t prcaktohen dhe kompetencat specifike si psh aftsia pr t ndrvepruar n
mnyr efektive me prdoruesin, aftsia pr t transformuar krkesat funksionale n krkesa
teknike ose aftsia pr t br marrveshje me prdoruesit n mnyr q t prcaktohen
krkesa q mund t realizohen praktikisht.
Nj mnyr pr t identifikuar rolet dhe pergjegjesite sht ndertimi i nj matrice me
detyrat e identifikuara dhe rolin pergjegjes pr to. Kjo matrice sht nj mnyr pr t
identifikuar rolet n tere projektin, fare veprimesh duhet t bejne ata gjate gjithe projektit dhe
pr t kuptuar nese jane jane percaktuar t tera rolet pr t gjitha pergjegjesite e identifikuara.

2
B.Bimbari

Inxhinierimi i software

Krijimi i aplikimit
Testimi i
aplikimit
Shnderrimi i
aplikimit n nj
version q t
shperndahet
Testimi i leshimit
t aplikimit
Instalimi n
stacionet e
punes

Leksion VI, Menaxhimi i projektit


Menaxher
projekti
Aprovon
Aprovon

Zhvillues
aplikimesh
Krijon
Merr pjese

Rishikon

Rishikon
Aprovon

Inxhinier rrjeti
Merr pjese
Merr pjese
Rishikon

Rishikon
Merr pjese

N pcaktimin e kompetencave, duhen pasur parasysh stilet/menyrat e t punuarit q varen nga


temperamentet e njerzve. Ato mund t klasifikohen si:
1. njerezit praktike kjo kategori do q t arrije ti bj gjrat dhe shfrytzojn rastin e
par q u paraqitet. Pergjithsisht keta jan njerezit q inicializojn gjrat, q i vne n
veprim planet. E meta e tyre sht q nuk i kushtojn koh t menduarit dhe
planifikimit. Ata thjesht bjn veprimin q u duket me i prshtatshm pr momentin.
Menaxheri n kt rast duhet t mesoj t zbus dshiren e tyre pr t bre menjehere
dika, por pa e hequr krejtesisht mundesine pr t vepruar. Gjja e par q u duhet
kerkuar sht t bjne nj plan, sepse dhe pergatitja e tij prbn nj veprim.
2. njerez nderveprues keta njerez duan q gjithmone t bisedojne pr gjerat dhe shpesh
biseda perqendrohet rreth ketyre njerezve dhe marredhenieve t tyre me punen.
Njerezit nderveprues preferojne nderveprimin fizik me njerezit. Ata jane me t rralle n
fushen e IT. Ata mund t kthejne me kembe n toke njerezit praktike duke i detyruar
ata t planifikojn. E meta e ksaj kategorie sht q vemendja e bisedave fokusohet
tek keta persona, dhe zhvendoset nga temat e tjera q duhen trajtuar.
3. njerezit me shpirtin e punes n grup punon pr t vlersuar mjedisin e grupit dhe pr
tu siguruar q cdo pjestar i ekipit sht aktiv. Ai do t jet nderveprues, por aktiviteti i tij
sht sigurimi i funksionalitetit t tere ekipit. Ky njeri do t ripercaktoje nevojat e tij n
pershtatje me ato t ekipit. E meta e tyre sht q ata mund t behen shum t
perfshire n punen e grupit dhe t anashkalojne nevojat dhe detyrat e tyre.
4. analistet tipi i njeriut q pelqen t analizoje cdo detaj n mnyr q t organizoje
gjerat. Gjenden shpesh n fushen e IT, sidomos n programim. Jane t pershtatshem
pr analizen e t dhenave, ose pr aktivitete q duan detaje. Shpesh shikohen si ata q
mudn t thone kjo nuk do t funksionoje, sepse ata kane menduar n lidhje me nj
tem dhe kane nxjerr perfundimet e tyre. E meta e tyre sht q ata mund t thone
gjithmone jo pr propozime t ndryshme, ose mund ti mbarojne jo n kohe detyrat e
tyre duke menduar se nuk kane t dhena t mjaftueshme pr t arritur n perfundime
t caktuara.
Kur krijohet ekipi, sht mir, q atehere kur sht e mundur t kt nj ekuilibr ndermjet
pjestareve, mundesisht t kt perfaqesues t t kater kategorive t pershkruara. Kjo do te
ofronte pikepamje dhe menyra t ndryshme zgjidhjeje pr projektin. Menaxhimi do t ishte me i
lehte dhe projekti do t rezultonte me cilesor. Psh tipat analitike do t ndihmonin n

3
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

percaktimin e shum detajeve, ndersa ata nderveprues do t ndihmonin n krijimin dhe


menaxhimin e komunikimit si dhe n punen me prdoruesit.
Pas identifikimit t roleve dhe pergjegjesive duke pasur parasysh tere projektin, duhet t
percaktohen njerez specifike q i marrin persiper keto role dhe pergjegjesi. N ekip mund t
kt nevoje pr konsulence, eksperte shitjeje, eksperte t industrise, eksperte finance ose
ligjore, etj. Duhet t identifikohen nevojat pr aftesi specifike n nj pike t caktuar t projektit.
Me pas duhet t identifikohet nese gjendet brenda grupit t punes, divizionit apo kompanise ky
njeri me aftesite specifike. N rast se ky person sht brenda kompanise, a sht i gatshem ai t
marre pjese n projekt? N rast se nuk sht, a pershihet marrja n pune e tij n vleresimin e
kostos, apo sht e mundur fizikisht q ai t perfshihet n grupin e punes? N rast se pr
projektin nevojitet nj person me aftesi q i kane shum pak njerez n bote, jo vetem q do t
kt veshtiresi pr gjetjen dhe financimin e tij, por n kt mnyr sht identifikuar nj rrezik
serioz i projektit.
Pr t rekrutuar njerez t rinj pr krijimin e ekipit pr projektin, menaxheret zhvillojne
intervista. Qellimi i ketyre intervistave sht q t percaktohet se cfare roli mund t kene
kandidatet n projekt. N mnyr q t zhvillohen pyetjet e duhura gjate intervistes, duhet q
t kihet nj pershkrim i qarte i rolit q do t plotesohet nga kandidatet. Menaxheri duhet t kt
dhe nj bashkesi me kritere zgjedhjeje q jane n perputhje me rolin. Plotesimi i ketyre
kritereve sht tregues i pershtatshmerise se kandidatit pr t plotesuar ate rol. Keto kritere
mund t perfshijne: arsimin, njohuri mbi detyrat, pervoje me keto detyra q do t duhet t
plotesoje ketu, aftesi q kane lidhje me keto detyra, angazhime dhe rezultatet n to, aftesi
drejtuese, aftesi pr t punuar me te tjere, etj. Natyra e pyetjeve q ben nj menaxher n
intervista, sht mir t jet n t meposhtmet:
1. pyetje q mund t pergjigjesh me po ,dhe jo. Psh keni krijuar me par ndonje batch?
2. pyetje ese lejojne kandidatin t jape informacion, dhe lejojne menaxherin t degjoje
dhe vezhgoje. Psh pse jeni i interesuar pr t punuar me kt projekt?
3. pyetje q lidhen me pervojen fokusohen n sjelljen e kandidatit n t kaluaren dhe
lejojne t gjykohet sesi ka vepruar ai n t kaluar dhe t parashikohet n kt mnyr
sesi mund t reagoje ai. Psh. si keni reaguar kur nj anetar i ekipit nuk perfundoi
detyrat e tij n projektin e kaluar dhe ju duhet t benit punen e tij n mnyr q t
mbaronit tuajen? Si u zgjidh situata?
4. pyetje reaguese lindin nga pergjigjet e kandidatit. Kur vihet re nj boshllek ose pasiguri
n pergjigje, behen pyetje q lidhen me to, por pa i quajtur q n fillim genjeshtra. Psh
ju thate q keni njohuri n Visual Basic. A kuptoni edhe VBScript?
5. pyetje q nuk duhet t pyeten duhet t shmangen pyetje q nuk kane t bejne me
aftesite q lidhen me punen. T tilla jane ato q kane t bejne me familjen, gjendjen
civile, fene, etj.

4
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

5.2 Planifikimi i projektit


Menaxhimi i projekteve t software fillon me nj bashksi veprimesh q prbjn planifikimin e
projektit. Prpara se t filloj projekti, menaxheri dhe ekipi i zhvillimit t software duhet t
vlersojn punt q duhen br, burimet e krkuara dhe kohn q duhet nga fillimi n fund. Sa
her q bhen vlersime, parashikohet e ardhmja dhe pranohet nj shkall pasigurie. Frederick
Brooks thot:
teknikat tona pr t br vlersime jan shum t varfra. Pr m tepr, ato pasqyrojn at q
ne nnkuptojm n mnyr t vetvetishme, q do gj do t shkoj mire
Edhe pse planifikimi sht po aq art sa dhe shkenc, ai nuk duhet t bhet n mnyr t
rregullt. Ekzistojn teknika pr vlersimin sasior t kohs dhe prpjekjeve. Ne krijimin dhe
rishikimin e vlersimeve ndihmojn shum dhe prvojat e mparshme t t tr njerzve t
pfshir n projekt.
Planifikimi prfshin vlersim prpjekje pr t prcaktuar sesa para, prpjekje, burime
dhe sa koh do t duhet pr t ndrtuar nj produkt apo sistem t bazuar n software. Kryesisht
ai bhet nga menaxhert e software duke prdorur informacionin e nxjerr nga klientt dhe nga
inxhiniert e software si dhe t dhnat e marra nga projektet e mparshme. Vlersimi fillon me
nj prshkrim t hapsirs s produktit. Nj vlersim me kuptim nuk mund t bhet derisa t
prcaktohen qart kufinjt e ksaj hapsire. M pas, problemi coptohet n nj bashksi
nnproblemesh dhe secili vlersohet duke prdorur prvojn e mparshme. Prpara se t bhet
nj vlersim prfundimtar, konsiderohen edhe kompleksiteti i problemit dhe rreziku. Produkti i
planifikimit sht nj tabel q paraqet detyrat q do t bhen dhe funksionet q do t
implementohen si dhe kostoja, koha dhe puna e nevojshme pr secilin funksion. Krijohet
gjithashtu edhe nj list me burimet e nevojshme pr projektin.

5.2.1 Vzhgim mbi vlersimin


Pergjigja e nj drejtuesi ekzekutiv pr pyetjen se cila karakteristike ishte m e rndsishme n
zgjedhjen e nj menaxheri projekti, ishte ..nje person me aftsit e nevojshme pr t kuptuar se
cfar do t shkoj keq, perpara se vrtet t shkoj keq kjo gj dhe, kurajoja pr t vlersuar nj
t ardhme me re n horizont..
Vlersimi i burimeve, kostos, orareve gjat inxhinierimit kerkon prvoj, akses n
informacione historike dhe kurajo pr t krijuar vlersime sasiore kur ekziston informacion
cilsor. Vlersimi mbart n vetvete rrezik i cili on m pas n pasiguri. Faktor q ndikojn n
pasigurin e vlersimit jan:
1. kompleksiteti i projektit: kompleksiteti ka nj ndikim t madh n pasigurit q jan t
pranishme gjat planifikimit, megjithat rreziku q ai paraqet sht n varsi t
familjariteti ose prvojs s mparshme me natyrn e projektit.
2. madhsia e projektit: mund t ndikoj n efikasitetin dhe saktsin e vlersimeve. Rritja
e prmass s projektit ndikon drejtprdrejt rritjen e varsive t elementve t
projektit. Prmasat rriten shpesh si pasoj e rritjes s hapsirs s projektit, pra si
pasoj e rritjes apo ndryshimeve t krkesave t prdoruesit. Dekompozimi i problemit
bhet m i vshtir sepse elementt rezultat i ktij proesi mund t ken akoma varsi
mes tyre.

5
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

Informacioni historik sht shum i rndsishm, sepse duke e pasur at n dispozicion,


mund t stimulohen situata q kan ecur mir n t kaluarn dhe t prmirsohen fushat n t
cilat jan shfaqur probleme.
Klientt, mbi t gjitha, duhet t dine dhe t jen t ndrgjegjshm q ndryshimet apo prirjet
pr ndryshime n krkesa do t thot paqndrushmri n orare dhe kosto.

5.2.2 Objektivat e planifikimit t projektit


Objektivi i planifikimit te projektit te software eshte te siguroje nje skelet pune qe lejon
menaxherin t bj vlersime t arsyeshme t burimeve, shpenzimeve dhe kohs(orarit). Kto
vlersime bhen brenda nj kohe t kufizuar n fillim te projektit dhe duhet t ndryshohen n
mnyr t rregullt ndrkoh q projekti progreson.
Ndrkoh, vlersimet duhet t arrijn t prcaktojn situata raste m t mira dhe rastet m
t kqia n mnyr q rezultatet e projektit t mund t arrihen suksesshm.

5.2.3 Hapat e Planifikimit


5.2.3.1 Percaktimi i hapsirs/qllimit t software (software scope)
Aktiviteti i par n planifikimin e projektit sht prcaktimi i qllimit t software. Deklarimi dhe
prcaktimi i hapsirs s qllimit duhet t ket konture te prcaktuar qart.
Hapsira e software prcakton t dhnat dhe kontrollet q duhet t proesohen, funksionet,
performancn, ndrfaqet dhe besueshmrin.
Per percaktuar sa me sakte qellimin e projektit eshte e domosdoshme te mblidhet nje
informacion paraprak. Komunikimi mes zhvilluesit dhe klientit nis me takime ose intervista. Pr
t mbledhur informacionin e nevojshm pr prcaktimin e hapsirs s software, mund t
prgatitet nj liste me pyejte (context free questions). Kto pyetje do t ojn n nj kuptim
themelor t problemit, njohje t njerzve q duan nj zgjidhje, natyren e zgjidhjes s krkuar.
Ato duhet t fokusohen tek klienti, qellimet e prgjithshme dhe prfitimet. Pyetjet e para jan:
- Kush sht pas krkess pr kt pun?
- Kush do ta prdor zgjidhjen?
- Cili do t jet prfitimi ekonomik i nj zgjidhjeje t sukseshme?
- A ka nj burim tjetr pr kt zgjidhje?
M pas vijohet me pyetje q aftsojn analistin t prfitoj nj kuptim m t mire te problemit
dhe klientin te qartesojme me mire perceptimet e tij per nje zgjidhje:
- Si do ta karakterizoni ju (klienti) nje rezultat te mire qe do te gjenerohej nga nje
projekt i suksesshem?
- Cfare problemesh do te adresoje zgjidhja?
- Tregoni (pershkruani) mjedisin ne te cilin zgjidhja do te perdoret?
- A ka ceshtje te vecanta te performances ose kufizime qe do te ndikojne menyren ne te
cilen zgjidhja behet?
Grupi i fundit i pyetjeve percaktojn efektivitetin e takimit. Nj list e tyre mund t ishte:
- a jeni ju person ii duhur pr tiu pergjigjur pyetjeve? (a jane ato zyrtare)
- a kane lidhje pyetjet e mia me problemin q ju keni?
- Po bj shum pyetje?

6
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

- A ka ndonj tjeter q mund t jap informacion shtes?


- Ka ndonj gj pr t ciln sjan br pyetje?
Pyetjet ndihmojn n fillimin e komunikimit mes klientit dhe ekipit t projektit, dhe ky
komunikim sht thelbsor n prcaktimin e hapsirs s software. Me kalimin e kohs formati i
takimeve me pyetje dhe prgjigje duhet t zvendsohet me nj format q kombinon elemente
t zgjidhjes s problemit, negociata dhe specifikime.
Ekipi zhvillues dhe klientet krijojne n mnyr t pandrgjegjshme mentalitetin e ne dhe ata.
N kt kontekst secili cakton territorin e tij dhe nuk krijohet nj bashkepunim konstruktiv mes
tyre, por vetm formal. Duke pasur kt parasysh, klientet dhe ekipi i projektit duhet t punojn
me nj frym ekipi pr t prcaktuar krkesa q cojn dhe n prcaktimin e hapsirs s
software.
Kur nj menaxheri i krkohet t planifikoj nj projekt, ai fillon t bj krkime t
ndryshme n mnyr q t krijoj ide mbi projektin dhe sesi mund ta planifikoj at pr t
arritur nj prfundim t suksesshm.
Q projekti t jet i suksesshm, menaxheri dhe njerzit kryesor t interesuar pr produktin,
duhet t ken ide t qart pr at q do t prodhoj projekti. Shpesh, sidomos n teknologjin e
informacionit, klientt nuk e dine me saktsi se cfar do t krijoj projekti. Ata kan vetm nj
ide t prgjithshme t skenarit q duhet t krijohet pr ta. Ekipi duhet ti propozoj zgjidhje pasi
ka kryer intervista, krkime dhe analiz sasiore. Kur menaxheri krijon nj zgjidhje pr klientin, ai
duhet t ket t njjtin vizion me t pr problemin q do t zgjidhet. Pavarsisht se me kalimin e
kohs do t kuptohen m mir gjrat, sht mir t kuptohet q n fillim se cfar do t
prmbajn rezultatet q do t lshohen.
Pr t prcaktuar cfar do t ndrtohet dhe cili sht qellimi i software, prve t tjerash,
menaxheri duhet t bj krkime. Nj metod q mund t ndiqet prfshin kto aktivitete:
1. shkruhet qllimi i krkimit q po kryet: shkrimi i nj deklarate konize t percaktimit t
konceptit t projektit sht ndihme n krkim. Kjo deklarate e shkruar ndihmon n
fokusimin vetm n gjrat e rndsishme, q ojn drejt suksesit. Gjithmon duhet
pasur parasysh ky prcaktim n mnyr q krkimi t filloj t fokusohet n gjra q
jan jasht qllimit t projektit.
2. percaktohet se cfar burime do t prdoren pr kt krkim. Bhet nj list me pistat e
informacionit q do t prdoren. Kjo nuk ka qllim prjashtimin e ndonj burimi t
mundshm informacioni, por renditjen e tyre sipas prioriteteve. Burime t mundshme
jan: prvojat e mparshme, prvojat e t tjerve, burime cilsore n Internet, revista
IT, libra IT q lidhen drejtprdrejt me temn n fjal, broshura t shoqrive shitse.
3. delegimi. Nqs menaxheri ka menduar q n projekt do t ket nj grup njerzish, ai
duhet ti prdor ata pr ta ndihmuar n krkim. Prvoja dhe ekspertiza e tyre do t
jen t nevojshme pr t ndrtuar zgjidhjen me t mir pr projektin. Planifikimi mund
t ndahet n komponente dhe pjes t krkimit mund ti delegohet antarve t tjer t
ekipit.
4. fillimi i puns konkrete. Fillohet me lexime, vlersime dhe shnime. Mbahet nj
evidence e informacionit t gjetur dhe prfundimeve.
5. organizim dhe dokumentim. Mblidhet i gjith informacioni i puns se menaxherit dhe t
ekipit. Ky eshtefillimi i planit t aftsive praktike pr t br projektin. Nj aftsi
menaxhuese sht organizimi i mir i informacionit dhe prdorimi i menjhershm i tij
kur del nevoja.
6. vlersime dhe krkim i mtejshm. Kur sht br nj pjes e krkimit duhet kontrolluar
nse t dhnat e mbledhura i prgjigjen qllimit t krkimit t br. Nqs po ecet
prpara. Prndryshe vazhdohet me krkimin duke ndjekur fazat m lart.

7
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

Kjo sht nj mnyr e thjeshte dhe direkte pr t br krkime t nevojshme q t kuptohet


dhe t mund t planifikohet projekti, megjithate ajo jep rezultate. Koha sht nj faktor i
rndsishm dhe nuk duhet q krkimi t vazhdoj pafundsisht. Pr t duhet t vendoset nj
afat.

5.2.3.2 Vlersimi i aftsive praktike pr realizimin e projektit


Pasi prcaktohet hapsira, sht e arsyeshme t pyetet nse sht praktikisht e mundur t
realizohet ky projekt. Aftsia praktike pr t ndertuar nj software ka katr dimensione:
- teknologjia: sht nj projekt teknikisht i mundshm? sht brenda asaj cka ofron
teknologjia e momentit (brenda state of the art)?
- financa: A sht i mundur financiarisht? A mund t kryet zhvillimin me nj kosto t
perballueshme nga kompania dhe klienti?
- koha: a do t dale n treg n kohe pr t prballuar konkurrencen?
- burimet: a ka kompania burimet e duhura pr t arritur sukses
Pr projektet t cilat jane t ngjashme me ato q jane kryer me par, ketyre pyetjeve menaxheri
mund tu pergjigjet me lehtesi. Ndersa projektet q jan t reja, mund t krkojne periudha disa
mujore pr kerkime dhe pr identifikim t kerkesave dhe t rreziqeve q mund t sjellin ato.

5.2.3.3. Vlersimi i burimeve


Hapi tjeter i planifikimit t projektit sht vlersimi i burimeve t nevojshme pr zhvillimin e
software. N themel t burimeve t krkuara pr zhvillim sht mjedisi zhvillues- mjetet
hardware dhe software q ofrojn infrastrukturn pr zhvillim. Me pas jan komponentet e
software blloqe q mund t ndertojne software dhe q mund t ulin n mnyr dramatike
koston dhe kohn e zhvillimit. Ne maj t piramides se burimeve qendrojn njerzit. Pr secilin
prej ktyre elementeve t burimeve specifikohet pershkrimi i burimeve, nj deklarim i
disponimit t ktyre burimeve dhe periudha gjat t cils do t prdoren kto burime.
Blloqet e software q krijohen me synime riprdorimi, q shpesh quhen komponente,
kategorizohen si me poshte:
1. komponente off the shelf: software ekzistues q mund t perftohen nga nj pale e
trete ose q zhvillohen brenda kompanis. Keto komponente blihen nga pale e trete,
jane gati pr tu prdorur n projektin konkret dhe jan validuar plotesisht.
2. komponente full experience: specifikime, modele, kod, ose t dhna pr teste t
zhvilluara pr projektet e mparshme, por q jane shum t ngjashme me software q
po zhvillohet. Pjestart e ekipit aktual kan punuar n fushn ku jan krijuar kto
komponente dhe modifikimi i tyre nuk prbn rrezik t madh.
3. komponente t reja: komponente q duhet t ndertohen nga ekipi pr projektin
konkret.
Planifikuesi i projektit duhet:
1. t perdore komponentet off the shelf kur identifikohet nevoja pr to dhe kur jan
mundsit pr ti pasur ato. Kostoja pr blerjen dhe integrimin e tyre do t jet me e
vogl sesa kostoja pr zhvillimin e tyre
2. nqs ka komponente t krijuara nga prvoja e mparshme, rreziku pr modifikimin dhe
integrimin e tyre sht i vogl dhe i pranueshm. Plani duhet t reflektoj prdorimin e
ktyre komponenteve.

8
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

3. nqs ka komponente q i pershtaten pjesrisht projektit konkret, prdorimi i tyre duhet


t analizohet. Nqs krkohet modifikim i madh perpara se t bhet integrimi i tyre,
ather rreziku pr prdorimin e tyre sht i madh.

5.3 Orari dhe vijueshmria e projektit


Historia klasike: gjate gjith kohs s planifikuar pr realizimin e projektit, inxhiniert e software
kan realizuar 90 % t puns, por e mbarojn trsisht at vetm 1 muaj pas afatit, me
ndihmn e t tjerve. Pyetja q shtrohet sht pse?.
Koncepte Baze
Disa nga shkaqet kryesore pse software dorzohen von jane:
- nje afat kohor jo realist i vendosur nga dikush jasht grupit zhvillues dhe i forcuar tek
menaxheret e programuesit e ekipit.
- Ndryshimi i krkesave t klientit q nuk reflektohen n ndryshime te orarit.
- Nj nnvlersim i sasis s prpjekjes dhe/ose numrit t burimeve q do t krkohen
pr t br punn
- Rreziqe t parashikuara /paparashikuara q nuk ishin konsideruar kur projekti filloi.
- Vshtirsi teknike q mund t mos jen konsideruar q m pare, n kohn e duhur.
- Vshtirsi njerzore q mund t mos jen konsideruar q m pare, n kohn e duhur.
- Komunikim jo i mir mes stafit te projektit shkakton vonesa.
- Nje deshtim i menaxhuesit t projektit pr t par q projekti sht duke mbetur
mbrapa orarit dhe nj munges veprimi per te korrigjuar problemin.

Komente mbi vonesn


Eshte jo e pershatshme te hysh ne zyren e klientit dhe te kerkosh qe data e dorezimit te
software te shtyhet. Presion i tregut te jashtem ka diktuar daten, dhe produkti duhet leshuar.
Nga ana tjeter eshte nj guxim i teprt nga pikpamja e karriers q nj pun e caktuar t mos
merret prsipr. Cduhet br n kto kushte?
Rekomandohen hapat e meposhtem:
1. Bej nje vleresim te detajuar duke perdorur te dhena historike nga projektet e
meparshme. Vlereso perpjekjet dhe kohzgjatjen e projektit.
2. Duke perdorur nje model procesi inkremetues, zhvillo nje strategji inxhinierimi software
qe do t jap funksionalitete kritike te imponuara nga afati kohor (deadline), por vonon
funksionalitetet e tjera per me vone. Dokumento Planin!
3. Takohu me klientin dhe (duke perdorur vleresime te detajuara), pershkruaj pse afati
kohor i imponuar nuk eshte realist. Jini te sakte ne vleresime.
4. Ofro strategjine e zhvillimit inkremental si nje alternative (mund t bhen propozime
pr t rritur buxhetin pr t marr m shum burime dhe pr t mbaruar me shpejt, pr
t zvogeluar numrin e funksionaliteteve n versionin e par t software, por me von
mund t japim nj version me t tra funksoniet e krkuara).

9
B.Bimbari

Inxhinierimi i software

Leksion VI, Menaxhimi i projektit

Parime baz
Objektivi i nj menaxheri projekti sht t prcaktoj tr detyrat e projektit, t ndrtoj nj
rrjet q paraqet varsite e tyre, t identifikoj punt q jan me rrezik dhe t gjurmoj
progresin duke u siguruar q vonesa diktohet cdo dite. Pr t realizuar kt, menaxheri duhet t
ket nj planifikim kohor t punve (orar), q i lejon njkohsisht t mas progresin.
Planifikimi kohor (percaktimi i orareve) sht nj aktivitet q shprndan prpjekjet e vlersuara
si t nevojshme n periudhn gjat s cils do t zhvillohet projekti. Planifikimi kohor ndryshon
n koh. Fillimisht prcaktohet nj orar makroskopik q identifikon aktivitetet kryesore t
inxhinierimit t software dhe funksioneve t cilave u takojn. M von, cdo element i planit
makroskopik, ripercaktohet n nj orar t detajuar punsh.
Parime t prcaktimit t orarit jan:
Ndarja: Projekti duhet ndare ne nje numer aktivitetesh dhe punesh me lehte te
menaxhueshme.Per te bere kete ndarje, te dy projekti dhe procesi duhen dekompozuar.
Varsit: Duhet percaktuar varesia midis seciles pune apo aktivitet te dekompozuar. Disa pune
duhet te ndodhin ne vazhdimesi njera pas tjetre, kurse disa te tjera mund te ndodhin ne paralel.
Nderkohe, disa aktivitete nuk mund te fillojne derisa produkti i nje aktiviteti tjeter te mbarohet.
Shprndarja e kohs: Cdo pune qe do te vihet ne orar duhet ti percaktohet nje numer njesipune (psh. Pune njerez-dite). Gjithashtu, pr cdo pune duhet percaktuar nje date fillimi dhe nje
date mbarimi, si dhe statusi (part-time / kohe e plote pune).
Prgjegjsit: Cdo pune qe eshte ne orar duhet te percaktohet ne pergjegjesi te nje anetari
specifik te ekipit.
Produkte: Cdo pune/aktivitet duhet te kete nje rezultat/produkt. Per projekte software,
rezultati eshte normalisht nje produkt pune (p.sh design i nje moduli) ose pjese e nje produkti.
Produktet shpesh kombinohen me pune per dorezim (deliverables).
Objektiva: cdo pune ose grup punish duhet t shoqrohet me nj objektiv t projektit
(milestone). Nj objektiv prmbushet kur nj ose me shum produkte pune jan rishikuar pr
cilsi dhe jan aprovuar.

10
B.Bimbari