Inxhinierimi i Software Leksin V, Organizimi i Projektit

1
B.Bimbari
5. Koncepte te Organizimit te Projektit dhe Komunikimit

Inxhinierimi i software eshte nje pune ku bashkepunojne shume pal. Zhvillimi i software bashkon njerez
me profile te ndryshme si eksperte te domainit, analiste, modelues, programues, menaxhere,
dokumentuesit teknike, dizenjues grafike, etj. Asnje nga pjesmarresit ne projektin e zhvillimit te nje
software nuk mund te kuptoje ose kontrolloje i vetem te gjitha aspektet e sistemit qe do te zhvillohet,
prandaj te gjithe varen nga njeri tjetri per te perfunduar punet. Per me teper, te gjithe duhet te kuptojne
cdo ndryshim ne sistem apo ne domainin e aplikimit te sistemit. Ne kushtet e varesive te tilla, eshte shume
e rendesishme qe informacioni te ndahet ndermjet anetareve te projektit ne kohen e duhur dhe me
saktesi.
Komunikimi mund te jete ne trajta te ndyshme, ne varesi te aktivitetit te projektit me te cilin lidhet.
Mund te komunikohet ne mbledhje qe zhvillohen dhe dokumentohen rregullisht. Statusi i projektit mund te
komunikohet edhe gjate rishikimeve me klientet. Komunikimi i kerkesave dhe i modelimit behet nepermjet
modeleve te ndertuara dhe dokumentacionit perkates. Ne raste problemesh kritike apo keqkuptimeve,
komunikimi realizohet nepermjet shkembimit spontan te informacionit dhe mbledhjeve urgjente. Projektet
e zhvillimit te software behen shume te medha, rrjedhimisht koha e shpenzuar per komunikim mes
anetareve te ekipit te projektit rritet shume. Kjo zvogelon kohen qe njerezit mund te shpenzojne ne
aktivitet e tyre teknike, duke e vonuar punen. Per te shmangur keto probleme, njerezit e perfshire ne
projekt organizohen ne ekipe, per te cilat shkembimi i informacionit ne menyre formale apo informale
eshte thelbesor.

5.1 Projektet
Ne projektet e zhvillimit te sistemeve te medha, pergjithesisht eshte e nevojshme te dihet:
- Kush eshte pergjegjes per secilen pjese te sistemit
- Kur jane afatet e perfundimit te seciles pjese te sistemit
- Kush duhet te kontaktohet kur hasen probleme me versione specifike te komponenteve
- Si duhet te dokumentohet nje problem
- Cilat jane kriteret cilesore per vleresimin e sistemit
- Ne cfare forme duhet ti komunikohen zhvilluesve kerkesat per software
- Kush duhet te informohet per kerkesat e reja
- Kush eshte pergjegjes per komunikimin me klientin
Nga kendveshtrimi i nje zhvilluesi, nje projekt perbehet nga kater komponente:
- Produktet e punes. Cdo element i realizuar gjate projektit, si psh pjese kodi, modele, dokument.
Produktet e punes te prodhuara per klientin quhen dorezime(deliverables).
- Orari. Specifikon kur duhet perfunduar secila pune e projektit.
- Pjesmarresit. Cdo person qe perfshihet ne projekt.
- Detyra. Pune qe duhet te realizohen nga nje pjesmarres per te realizuar produktet e punes.
Projektet mund te percaktohen ne trajte formale (nepermjet kontratave) apo informale. Projektet jane te
madhesive dhe tipeve te ndryshme. Tipi i projektit percaktohet nga natyra e dorezimeve. Nqs rezultati
perfundimtar i nje projekti eshte dorezimi i nje sistemi software, atehere projekti eshte nje projekt zhvillimi
software.
Projekti mund te ndodhet ne nje nga gjendjet me poshte, ne nje moment te caktuar:
- Faza e percaktimit te projektit. Ne kete faze perfshihen menaxheri i projektit, nje nga klientet e
mundshem, nje pjesmarres kyc i projektit dhe arkitekti i software. Vemendja perqendrohet tek
Inxhinierimi i Software Leksin V, Organizimi i Projektit
2
B.Bimbari
kuptimi fillestar i arkitetktures se software dhe percaktimi i projektit, vecanerisht i orarit, i punes qe
duhet kryer dhe i burimeve te nevojshme. Kjo faze dokumentohet ne tre dokumente:
o Deklarimi i problemit (problem statement)
o Dokumenti i arkitektures fillestare te software (perqendruar tek nensistemet eventuale)
o Plani fillestar i menaxhimit te projektit te zhvillimit te software
- Faza e fillimit te projektit. Menaxheri i projektit krijon infrastrukturen per projektin, puneson
pjesmarresit e projektit dhe i organizon ne ekipe, percakton objektivat kryesore dhe fillon projektin
nepermjet nje mbledhjeje kick-off.
- Faza e zhvillimit te projektit. Ne dy fazat e para eshte menaxheri i projektit qe merr vendimet
kryesore, ndersa ne kete faze cdo pjesmarres angazhohet per zhvillimin e software. Ata raportojne
tek drejtuesi i ekipit te tyre. Ky i fundit eshte pergjegjes per kontrollin e vazhdueshem te statusit te
zhvillimit dhe per identifikimin e problemeve. Drejtuesit e ekipeve raprotojne statusin e pjeses se
projektit per te cilin jane pergjegjes tek menaxheri i projektit. Drejtuesit e ekipeve reagojne ndaj
devijimeve nga planifikimi fillestar duke bere rishpendarje te detyrave tek anetaret e ekipit ose
duke marre burime shtese nga menaxheri i projektit. Menaxheri i projektit eshte pergjegjes per
komunikimin me klientet, per te marre aprovim formal dhe per te rene dakort per afate dhe burime
te reja.
- Perfundimi i projektit. Rezultati i projektit i dorezohet klientit dhe behet historizimi i projektit.
Perfshirja e pjeses me te madhe te zhvilluesve ne projekt perfundon perpara kesaj faze. Disa
zhvillues ky, dokumentues teknike dhe drejtuesit e ekipeve perfshihen per pergatitjet
perfundimtare te sistemit per instalim dhe pranim nga klienti. Ecuria e projektit historizohet ne
menyre qe te mund ti referohet ne te ardhmen.

