Projektim Software, Msc Nirida Pashaj Leksion 3

TEMA: MODELET E PROCESIT

Në këtë leksion...

Modele të procesit software.

 Modeli linear.
 Modeli prototip
 Modeli rad
 Modelet evolues.
 Zhvillimi i bazuar në komponentë
 Teknikat 4g

Për të zhvilluar një software një skuadër inxhinierësh duhet të zgjedhin një strategji pune e cila i tejkalon shtresat
e përmendura në leksionin 2: procesin, mjetet dhe metodat. Kjo strategji madje kalon edhe kufijtë e fazave të
përgjithshme përkufizim, zhvillim dhe suport. Kësaj strategjie i referohemi si model procesi ose paradigm i
inxhinierisë software. Modeli i procesit zgjidhet në varësi të aplikacionit, mjeteve dhe metodave të
përdorur, pritshmërisë së dorëzimit të aplikacionit.

Zhvillimi i software-it mund të shihet si një cikël i zgjidhjes së problemit ku dallohen qartë 4 stade: status quo,
përcaktimi i problemit, zhvillimi teknik, integrimi i zgjidhjes.

Figure 1

Status quo përfaqëson gjendjen aktuale të problemit.

Përcaktimi i problemit identifikon problemin që do të zgjidhet.

Zhvillimi teknik zgjidh problemin me anë të aplikimit të teknologjive.

Integrimi i zgjidhjes i dorëzon rezultatin final atyre që kanë kërkuar zgjidhjen e problemit.

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

Ky cikël i zgjidhjes së problemit i aplikohet punës së inxhinierisë software në disa nivele(figura 2). Ai mund të
aplikohet në nivel të lartë kur merret në konsideratë i gjithë aplikacioni, në nivel të mesëm kur inxhinierohen
komponentë të programit, madje edhe në nivel kodimi.

Figure 2

Realisht është e vështirë që tíi ndash aktivitetet e zgjidhjes së një problemi software aq qartë dhe dukshëm sa
në figurën 1. Megjithatë kjo pamje e thjeshtuar është e rëndësishme për të kuptuar një ide të rëndësishme: 4
stadet e zgjidhjes së një problemi software bashkëjetojnë brenda të njëjtit nivel detajimi.
Disa modele të procesit software

Build and fix

Figure 3 - build and fix

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

Ky është modeli më i thjeshtë i zhvillimit të software. Produkti ndërtohet bazuar në kërkesa minimale. Në
përgjithësi nuk bëhen specifikime dhe as tentativa për modelim; shpesh neglizhohet edhe testimi. Ndryshe quhet
edhe zhvillim ad-hoc i software-it. Sipas këtij modeli zhvilluesit shkruajnë kod dhe vazhdojnë ta modifikojnë
atë deri sa të kënaqen kërkesat e klientit. Modeli ofron avantazhet e kostos së ulët për sisteme me përmasa të
vogla dhe kompleksitet të ulët.

Për shkak të planifikimit të varfër ky është një model me shume risqe pasi:

 Eshtë i paaftë të përballojë sisteme të mëdhenj dhe të sofistikuar.

 Për sisteme kompleksë kostoja e zhvillimit rezulton më e lartë.
 Në shumicën e rasteve produkti nuk dorëzohet në kohë.
 Cilësia e ofruar është e ulët.
 Nuk prodhon dokumentacion.
 Mirëmbajtje e vështirë.

Zakonisht nevojitet një model më rigoroz zhvillimi.

2.Modeli linear sekuencial

Figure 4 - modeli linear sekuencial

Modeli linear sekuencial sugjeron një këndvështrim sistematik sekuencial mbi zhvillimin e software i cili fillon në
nivelin e sistemit për të vijuar me analizën, dizenjimin, kodimin, testimin dhe suportin.

Vështirësi:

 E vështirë për klientin të deklarojë të gjitha kërkesat siá duhet, qartësisht, në fillim te zhvillimit. Modeli nuk
e lejon këtë!
 Klienti duhet të ketë durim ñ nuk ka model(version) që punon deri ne fazë të mëvonshme të projektit.
 Zhvilluesit shpesh here vonohen pa nevojë- ata ìbllokohenë duke pritur për anëtarë të tjerë te ekipit për të
