You are on page 1of 6

Inxhinierimi i software

Leksion IV

Zhvillimi i shpejte (Agile Development)

Zhvillimi i shpejte i software kombinon nje filozofi te caktuar me nje bashkesi udhezimesh per menyren
e zhvillimit. Filozofia e kesaj menyre zhvillimi inkurajon kenaqjen e klientit dhe dorezimin inkremental
dhe te hershem te software, ekipe te vogla pune dhe shume te motivuara, metoda informale, produkte
minimale te inxhinierimit te software dhe thjeshtesi te pergjithshme te zhvillimit te software. Udhezimet
e zhvillimit theksojne me teper dorezimin e nje inkrementi software sesa analizen dhe modelimin (edhe
pse rendesia e ketyre aktiviteteve nuk mohohet). Rendesi e madhe i jepet edhe komunikimit te ngushte
mes zhvilluesve dhe klienteve.
Gjate zhvillimit te shpejte, inxhinieret e software dhe te tjere te interesuar per projektin (stakeholders)
menaxhere, kliente, perdorues fundore- punojne sebashku ne nje ekip dinamik, qe ndryshon shpesh dhe
shpejt (agile team). Ky lloj ekipi eshte i veteorganizueshem dhe kontrollues i fatit te vet. Nje ekip
dinamik inkurajon komunikim dhe bashkepunim ndermjet pjesmarresve dhe atyre qe punojne me te.
Zhvillim i shpejte perfaqeson nje alternative te arsyeshme ndaj inxhinierimit tradicional dhe
konvencional te software per nje bashkesi te caktuar klasash software dhe per tipe te caktuara te
projekteve te zhvillimit te software. Kjo menyre zhvillimi eshte ne sintoni me mjedisin biznes qe nxit
nevojen per software, ky mjedis eshte ne zgjerim dhe ndryshim te shpejte dhe te vazhdueshem.
Zhvillimi i shpejte ndjek aktivitetet baze: komunikimi, planifikimi, modelimi, ndertimi, dhe leshimi i
software, por ato formojne nje bashkesi minimale detyrash qe e shtyjne ekipin e projektit drejt
ndertimit dhe shperndarjes se software.
Klientet dhe ekipi zhvillues kane te njejten pikepamje i vetmi produkt qe ka vertet rendesi eshte nje
inkrement qe funksionon i software, qe i dorezohet klientit ne nje date te caktuar per te cilen kane rene
dakort.
Nqs ekipi i punes bie dakort qe procesi i punes funksionon sic duhet dhe eshte prodhuar nje inkrement
funksional qe kenaq klientin, atehere puna (duke ndjekur kete menyre zhvillimi) eshte bere sic duhet.

Reagimi i shpejte
Idete qe qendrojne ne themel te zhvillimit te shpejte kane qene te pranishme prej kohesh, por ne dy
dekadat e fundit ato jane kristalizuar ne nje levizje. Ne thelb, metodat e zhvillimit te shpejte u zhvilluan
per te reaguar ndaj dobesive te pranishme apo perceptuara te inxhinierise tradicionale dhe
konvencionale te software. Zhvillimi i shpejte mund te sjelle mjaft perparesi, por nuk eshte i
aplikueshem ne cdo projekt, tek cdo produkt, tek te gjithe njerezit dhe ne cdo situate. Ai nuk i
kundervihet praktikave solide te inxhinierise se software.
1

Inxhinierimi i software

Leksion IV