Komunikimi eshte i domosdoshem dhe i pranishem gjate gjithe ecurise se projektit dhe ai mund te
realizohet ne menyre te planifikuar ose paplanifikuar. Komunikimi i planifikuar perfshin:
- Inspektime te problemit. Zhvilluesit mbledhin informacion nga deklarimi i problemit, klienti,
perdoruesi.
- Mbledhje per diskutimin e statusit te projektit (status meeting). Ekipet diskutojne progreset
respektive.
- Rishikime ndermjet pjesmarresve. Anetaret e ekipeve identifikojne problem dhe gjejne zgjidhje.
- Rishikime per klientin. Klienti ose pjesmarresit e projektit rishikojne dorezimet per cilesi dhe
saktesi.
- Leshime. Pjesmarresit e projektit u japin perdoruesve dhe klienteve versione te sistemit dhe
dokumentacionin perkates.
Komunikimi i paplanifikuar perfshin:
- Kerkesa per sqarime. Pjesmarresit e projektit kerkojne informacione specifike nga te tjeret per
sistemin, domainin e aplikimit, apo vete projektin
- Kerkesa per ndryshime. Pjesmarresit pershkruajne problemet qe kane hasur ose kerkesa te reja qe
duhet ofrohen nga sistemi
- Zgjidhje te problemeve. Identifikohen konflikte mes grupeve te ndryshem te interesuar per
projektin (stakeholders), gjenden/ analizohen zgjidhje te mundshme dhe bihet dakort per zgjidhjen.
Komunikimi i planifikuar sherben per shperndarjen e informacionit qe pjesmarresit e projektit duhet ta
perdorin per punen e tyre. Komunikimi i paplanifikuar eshte i nevojshem kur ka kriza apo kur nevojitet
informacion papritur.


Inxhinierimi i Software Leksin V, Organizimi i Projektit
3
B.Bimbari
5.2 Koncepte te organizimit te projektit