përfunduar punët e varura.

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

Modeli waterfall
Ky model është zgjerim/extension i modelit sekuencial linear. Shpesh i referohen edhe si modeli klasik i zhvillimit
të software. Ndonëse ka faza të dallueshme nga njëra tjetra secila prej tyre merr informacion dhe feedback nga
faza paraardhëse duke lejuar modifikimin e problemeve në software. Për këtë arsye procesi është një sekuencë e
përsëritjeve të aktiviteteve software.

figure 5 - modeli waterfall

Probleme:

 Cdo ndryshim në kërkesat e software, dmth ádo kthim prapa në ujëvarën e aktiviteteve përkthehet në
kosto financiare.
 Shpesh ndryshimet janë të vështirë për tu përshtatur pasi sistemi është në përpunim e sipër.
 Ndarje jofleksible e projektit në faza të dallueshme gjë që shkakton vështirësi në pasqyrimin e
ndryshimeve të kërkesave të klientëve.
 Prandaj është i përshtatshëm ath kur kërkesat janë të kuptuara mirë që në fillim.
 Megjithatë lejon punë në skuadër dhe ndarje të punëve.

Për shkak të problemeve të sipërpërmendur ekziston një tjetër variant i modelit waterfall; modeli waterfall i
përmirësuar. Modeli waterfall i përmirësuar bazohet në prodhimin e implementimeve të hershme dhe të
mëvonshme midis të cilëve rishikohen edhe një herë fazat e zhvillimit: analizë, dizenjim etj.

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

Figure 6 - modeli waterfall i rishikuar

4.Modeli prototip (prototyping model)

Shpesh klienti përcakton një grup të përgjithshëm objektivash për software-in e ardhshëm por nuk
identifikon saktësisht informacionin që do të shërbejë si input, mënyrën e përpunimit të tij, apo rezultatin
përfundimtar. Nga ana tjetër zhvilluesi mund të jetë i pasigurt në lidhje me efiáencen e një algoritmi,
përshtatshmërinë me os apo mënyrën e komunikimit midis pajisjes dhe njeriut. Në të tillë raste paradigmi i
prototipit është këndvështrimi më i mirë.

Paradigmi fillon me mbledhjen e kërkesave. Zhvilluesi dhe klienti takohen për të caktuar objektivat kryesorë të
sistemit, kërkesat e njohura dhe fushat mbi të cilat nevojitet përkufizim i mëtejshëm.

Dizenjim i shpejtë i cili fokusohet në prezantimin e atyre aspekteve që do të jenë të dukshëm për
klientin/përdoruesin. Dizenjimi i shpejtë prodhon një prototip.

Prototipi vlerësohet nga klienti/përdoruesi për të rafinuar kërkesat e zhvillimit të software-it. Iteracioni vazhdon deri
sa prototipi të kënaqë kërkesat e software.
Shpesh prototipi përdoret si një mjet për mbledhjen e kërkesave kur ky proces është i vështirë. «índodh me
prototipin pasi ai është vlerësuar? Në një pjesë të rasteve prototipi është një throw away prototip duke shërbyer
thjesht si një sistem fillestar. Një pjesë tjetër e prototipeve janë evolues.

Eshtë vënë re se edhe klientët edhe zhvilluesit e pëlqejnë paradigmën e prototipit. Përdoruesit marrin ndjesinë e
përdorimit për sistemin e ardhshëm ndërsa zhvilluesit marrin kënaqësinë e dhënies së një rezultati në kohë
rekord. Megjithatë ky paradigm është konstatuar të jetë problematik në disa raste:

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

 Duke parë një sistem që në njëfarë mënyre funksionon klienti fillon të pretendojë për afate kohorë më të
hershëm pa e ditur se prototipi që ka në dorë është një sistem shumë delikat dhe lehtësisht i
shkatërrueshëm.

 nën presionin e klientit zhvilluesi bën kompromise për të lëshuar sa më shpejt një version
përfundimtar duke rrezikuar kështu zgjedhjen e algoritmeve apo teknikave të gabuara për zhvillim.

Figure 7 - model prototip

5.Modeli rad(rapid application development)