Ne ekonomine moderne, shpesh eshte e pamundur te parashikohet sesi nje sistem kompjuterik (psh nje
aplikim Web) do te evoloje me kalimin e kohes. Kushtet e tregut ndryshojne shume shpejt, nevojat e
perdoruesit evolojne. Shpesh eshte e pamundur qe kerkesat te percaktohen plotesisht derisa projekti te
kete filluar. Duhet qe menyra e punes te jete e pershtatshme dhe e ndryshueshme shpejt ne menyre qe
ti pergjigjet nje mjedisi biznesi shume te ndryshueshem.
Ndyshimi eshte i shtrenjte, sidomos nese ai nuk kontrollohet dhe menaxhohet si duhet. Metodat e
zhvillimit te shpejte jane vecanerisht joshese sepse kane aftesi te ulin ndjeshem koston e ndryshimit ne
procesin e zhvillimit te software.
Reagimi i shpejte eshte fjala kyce ne procesin e zhvillimit te software ne kohet e sotme sepse ndryshimi
eshte pjese organike e tij. Ndryshon software qe po ndertohet, ndryshon perberja e ekipit zhvillues,
ndryshon teknologjia, etj. Ekipi i zhvillimit te nje softi duhet te kete aftesite ta kuptojne shpejt
ndryshimin dhe ta pershtasin ate ne projekt. Per kete eshte thelbesore qe pjestaret e ekipit zhvillues te
kene aftesi bashkepunimi.
Reagimi i shpejte eshte me teper sesa reagim efektiv ndaj ndryshimit. Ai nxit struktura ekipi dhe menyra
pune te tilla qe zgjerojne komunikimin mes pjestareve te ekipit, mes teknikeve dhe njerezve te biznesit,
ndermjet inxhiniereve te software dhe menaxhereve te tyre. Ai thekson dorezim te shpejte te software
operacional dhe nuk thekson rendesine e produkteve te ndermjetme te punes (gje qe jo gjithmone
eshte pozitive). Klienti eshte pjese e ekipit zhvillues dhe metodat e zhvillimit te shpejte synojne qe te
sheshojne diferencen ne dhe ju qe eshte shpesh e pranishme ne shume projekte zhvillimi software. Ne
zhvillimin e shpejte pranohet qe planifikimi ne nje bote te pasigurt ka kufizimet e tij dhe qe plani i nje
projekti duhet te jete fleksibel.
Reagimi i shpejte mund te perdoret ne cdo proces zhvillimi software me kusht qe ekipi te jete i
pergatitur qe te pershtase detyrat dhe punet, te planifikoje projektin ne menyre te tille qe te marre
parasysh natyren fluide e te ndryshueshme te zhvillimit te shpejte, te eliminoje pothuajse te gjitha
produktet e punes pervec atyre qe jane thelbesore, nxit strategji inkrementale te dorezimit qe i jep
klientit software funksional ne intervalin me te shkurter kohor qe eshte objektiv per tipin e software.

Reagimi i shpejte dhe kostoja e ndryshimit


Kostoja e akomodimit te ndryshimit ne projekt rritet ne menyre jolineare me kalimin e kohes ne te cilen
projekti ben progres. Eshte relativisht e thjeshte qe ndryshimi te pershtatet ne fazat e para te mbledhjes
se kerkesave. Ndryshimi mund te jete editimi i nje skenari ose i nje specifikimi te shkruar. Kostoja dhe
koha per te bere keto ndryshime eshte e vogel. Nqs ekipi eshte ne mes te testimit per validim te
realizimit te kerkesave dhe klientet kerkojne nje ndryshim te madh funksional te software atehere
ndryshimet qe duhet te behen ne software jane te medha. Duhet te rishikohet modeli arkitekturor,
modeli dhe ndertimi i komponenteve ekzistuese dhe ndertimi i komponenteve te reja, duhet te behen
testime te reja, etj. Koha dhe kostoja per te realizuar ndryshimin dhe per tu siguruar qe ai nuk ka
shkaktuar probleme te reja tek software eshte e konsiderueshme.

Inxhinierimi i software

Leksion IV

Zhvillimi i shpejte synon qe ta ule koston e ndryshimit qe shfaqet ne faza te vonshme te procesit. Kjo
realizohet pergjithesisht nepermjet dorezimit inkremental dhe praktikave te tjera si testim njesi i
vazhdueshem dhe programim ne cift. Shkalla e zvogelimit te kostos se ndryshimit eshte e debatueshme,
por pervoja tregon qe nepermjet reagimit te shpejte mund te arrihet zvogelim i dukshem i kostos.

Procesi i shpejte (Agile Process)