Organizimet e projekteve
Organizimi i projektit percakton lidhjet ndermjet pjesmarresve te projektit dhe, ndermjet pjesmarresve dhe
puneve, orarit dhe produkteve tepunes. Ne organizimin me ekipe, pjesmarresit ne projekt grupohen ne
ekipe ku nje ekip eshte njesia organizative dhe perbehet nga nje numer i vogel pjesmarresish qe punojne
per te njejten pune apo aktivitet te projektit. Psh ne nje projekt mund te kete kater ekipe: ekipi i
menazhimit, i nderfaqes grafike, i bazes se te dhenave dhe i kontrollit.
Ne nje projekt pjesmarresit nderveprojne me njeri tjetrin. Tre menyrat kryesore te nderveprimit ne
projekt jane:
- Raportimi. Perdoret per te raportuar statusin e projektit. Psh nje zhvillues raporton tek nje
zhvillues tjeter qe nje API eshte perfunduar, ose drejtuesi i ekipit raporton tek menaxheri i projektit
qe nje pune nuk ka perfunduar akoma.
- Vendimi. Sherben per komunikimin e vendimeve. Psh nje drejtues ekipi vendos qe nje zhvillues
duhet te publikoje nje API, nje menaxher projekti vendos qe shperndarja e nje dorezimi duhet te
riplanifikohet
- Komunikimi. Ky lloj nderveprimi perdoret kryesisht per te shkembyer te gjithe informacionin qe
duhet per te marre vendime apo per te g jykuar per statusin e projektit. Psh shkembimi i kerkesave
dhe i modeleve ose krijimi i nje argumenti per te mbeshtetur nje propozim.

Organizimi i projektit eshte hierarkik kur informacionet per statusin dhe vendimarrjen jane
njedrejtimore, dmth vendimet merren gjithmone nga qendra e organizates dhe i kalohen degeve te saj.
Statusi gjenerohet tek deget e organizates dhe raportohet tek qendra. Struktura e rrjedhes se informacionit
per statusin dhe vendimet perben strukturen raportuese te organizates.






Struktura e raportimit ne nje organizim hierarkik. Informacioni per statusin i raportohet menaxherit te projektit dhe vendimet
korrigjuese i komunikohen ekipeve nga drejtuesit e ekipeve. Drejtuesit e ekipeve dhe menaxheret e projekteve perbejne ekipin
e menaxhimit.

Projektet duhet te kene edhe strukturat e tyre te komunikimit ne menyre qe pjesmarresit ne projekt te
mund te komunikojne drejtperdrejt me njeri tjetrin. Pergjithesisht, pergjegjesia per komunikim i delegohet
nje zhvilluesi, i cili eshte pergjegjes per shkembimin e informacionit. Psh ekipi i dokumentimit ka nje anetar
qe komunikon vazhdimisht me ekipin e ndertimit te nderfaqes grafike ne menyre qe te komunikohen
ndryshimet e bera ne pamjen e sistemit. Komunikimi ne keto raste eshte jo hierarkik. Drejtuesi i ekipit
duhet te sigurohet qe menaxheri i projektit njoftohet vazhdimisht per statusin e projektit dhe qe anetaret e
ekipit kane te gjithe informacionin qe u duhet nga ekipet e tjera.



Komunikim i statusit
Komunikim i statusit
Ekipi Kontrollit
Komunikim i vendimit
Komunikim i statusit
Komunikim i vendimit
Komunikim i statusit Komunikim i statusit Komunikim i statusit
Ekipi Kontrollit
Ekipi Menaxhimit
Ekipi Databazes Ekipi Nderfaqes Grafike
Komunikim i vendimit
Komunikim i statusit
Ekipi Kontrollit
Inxhinierimi i Software Leksin V, Organizimi i Projektit
4
B.Bimbari
Rolet
Roli percakton nje bashkesi detyrash teknike dhe menaxheriale qe priten nga nje pjesmarres ose ekip. Ne
projektet me organizim me ekipe, detyrat percaktohen nepermjet roleve. Psh, roli i testuesit te nje
nensistemi ka te beje me percaktimin e rasteve te testimit te nensistemit qe po zhvillohet, ekzekutimi i
testimeve dhe raprotimi i problemeve qe jane identifikuar tek zhvilluesit.
Rolet ne nje projekt zhvillimi software jane:
1. Role menaxherial (menaxheri i projektit, drejtuesi i ekipit). Detyra kryesore eshte organizimi dhe
realizimi i projektit brenda kufizimeve.
2. Role zhvillimi. Detyrat kryesore kane te bejne me specifikimin, modelimin, ndertimin e
nensistemeve. Ky rol perfshin analistin, arkitektin e sistemit, modeluesit e objekteve,
implementuesit, testuesit.


Roli