Rad është një model inkremental i zhvillimit të software i cili vendos theksin mbi një cikël shumë të shkurtër të
zhvillimit të software. Modeli rad përbën një aplikim shumë të shpejtë të modelit sekuencial linear, në
këtë rast zhvillimi i shpejtë sigurohet në sajë të përdorimit të komponentëve. Nqs kërkesat janë kuptuar dhe
specifikuar mirë ath modeli rad i mundëson një skuadre zhvilluesish të krijojë një sistem funksional brenda një
kohe shumë të shkurtër(60-90 ditë). Ky model kryesisht përdoret në zhvillimin e aplikacioneve të sistemeve të
informacionit.

Procesi kalon në fazat e mëposhtme:

 Modelimi i biznesit. Përcakton rregullat e biznesit të aplikacionit në varësi të fushës së aplikimit.

 Modelimi i të dhënave. Modelon objektet dhe atributet e tyre sipas rrjedhës se informacionit të përcaktuar
në fazën e modelimit të biznesit.

 Modelimi i procesit. Objektet e përcaktuar në fazën paraardhëse përshtaten në mënyrë të tillë që të

mbështesin rrjedhën e duhur të informacionit dhe mënyrën e duhur të përpunimit të tij. Shtohet mundësia
për të fshirë, krijuar, modifikuar dhe aksesuar një objekt të dhënash.

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

 Gjenerimi i aplikacionit. Rad përdor metodat e brezit të 4-t për të gjeneruar sa më shpejt aplikacionin.
Mbi të gjitha synon të ripërdorë komponentët ekzistuese.
 Testim dhe rishikim. Mqs rad përdor gjerësisht komponentët gjatë fazës së testimit secila prej
komponentëve është tashmë e testuar. Kjo shkurton kohën e testimit. Megjithatë mbeten për tu testuar
elementë të tjerë si komponentët e reja, ndërveprimi midis komponentëve dhe ndërfaqet.

Figure 8- rad

Figura ilustron organizimin e punës në skuadra sipas modelit rad. Nqs projekti mund të modularizohet në mënyrë
të tillë që secili prej moduleve apo komponentëve mund të përfundojë brenda një afati kohe te shkurtër me te
vogël se tre muaj atëherë ky projekt është një kandidat i mire mbi te cilin mund te aplikohet modeli rad.

Disavantazhe:

 Për projekte te mëdhenj te modularizueshëm ky model kërkon burime njerëzore te

mjaftueshëm për të përballuar numrin e skuadrave që duhet të krijohen.

7 Nirida
P h j
 Projektim Software, Msc Nirida Pashaj Leksion 3

 Jo te gjithë aplikacionet janë te përshtatshëm për rad. Nqs projekti nuk mund te modularizohet siá duhet
atëherë aplikimi i rad mund te paraqesë probleme. Nqs nevojitet performancë e lartë ath rad mund te mos
ta mbështesë ketë kërkese për shkak të komunikimit midis ndërfaqeve dhe komponentëve.
 Këndvështrimi rad nuk është ideali nqs paraqiten rreziqe te larta teknike. Kjo ndodh kur përdoren
teknologji te reja ose kur software i ri pritet te komunikoje me programe ekzistues kompjuterike.

Modelet evolues

Àshtë tashmë e njohur se sistemet software sikurse sistemet e tjerë komplekse evoluojnë me kalimin e kohës.
Kërkesat e biznesit ndryshojnë vazhdimisht duke e bere te pamundur një këndvështrim linear mbi projektin, afatet
kohore janë gjithmonë te limituar, nevojitet një produkt prezantues për klientin i cili te ketë funksionalitetet baze,
një pjese e kërkesave thelbësore te sistemit janë kuptuar mire por ka shume detaje qe duhen specifikuar ende;
situatat e përmendura me sipër kane nevoje për një model i cili te mbështesë evoluimin e software-it ne kohe.
Asnjeri prej modeleve te paraqitur deri tani nuk e mbështet plotësisht këtë dukuri.

Modelet evolues janë iterative. Ato janë konceptuar ne mënyrë te tille qe tíi ndihmojnë inxhinieret software që të
prodhojnë versione gjithmonë dhe më te plota të sistemeve që ata ndërtojnë.

8 Nirida
P h j
Projektim Software, Msc Nirida Pashaj Leksion 3

8 Nirida
P h j