Proceset e shpejta pershkruhen nga karakteristikat e meposhtme:
1. Eshte e veshtire te parashikohen qe ne fillim kerkesat qe do te qendrojne te pandryshueshme
dhe ato qe do te ndryshojne. Eshte gjithashtu po aq e veshtire qe te parashikohet nese
prioritetet e klientit ne lidhje me funksionalitet e software do te ndryshojne apo jo.
2. Per shume tipe software, modelimi dhe ndertimi i tyre jane te lidhura ngushte. Ato duhet te
kryhen njera pas tjetres ne menyre qe modelet te provohen kur ato krijohen. Eshte e veshtire te
parashikohet niveli I modelimit perpara sesa te behet ndertimi qe bazohet mbi ate mdoel.
3. Analiza, modelimi, ndertimi dhe testimi nuk jane te parashikueshme (nga pikepamja e
planifikimit).
Nisur nga sa me lart, lind natyrshem pyetja: si mund te krijohen procese qe menaxhojne te
paparashikueshmen? Kjo mund te realizohet vetem nepermjet aftesise se proceseve per tu pershtatur
me kushtet (proceseve dhe kushteve teknike qe ndryshojne shpejt). Pra, nje proces i shpejte duhet te
kete aftesi pershtatese. Per me teper ai duhet te pershtatet ne menyre inkrementale, sepse pershtatje e
vazhdueshme pa nje progres nuk eshte ajo qe deshirohet. Per te realizuar kete, ekipi qe ndermerr
procesin e shpejte duhet te marre feedback te vazhdueshem nga klienti. Feedback mund te merret
nepermjet nje prototipi operacional ose nepermjet nje inkrementi te sistemit operaciaonal. Inkrementet
e software duhet te dorezohen shpesh, ne intervale jo shume te gjate, ne menyre qe te mund te kete
pershtatje ne kohe nese ka ndryshime. Kjo menyre iterative ben qe klienti ti vleresoje rregullisht
inkrementet e software, te jape feedback te nevojshem tek ekipi dhe te ndikoje tek pershtatjet ne
proces.
Parimet e reagimit te shpejte
Themeluesit e zhvillimit te shpejte (ose me mire te formalizimit te tij si nje proces zhvillimi software
nepermjet Agile Manifesto http://agilemanifesto.org/ ) kane percaktuar parimet e meposhtme:
1. Prioriteti me i larte eshte kenaqesia e klientit nepermjet dorezimit te software funksional heret
dhe ne menyre te vazhdueshme.
2. Ndryshimi i kerkesave eshte i mirepritur, qofte edhe vone ne procesin e zhvillimit.
3. Dorezohet shpesh software funksional. Kjo mund te behet brenda disa javeve apo disa muajve,
por perparesi kane intervalet e shkurtra.
4. Zhvilluesit dhe perfaqesuesit e biznesit duhet te punojne bashke cdo dite.

Inxhinierimi i software

Leksion IV

5. Projektet ndertohen me njerez te motivuar. Ata duhen mbeshtetur, u duhet ofruar mjedisi I
duhur dhe u duhet dhene besim ne punen qe bejne.
6. Menyra me efikase dhe me e shpejte per komunikimin e informacionit (brenda ekipit apo ndaj
ekipit) eshte komunikimi i drejperdrejte mes njerezve.
7. Progresi matet kryesisht me software qe funksionon.
8. I kushtohet rendesi ne menyre te vazhdueshme ekselences teknike dhe zhvillimit te aftesive te
mira teknike, per te arritur modele te mira ne menyre qe te mbeshtetet ndryshimi i shpejte.
9. Thjeshtesia ne punen e bere eshte thelbesore.
10. Arkitetkurat me te mira, kerkesat me te mira dhe modelet me te mira lindin nga ekipe qe vete
orgranizohen.
11. Ne intervale te rregullta kohore, ekipi reflekton sesi mund te jete me efektiv, me pas pershtat
sjelljen ne perputhje me perfundimet e reflektimit.
Proceset e zhvillimit te shpejte nuk i theksojne te gjithe njesoj te gjitha parimet e mesiperme.
Te gjitha jane pro reagimit te shpejte, por sfida e vertete eshte sesi ai do te arrihet. Si mund te
ndertohet software qe perputhet me nevojat e klienteve sot dhe qe ka karakterisitka cilesore qe do e
bejne te pershtatet lehte me ndryshimet apo zgjerimet e mundshme ne te ardhmen?
Nuk ka nje pergjigje absolute per sa me lart dhe menyra sesi realizohet reagimi i shpejte percakton dhe
modelin e procesit te shpejte. Megjithate, modelet e proceseve te shpejte nisen nga nje bashkesi idesh
qe e kane origjinen tek inxhinieria tradicionale e software. Por, perkrahesit e metodave te reagimit te
shpejte i japin rendesi te madhe faktorit human ne procesin e zhvillimit te software. Kjo menyre
zhvillimi perqendrohet dhe varet teresisht nga talenti dhe aftesite e anetareve te ekipeve zhvilluese dhe
procesi merr forme pikerisht ne varesi te tyre. Mqs njerezit jane kaq te rendesishem ne keto tipe
procesesh, atehere ata duhet te kene tiparet e meposhtme:
1. Kompetence. Pjestaret e ekipit duhet te jene te talentuar, me aftesi specifike per zhvillimin e
software, njohuri te pergjitshme per procesin qe ka zgjedhur ekipi. Aftesite dhe njohurite mbi
procesin mund dhe duhet tu mesohen njerezve qe do te jene pjese e ekipeve.
2. Fokus i perbashket. Pjestaret e ekipit kane detyra te ndryshme, kane profile dhe aftesi te
ndryshme, por ama kane nje qellim te perbashket tek i cili duhet te fokusohen te dorezojne
tek klienti software funksional brenda afatit te percakuar kohor. Per te arritur kete, ekipi duhet
te perqendrohet tek pershtatjet e vazhdueshme (te medha ose te vogla) qe e bejne procesin ti
pergjigjet nevojave.
3. Bashkepunimi. Ekipet duhet te kene bashkepunim te ngushte me njeri tjerin si dhe me klientet.
Kjo ndihmon ne vleresimet, analizat, mbledhjen e informacionit, etj.
4. Aftesi vendimarrjeje. Cdi ekip zhvillimi software duhet te lejohet te kete lirine te vendose fatin e
vet. Kjo do te thote qe ekipit ti jepet autonomi per te marre vendime teknike dhe per probleme
te tjera te projektit.
5. Aftesi per te zgjidhur probleme te papercaktuara qarte. Ekipet shpesh perballen me probleme te
papercaktuara qarte, qe ndryshojne, etj. Keshtu qe ekipet duhet te kene aftesi te pershtaten me
to dhe te japin zgjidhje.

Inxhinierimi i software

Leksion IV

6. Besim i ndersjellte dhe respekt. Anetaret e ekipeve te zhvillimit te shpejte duhet te kene besim e
vleresim mes tyre ne menyre qe te formojne nje ekip te tere, te plote qe funksionon ne
harmoni.
7. Veteorganizimi. Ne kontekstin e zhvillimit te shpejte, vete organizimi do te thote:
Shembull i menyres agile te zhvillimit eshte programimi ekstrem

Programimi ekstrem (Extreme Programming XP)


Model i perdorur nga ekipe te vogla zhvilluesish qe duhet te zhvillojne shpejt software qe do te
perdoren ne mjedise te ndryshueshme. Qellimi i XP eshte qe modelimi i software te jete sa me shume te
jete e mundur e pershkruar ne kodin burim te programit. Kjo zvogelon nevojen per dokumentim dhe
rrezikun per mosperputhje ndermjet dokumentave te ndryshem. Sistemi modelohet ne menyre
inkrementuese. Implementohen vetem ato karakteristika te software qe kane te bejne me kerkesat qe
po konsiderohen. Zhvilluesit nuk ndertojne nje arkitekture te pergjithshme dhe te zgjerueshme, qe te
mund te zgjerohet me vone. Ne nje moment te caktuar trajtohet vetem nje kerkese: kodi ekzistues
rishikohet per te permiresuar modelin e sistemit ne kushtet e kerkeses se re qe duhet te
implementohet. Kodi i permiresuar testohet per kerkesen qe do te implementohet shkruhen teste. Ne
fund implementohet kerkesa (funksionaliteti perkates qe realizon kete kerkese ne sistem). Pra, modeli i
sistemit permiresohet per te akomoduar zgjerimin vetem kur shfaqet nevoja per zgjerime/ ndryshime.
Kodi nuk eshte ne pronesi te vetem nje programuesi kur perdoret XP, por i gjithe ekipi ka njohuri per
te. Cdo rresht kodi duhet te shkruhet nga nje cift programuesish. Pasi shkruhet kodi, cifti shperbehet.
Me pas, cdo programues mund te ndryshoje kodin.
Ai dallohet nga metodologjit e tjera nga:
1. feedback i shpejte, konkret, i vazhdueshem nprmjet cikleve t shkurtr. Perballja me
problemet eshte e hershme, keshtu qe ka me shume kohe per zgjidhjen e tyre. Kjo ka te beje me
feedback-un e klientit dhe ate qe vjen nga testimi.
2. Thjeshtesia. Modeli duhet te perqendrohet ne kerkesat e momentit. Dihet qe do te ndodhin
shume ndryshime, por nuk mund te parashikohet cilat jane ato. Per kete, eshte me e lehte qe
ato te trajtohen ne momentin qe behen reale. Nje model i thjeshte eshte me i lehte per tu
kuptuar dhe per tu modifikuar/ pershtatur.
3. Ndryshim/Planifikimi inkremental. Eshte me e thjeshte te trajtosh nje ndryshim sesa disa
njekohesisht. Ndryshimi duhet te integrohet me versionin e qendrueshem te software.
4. Ndryshimi konsiderohet si fenomen normal.
5. Cilesia e punes. XP ka te beje me projekte te shpejta, ku progresi demostrohet shpesh. Cdo
ndryshim inkremental duhet te implementohet me kujdes dhe ne menyre te plote. Nese
investohet koha e duhur qe pun ate behet qe ne fillim me cilesi te larte, atehere koha qe do te
duhet me vone per permiresime apo pershtatje do te jete me e vogel.
Kur perdoret XP, planifikimi percaktohet nga kerkesat dhe prioriteti i tyre. Nje iteracion fillon me
planifikimin e punes per te implementuar kerkesen qe klienti vendos qe duhet te implementohet.

Inxhinierimi i software

Leksion IV

XP nuk thekson riperdorimin si nje element kyc per rritjen e produktivitetit. Ai nuk e perjashton
riperdorimin, por gjithsesi inkurajon zgjidhjen me te thjeshte per kerkesen qe duhet te implementohet.
XP minimizon dokumentimin, kodi eshte vetedokumentues dhe ai njihet nga pothuajse te gjithe
anetaret e ekipit.
Cikli jetesor i XP ka kater aktivitete: planifikim, modelim, kodim, testim. Planifikimi behet ne fillim te
iteracionit, ndersa aktivitetet e tjera zhvillohen ne menyre inkrementuese. Ekzistojne disa kufizime:
1. Fillimisht shkruhen testet.
2. Shkruhen teste per cdo problem/ gabim te gjetur. Keto teste duhet te riprodhojne problemin. Kur
problemi zgjidhet, riekzektuohen testet e shkruara ne fillim.
3. Rishikohet dhe permiresohet kodi perpara se te zgjerohet ai per te implementuar funksionalitete
qe perkojne me nje kerkese te re.
4. Kodi shkruhet ne cifte kodi qe do te jete pjese e release te software
5. Integrimi eshte i shpeshte

Modeli Sinkronizo dhe Stabilizo


sht modeli q prdor Microsoft n pjesen m t madhe t projekteve q zhvillon. Parimi i tyre sht
t krijojne ekipe paralel, t vogla (3 8 persona) ose programues individual q funksionojn si nj ekip
i madh pr t ndrtuar produkte relativisht shpejt, por q n t njjtn koh i jep liri programuesve dhe
ekipeve t zhvillojn modelet e tyre dhe t veprojn pothuajse n mnyr autonome. Kto ekipe
zhvillojn veorit e reja apo tr produktin n mnyr inkrementuese duke futur edhe ide dhe
teknologji t reja. Mqs zhvilluesit jan t lire t fusin risi dhe individualizma, ata duhet t sinkronizojn
shpesh ndryshimet e tyre n mnyr q pjest t funksionojn si nj e tr. Thelbi i ktij modeli sht:
sinkronizo vazhdimisht ate q zhvilluesit (si individ apo ekipe) po zhvillojn dhe, stabilizo vazhdimisht
produktin n inkremente prgjat zhvillimit t proesit dhe jo n fund. Pra pjes t prfunduara
pjesrisht apo plotsisht gjat proesit t zhvillimit, bashkohen pr t par cilat jan funksionet e
realizuara dhe cilat jan problemet q ekzistojn. Teknikat e prdorura nga Microsoft adresojn
problemin e pranishm n shum kompani zhvillimi software: produktet me kompleksitet gjithmon e
m t madh nuk mund t ndrtohen m prej dy ose tre zhvillues, por duhen prfshir grupe pune m t
mdha q t mund t shpikin dhe sjellin risi gjat zhvillimit.
Ekipet e Microsoft e fillojn punn duke krijuar nj vizion duke prcaktuar objektivat q do t
prmbush produkti dhe duke prcaktuar aktivitetin e nj prdoruesi q do t prdor produktin.
Menaxhuesit e produktit dhe t programit prdorin input t vazhdueshem nga klientet pr sa me siper.
Bazuar mbi vizionin e krijuar, ndertohet dokumenti i specifikimeve t funksionaliteteve, cshtjeve t
arkitektures, ndervaresite e komponenteve. Me pas percaktohen oraret dhe krijohen ekipet q t kene
t pakten nj menaxher programi, 3-8 zhvillues, 3-8 testues. Gjate fazes se zhvillimit, menaxhuesit e
programit koordinojne evolimin e specifikimeve. Testuesit punojne n cift me programuesit. Projekti
ndahet n 3 nenprojekte: nenprojekti i par realizon 1/3 e vecorive me kritik t sistemit, i dyti 1/3 e
vecorive t tjera dhe i treti 1/3 e vecorive me pak kritike. Ekipet q kane punuar paralelisht,
sinkronizojne punen e tyre n fund t dites (perfshihen testime, debugime).
6