Pergjegjesite

Arkitekt Sistemesh Arkitekti siguron konsistence ne vendimet e modelimit te sistemit
dhe stileve te nderfaqeve, ne modelimin e menaxhimit te
konfigurimit, testimit, strategjite e integrimit. Ky eshte me teper
nje rol integrues, qe perdor informacion nga te gjitha ekipet qe
marrin pjese ne zhvillimin e sistemit.

Modeluesi i objekteve Modeluesi i objekteve eshte pergjegjes per percaktimin e
nderfaqes se nensistemit me te cilin po merret. Nderfaqja duhet te
reflektoje funksionalitet qe do te ofroje nensistemi dhe varesite qe
ka me nensisteme te tjera.

Implementuesi Implementuesi kodon klasat qe perbejne nje nensistem.

Testuesi Testuesi vlereson qe nensistemet funksionojne sic jane specifikuar
nga modeluesi i objekteve. Ne pergjithesi, projektet e zhvillimit te
software kane nje ekip te vecante qe eshte pergjegjes vetem per
testimin. Ndarja e rolit te testimit nga ai i zhvillimit siguron testim
me eficent.


3. Role nder-funksionale. Keto role lidhen me koordinimin mes ekipeve. Zhvilluesit qe luajne keto role
jane pergjegjes per shkembimin e informacionit te duhur me ekipe te tjera dhe negocimin e
detajeve te nderfaqeve. Zhvilluesi qe realizon keto role mund te jete:
a. Inxhinier API. Percakton nderfaqen e sistemit per te cilin eshte pergjegjes. Ndefaqja duhet
te reflektoje funksionalitetet qe mbulon nensistemi dhe varesite me nensistemet e tjera.
b. Editues dokumentacioni. Pergjegjes per te integruar dokumentacionin e prodhuar nga
ekipi. Mund te shikohet si ofrues sherbimesh per ekipe te tjera qe varen nga nensistemi ne
fjale. Menaxhon edhe informacionin qe duhet te shperndahet brenda ekipit, si axhendat e
mbledhjeve apo dokumentimin e zhvillimit te tyre.
c. Menaxheri i konfigurimit. Menaxhon versionet e ndryshme te dokumentave, modeleve,
kodit te realizuar nga ekipi. Ky rol mund te kryhet nga drejtuesi i ekipit per politika te
thjeshta te menaxhimit te konfigurimit si platforma e hardware, etj.
Inxhinierimi i Software Leksin V, Organizimi i Projektit
5
B.Bimbari
d. Testuesi. Duhet te sigurohet qe cdo nensistem funksionin sipas specifikimeve te
modeluesit.
4. Role konsulence. Keto role ofrojne ekspertize te perkohshme ne ato pjese te projektit ku
pjesmarresit e tij nuk kane njohurite e duhura. Klientet dhe perdoruesit shpesh jane konsulente per
domainin e aplikimit. Konsulekte teknike ofrojne ekspertizen e tyre per teknologji te reja.
Konsulente jo teknike ndihmojne ne trajtimini e eshtjeve legale apo te marketingut. Tipet e
konsulenteve jane:
a. Klienti, eshte pergjegjes per formulimin e skenareve, dhe te kerkesave (funksionale dhe
jofunksionale) dhe kufizimeve te mundshme. Klienti mund te komunikoje me zhvilluesit.
b. Perdoruesi fundor eshte personi te cilit do ti jepet sistemi i perfunduar per perdorim. Kur
perdoruesi nuk njihet dhe nuk mund te kontaktohet, atehere ai perfaqesohet nga klienti
apo nga zhvilluesit e sistemit.
c. Specialistet e domainit te aplikimit japin njohuri ne lidhje me pjese te caktuara funksionale
te domainit te aplikimit. Klienti mund te kete nje ide te pergjithshme te funksionaliteteve te
kerkuara nga sistemi, por specialisti i domainit ka njohuri te detajuara ne lidhje me nje
problem specifik.
d. Specialistet e domainit te zgjidhjes jep njohuri ne ldhje me zgjidhjet qe mund te perdoren
per implementimin e sistemit. Keto mund te perfshiijne metodologji zhvillimi, procesin,
metodologji implementimi, mjedisin e zhvillimit, etj.

Detyrat dhe Produktet e Punes
Detyra eshte nje pune e mirepercaktuar qe i caktohet nje roli. Grupe detyrash qe kane lidhje me njera
tjetren quhen aktivitete. Detyrat i caktohen nje roli nga menaxheri i projektit ose drejtuesi i ekipit.
Pjesmarresi i projektit qe luan rolin duhet te kryeje keto detyra, nderkohe qe menaxheri apo drejtuesi
monitoron progresin dhe perfundimin e tyre. Produkti i punes eshte rezultati i prekshem i nje detyre. Ai
mund te jete modelin e nje objekti, diagrama e nje klase, kod, dokument, ose pjese dokumentacioni.
Produketet e punes duhet te dorezohen brenda afateve te paracaktuara dhe mund te sherbejne si inpute
per detyra te tjera te projektit.
Produktet e punes qe duhet ti dorezohen klientit quhen dorezime. Shembuj jane sistemi software qe
ndertohet dhe dokumentacioni perkates. Produktet e punes qe nuk jane te dukshme per klientet quhen
produkte pune te brendshme. Specifikimi i punes qe duhet bere per te perfunduar nje detyre apo aktivitet
pershkruhet ne paketat e punes. Paketa e punes perfshin emrin e detyres, rolet qe duhet ta kryejne
detyren, pershkrimin e detyres, varesite nga inputet dhe outputet e pritshme. Paketa e punes per
ndertimin e nensistemit te databazes:
Detyra Roli Pershkrim i detyres Input Output
Nxjerrrja e
kerkesave per
nensistemin e
databases
Arkitekti i sistemit Nxirren kerkesat nga
ekipet e nensistemeve ne
lidhje me nevojat per te
ruajtur informacion.
Zhvilluesit
e caktuar
per
komunikim
ne ekip
API per nensistemin e
databazes, modeli i
analizes se objekteve
Modelimi i
nensistemit te
databazes
Modeluesi i
objekteve
Modelon nensistemin e
databazes, merret
vendimi per DBMS qe do
te perdoret
API i
nensistemit
Modeli i nensistemit te
databazes (diagrame
UML)
Implementimi i
databazes
Impelmentuesi Implementon
nensistemin e databazes
Modeli i
nensistemit
Kod
Inspektimi i Implementuesi, Realizimi i inspektimeve Kodi i Liste defektesh
Inxhinierimi i Software Leksin V, Organizimi i Projektit
6
B.Bimbari
nensistemit te
databazes
testuesi,
modeluesi i
objekteve
te nensistemit te
databazes
nensistemit
Plani i testimit te
nensitemit
databazes
Testuesi Zhvillon nje bashkesi me
raste testimesh per
nensistemin e databazes
API/ kod i
nensistemit
Testime dhe plan
testimi
Testimi i
nensistemit te
databazes
Testuesi Ekzekuton testet per
nensistemin
Nensistemi,
plani i
testimit
Rezultatet e testimit,
liste defektesh

Produktet e punes jane te rendesishme per menaxhimin e projektit. Nepermjet tyre mund te matet
progresi apo te evidentohen probleme. Vonesa e krijimit te rasteve te testimit do te vononte fillimin e
testimit.


Orari (Schedule)
Orari eshte vendosja e detyrave ne kohe: do detyre ka nje moment fillimi dhe perfundimi. Kjo lejon
planfikimin e afateve per dorezimet. Oraret paraqiten shpesh nepermjet diagramave Gantt. Diagrama
Gantt eshte menyre kompakte e e paraqitjes se orarit te nje projekti zhvillimi software. Ajo perbehet nga
grafike me shtylla. Boshti horizontal paraqet kohen ndersa ai vertikal detyrat qe duhet te realizohen.
Detyrat paraqiten si shtylla, gjatesia e se cilave i korespondon kohezgjatjes se tyre.


Diagrame Gantt
Prcaktimi i orarit udhhiqet nga informacion i percaktuar ne fazat e para t planifikimit dhe konkretisht
gjate:
- vleresimit te punes
- dekompozimit te funksionit te produktit
- perzgjedhjes se modelit te procesit te duhur
- percaktimit te bashkesise se puneve(rrjeti i puneve)
- dekompozimit te puneve
Varesite midis puneve mund te percaktohen duke perdorur nje rrjet punesh. Punet mund t percaktohen
per produktin si nje i tere ose per funksione individuale.Orari ndihmon q n cdo moment t vlersohet
progresi n projekt, t identifikohen vonesat dhe t merren masa pr ti rikuperuar ato.

Inxhinierimi i Software Leksin V, Organizimi i Projektit
7
B.Bimbari
5.3 Koncepte te Komunikimit ne Projekt

Komunikimi i planifikuar
Komunikimi i planifikuar realizohet nepermjet ngjarjeve te percaktuara ne kohe ku pjesmarresit
shkembejne informacion per tema te caktuara apo rishikojne produkte te punes. Keto ngjarje organizohen
ne menyre te tille qe te maksimizohet informacioni qe shkembehet dhe te minimizohet koha qe
shpenzohet per komunikim. Ngjarje tipike te komunikimit te planifikuar jane:
o Prezantimi i problemit. Prezantohet deklarata e problemit qe pershkruan problemin, domainin e
aplikimit dhe funksionalitetet e pritura nga sistemi, kerkesat jo funksionale si psh specifikime per
platformen, pritshmeri per performancen, etj. Deklarata e problemit nuk perben specifikim te plote
te sistemit. Sherben kryesisht per te vendosur nje gjuhe te perbashket fillestare mes ekipit te
projektit dhe klientit.
o Rishikime te klienteve. Qellimi eshte qe klienti te vleresoje progresin e zhvillimit dhe qe te
konfirmoje apo ndryshoje kerkesat. Sherben per te rritur kuptimin e perbashket te problemit dhe
per te kontrolluar pritshmerite e te dy paleve. Fokusi eshte tek ajo cka ben sistemi dhe tek
kufizimet e mundshme qe mund te kete klienti (performanca, platforma). Rishikimi i klientit
perqendrohet rralle here tek implementimi apo modelimi i sistemit. Pergjithesisht rishikimi i klientit
realizohet ne formen e prezantimeve formale gjate te cilave zhvilluesit perqendrohen tek
funksionalitete te caktuara. Paraprakisht duhet te jene dhene dokumente te specifikimeve,
prototipe te nderfaqes grafike, ose prototip vleresimi. Rezultati i rishikimeve eshte aprovimi i
klientit per sa u trajtuan, ose kerkesa/aprovime per ndryshime ne funksionalitete ose orare.
o Rishikime te projektit. Qellimi eshte qe menaxheret e projektit te vleresojne statusin dhe ekipet te
rishikojne nderfaqet ndermjet nensistemeve. Rishikimet nxisin shkembimin e njohurive ndermjet
ekipeve, si problemet qe jane hasur me shpesh, etj.Qellimi i rishikimeve varet nga subjekti i
rishikimit. Ne rastin e modelimit te sistemit rishikohen dekompozimi dhe nderfaqet e nensistemeve
kryesore. Ne rastin e modelimit te objekteve rishikohen nderfaqet e objekteve. Per integrimin dhe
testimin rishikohen testimet dhe rezultatet e tyre. Rishikimet e projektit realizohen si prezantime
formale gjate te cilave cdo ekip prezanton nensistemin e tij tek menaxhimi ose tek ekipet e tjera.
o Rishikime ndermjet anetareve te ekipeve. Fokusi i ketyre rishikimeve eshte kodi i programit, me
qellim permiresimin e tij. Nje zhvillues paraqet kodin e tij tek pjesa tjeter e ekipit ne menyre qe ata
te mund te gjejne zona te mundshme problematike. Baza e komunikimit eshte kodi qe inspektohet.
o Rishikime te statusit. Vemendja perqendrohet tek detyrat. Objektivi eshte gjetja e devijimeve nga
planifikimi i detyres dhe reagimi ndaj tyre. Rishikimet e statusit i nxisin zhvilluesit qe te perfundojne
detyra ende te paperfunduara. Nxiten diskutimet lidhur me ceshtjet e hapura dhe problemet e
hasura. Zgjidhjet komunikohen dhe ka ndarje njohurish mes pjesmarresve te projektit. Rishikimet e
statusit realizohen nepermjet mbledhjeve te cilat duhet te kene nje axhende te parapercaktuar. Kjo
i nxit pjesmarresit qe te pergatiten per mbledhje dhe te rishikojne edhe axhenden nese lindin
probleme urgjente. Zhvillmet e mbledhjeve duhet te dokumentohen (meeting minutes) nga nje
pjesmarres i dedikuar, sidomos statuset dhe vendimet e marra. Dokumenti sherben sin je menyre e
mire per komunikim me anetare te tjere te projektit qe nuk kane marre pjese ne mbledhje.
o Brainstorming. Qellimi eshte gjenerimi i shume zgjidhjeve per problemin, pavaresisht cilesise se
tyre. Me pas zgjidhjet vleresohen. Realizohet neper mbledhje, por edhe me e-mail. Ne themel te e
brainstorming qendron fakti qe idete, pavaresisht vlefshmerise se tyre, mund te sherbejne per te
nxitur ide te tjera tek pjesmarres te tjere. Ne kete menyre shkohet gjithmone me prane zgjidhjes se
problemit.
Inxhinierimi i Software Leksin V, Organizimi i Projektit
8
B.Bimbari
o Leshime. Qellimi eshte produktet e punes tu jepen anetareve te projekteve, duke zevendesuar
leshime te meparshme. Leshimi mund te jete nje njoftim i shkurter, versioni i ri I nje produkti, liste
me ndryshime qe nga leshimi i fundit, liste me probleme te zgjidhura apo qe mbeten per tu
zgjidhur, etj. Pergjithesisht, leshimet perdoren per te ofruar sasi te madhe informacioni ne menyre
te kontrolluar. Rishikimet e klientit dhe te projektit paraprihen pergjithesisht nga leshimi i nje ose
me shume dorezimesh.

Komunikimi i paplanifikuar
Nje projekt duhet te pergatitet per situata te papritura, shpesh ne kushte tensioni. Komunikimi i nevojshem
ne keto raste quhet komunikim i paplanifikuar. Ai mund te jete ne trajten e:
o kerkese per sqarime. Komunikim ndermjet zhvilluesve, klienteve dhe perdoruesve. Nje pjesmarres
mund te kerkoje sqarime per cdo aspekt te sistemit qe nuk duket i percaktuar qarte. Keto kerkesa
mund te jene gjate takimeve joformale, telefonatave, etj. Situatat kur pjesa me e madhe e
informacionit shkembehet nepermjet kerkesave per sqarime jane tregues te nje komunikimi jo
efektiv. Psh teksti i mesazhit me poshte:
Kur duhet te jete gati Dokumenti I Modelimit te Sistemit? Afati I sakte nuk eshte i qarte, sipas orarit
duhet te jete ne 22 Tetor, ndersa ne template thuhet 7 Nentor.
o kerkese per ndryshime. Nje pjesmarres I projektit raporton nje problem dhe ne disa raste,
propozon nje zgjidhje. Problemi mund te kete te beje me sistemin, dokumentacionin, procesin e
zhvillimit, organizimin e projektit. Kur permasa e sistemit dhe numri i pjesmarresve ne projekt
eshte i madh kerkesat per ndryshime formalizohen. Kerkesat permbajne klasifikim (problem i
rende, shtimi i nje vecorie te re, etj), pershkrim te problemit, pershkim te konteksit, materiale
suportuese. Psh forma e kerkeses per ndryshim me poshte:





o zgjidhje problemesh. Kur raportohen problem dhe zgjidhje te mundshme, duhet te zgjidhet njera
nga zgjidhjet, te komunikohet tek te gjithe dhe te implementohet. Zgjidhja mund te zgjidhet ne
grup ose si vendim i nje anetari te vetem. Ne cdo rast, ajo duhet te komunikohet dhe
dokumentohet. Dokumentimi sherben si reference, te ciles ekipet mund ti rikthehen.

Ne pergjithesi perdoren programe per gjurmimin e problemeve dhe zgjidhjeve. Keshtu sigurohet
komunikim ndermjet te gjitha paleve.
Identifikuesi i ndryshimit Numri i kerkeses: 1291
Data: 12/04/2011
Autori: Pol
Permbledhje: Programi ndalon ekzekutimin
kur dergohet nje forme bosh.

Informacioni i konteksit te problemit Nensistemet: Nderfaqa perdoruesit
Versioni: 3.4.1
Klasifikimi: funksionalitete jokorrekte/ te
paplota, bug, problem dokumentimi.
Shkalla e rendesise: e madhe, mesatare, e
ulet

Pershkrim i problemit dhe arsyet per
ndryshim
Pershkrim:
Arsye:

Pershkrim i ndryshimit te kerkuar Zgjidhja e propozuar