Inxhinieria Softuerike Procesi Dhe Korniza Softuerike: Ramiz HOXHA 2021/2022

Inxhinieria Softuerike
Procesi dhe Korniza Softuerike

R a m i z H OX H A
r a m i z . h ox h a @ u b t - u n i . n e t
2021/2022
Ramiz HOXHA © 2021 UBT 1

Procesi Softuerik
❑Një proces është një koleksion aktivitetesh, veprimesh dhe detyrash që çojnë në
ralizimin e një produkti softuerik.
▪ Proces nuk është një formual e ngurtë për mënyrën e ndërtimit të softuerit, përkundrazi është një
qasje e adaptueshme që u mundëson përsonave që kryejnë punën të përcaktojn dhe zgjedhini grupin e
duhur të veprimeve dhe detyrave të punës.
❑Një aktivitet synon të arrijë një objektiv të gjerë (p.sh., komunikimi me palët e
interesuara për përcaktimin e shërbimeve etj),
❑Një veprim (p.sh., dizajnimi arkitektures aplikacionit) përfshin një sërë detyrash
që rezulon në elemente kryesor të produkt (p.sh., një model arkitektonik).
❑Një detyrë fokusohet në një objektiv të vogël, por të përcaktuar mirë (p.sh. kryerja
e një testi të njësisë (unit testing)) që prodhon një rezultat të prekshëm.
* Secili nga aktivitetiet, veprimet & detyrat - qëndrojnë brenda një kornize ose modeli.
Korniza e Procesit të Softuerit
❑Një kornizë e procesit vendos bazën për procesin e plotë të inxhinierisë së softuerit,
ai përfshin pesë aktivitete.
❑ Aktivitetet e kornizës së Procesit:
▪ Komunikimi – Komunikimi me klientët/palet-interesit për të kuptuar kërkesat e sistemit për
përcaktimin e veçorive (features) të softuerit;
▪ Planifikimi – Plani i projektit të softuerit i cili përcakton rrjedhën e punës që duhet ndjekur,
përshkruan detyrat teknike, rreziqet, risurset, produktin që do të implementohet dhe orarin e punës;
▪ Modelimi – Krijimi i modeleve për të kuptuar kërkesat dhe dizajnuar (dizajnin Arkitektures softuerit,
BDH, UI, Modules etj) për t’i përmbushur kërkesat ;
▪ Konstruktimi – Gjenerimi i kodit (manual ose i automatizuar) dhe testimi (për të identifikuar
gabimet në kod);
▪ Vendosja (Deployment) – Ofroni (deliver) softuerin klientëve, mblidhni komente nga klienti bazuar në
vlerësimin, përfshirë mbështetjen e softuerit;
ref: Software Engineering: A Practitioner's Approach 9th Edition by Roger Pressman , Bruce Maxim

Korniza e Procesit të Softuerit...
❑Aktivitetet e kornizës së Procesit përfshijnë katër aktivitete bazë:
▪ specifikim - definimi i asaj që duhet të bëjë sistemi (funksionet, shërbimet, kufizimet në operimin dhe
implementimit e tij);
▪ dizajnimi dhe implementimi – definimi i organizimit të sistemit (p.sh.,dizajnimi arkitektures se
softuerit, BDH, UI, moduleve etj.) dhe implementimit (kodimi, rregullimi i gabimeve);
▪ validimi - kontrollimi nëse sistemi bën atë që dëshiron klienti;
▪ evuluimi – ndryshimi (mirmbajtja) i sistemit në përgjigje të ndryshimit të nevojave të
konsumatorëve.
ref: Software Engineering. Ian Sommerville. Addison-Wesley, 10th edition

Modelet e Procesit Softuerike
❑Cikli i jetsimit të zhvillimit të softuerit (SDLC) ose modelet e ciklit jetsimit të zhvillimit të
aplikacioneve:
▪ Modelet e Procesit Softuerike – përshkruajë një grup të veçantë aktivitetesh, veprimesh, detyrash dhe
milestones (dorzimet/deliverables) të nevojshme për të krijuar softuer me cilësi të lartë.
▪ Modelet e procesit nuk janë të përsosura, por ofrojnë

udhërrëfyes për punën e inxhinierisë softuerike.
▪ për shumë projekte softuerike, aktivitetet e kornizës

aplikohen në mënyrë iterative (të përsëritur) përdërsa
një projekt progreson (implementohet).

Modelet e Procesit Softuerike...
❑Modeli i procesit zgjidhet bazuar në ❑Modelet e Procesit Softuerike
parametra të ndryshëm: o Modeli Linear (ujvar/waterfall)
▪ Lloji i projektit dhe njerëzit, o Modeli Iterative
▪ Kompleksiteti i projektit o Modeli Prototype
▪ Madhësia e ekipit o Modeli Spiral
▪ Ekspertiza e njerëzve në ekip o Modeli RAD (Rapid Application
Development)
▪ Mjedisi i punës së ekipit
o Modeli Agile Model
▪ Afati i dorëzimit të softuerit
o Modeli (i ri) DevOps

praktika e Inxhinierisë Softuerike
❑Thelbi i praktikës së inxhinierisë softuerike :
▪ Kuptoni problemin (komunikimi dhe analiza).
▪ Planifikoni një zgjidhje (modelimi dhe dizajni i softuerit).
▪ Realizoni planin (gjenerimi i kodit).
▪ Ekzaminoni rezultatin për saktësi (testimi dhe sigurimi i cilësisë).
❑Si fillon gjithçka:

▪ çdo projekt softuerësh nxitet nga një nevojë e biznesit—nevoja për të korrigjuar një defekt në një
aplikacion ekzistues;
▪ nevoja për t'iu përshtatur një mjedisi biznesi në ndryshim;
▪ nevoja për të zgjeruar funksionet dhe veçoritë e një aplikacioni ekzistues;
▪ nevoja për të krijuar një produkt, shërbim ose sistem të ri.

parimet që udhëzojnë Procesin
❑procesi i softuerit dhe modelet e procesit janë propozuar për punë inxhinierike
të softuerike.
▪ secili projekt është unik dhe secili ekip është unik, që do të thotë që ju duhet ta përshtatni
procesin tuaj për t'iu përshtatur më së miri nevojave tuaja.
❑Për secili Proces Softueike aplikohen parimet:
▪ Parimi 1. Bëhu i agile.
▪ Parimi 2. Përqendrohuni te cilësia në çdo hap
▪ Parimi 3. Bëhuni gati për t'u përshtatur
▪ Parimi 4. Ndërtoni një ekip efektiv.
▪ Parimi 5. Krijo mekanizma për komunikim dhe koordinim
▪ Parimi 6. Menaxhoni ndryshimin.
▪ Parimi 7. Vlerësoni rrezikun.
korniza e thjeshtuar e procesit
▪ Parimi 8. Krijoni produkte që ofrojnë vlerë për të tjerët

parimet që udhëzojnë secilin Aktivitet të Kornizës
❑Parimet e Komunikimit
▪ Kërkesat e klientëve të mbledhura përmes aktivitetit të komunikimit.
▪ Një klient ka një problem, zgjidhja është e bazuar në kompjuter.
▪ Komunikimi efektiv (midis kolegëve teknikë, me klientin dhe palët e tjera të interesit, dhe me menaxherët e
projektit) është ndër aktivitetet më sfiduese me të cilat do të përballeni..
❑Parimet e Planifikimit
▪ Aktiviteti i planifikimit përfshin një sërë praktikash menaxhuese dhe teknike që i mundësojnë ekipit të softuerit të
përcaktojë një road-map përdërsa drejtohe në qëllimit të tij strategjik dhe objektivave taktike.
▪ Parimi 1. Të kuptoni skopin e projektit
o Është e pamundur të përdorësh një road-map (hartë rrugore) nëse nuk e di se ku po shkon. Skopi i siguron ekipit të softuerit
një destinacion.
▪ Parimi 2. Përfshini palët e interesit në aktivitetin e planifikimit.
o Palët e interesuara përcaktojnë prioritetet dhe vendosin kufizimet e projektit.
▪ Parimi 4. Kalkuloni (llogariteni) në bazë të asaj që dini.
o Qëllimi i llogaritjes është të sigurojë një indikator të arritjes, kostos dhe kohëzgjatjes së detyrës, bazuar në të kuptuarit aktual të ekipit për
punën që duhet bërë ………….
parimet që udhëzojnë secilin Aktivitet të Kornizës…
❑Parimi i Modelimit
▪ Ne krijojmë modele për të kuptuar më mirë entitetin aktual që do të ndërtohet.
▪ Parimi 1. Qëllimi kryesor i ekipit të softuerit është të ndërtojëm softuer, jo të krijojë modele.
o ofrimi e softuerit te klienti në kohën më të shpejtë të mundshme.
o Modelet që e bëjnë këtë ia vlen të krijohen, por modelet që ngadalësojnë procesin ose ofrojnë pak informata të reja duhet të shmangen.
▪ Parimi …….
▪ Parimi 7. Përpiquni të ndërtoni modele të dobishme, por harroni të ndërtoni modele të përsosura.
❑Parimi i Konstruktimi (Ndertimit)
▪ Ky aktivitet përfshin një sërë detyrash kodimi dhe testimi që ofrojn një softuer operacional që është gati
për t'u dorëzuar te klienti ose përdoruesi.

parimet që udhëzojnë secilin Aktivitet të Kornizës…
❑Parimi Deployment
▪ Aktiviteti i dorzimit (deployment) përfshin tre veprime:
o dorzim (instalim),
o mbështetjen dhe
o feedback.
▪ Modelet moderne të procesit të softuerit janë evolucionare ose rritëse në natyrë, dorzimi nuk ndodh
një herë, por disa herë përderisa softueri shkon drejt kompletimit.
▪ Dorëzimi i një verzioni (inkrementi) të softuerit përfaqëson një moment historik të rëndësishëm për
çdo projekt softuerësh

Skopi (Fushëveprimi) i Projektit Softuerik
❑Çka është Skopi (fushëveprimi)?
▪ Skopi i projektit është pjesa e planifikimit të projektit që përfshin përcaktimin dhe dokumentimin
e një liste të qëllimeve specifike të projektit, rezultateve, detyrave, kostos dhe afateve të dorzimeve.
❑Skopi është puna që duhet bërë

▪ Karakteristikat dhe funksionet që karakterizojnë një produkt, shërbim ose rezultat.
❑Përcakton kufijtë e një projekti,

▪ cilat veçori (features) do të përfshihen dhe implementohet në këtë skop,
▪ cilat janë datat e dorëzimit dhe etapat e dorëzohimit, si dhe buxheti i kërkuar për të ofruar atë skop.

Project Scope Statement
Title Timesheet Reporting Tool Date June 08, 2017
Project Manager Nicole Hansen
Project Justification The Timesheet Reporting tool will be the creation of a user-friendly web-based application. The application will automate the process of tracking the daily time entries made by employees.
Project Scope Description The timesheet reporting tool will be used as a tracking tool to review the time entries by the Information Technology employees globally.
Project Objective To create a tool to track the timesheet entries for all the Information Technology employees.
• User access for the tool granted to all employees
• Admin access to support team
High-Level Requirements • Report generation access to project managers
• Enable users to remotely access the tool
• Standard templates for all reports
• Multi-level approvals for timesheets
• Timesheet tasks additions to the tool by Admin access users
In Scope
• ‘Copy Previous Week’ timesheets feature
• Access tool via Desktop
• New project/task added to the tool by managers
• Connectivity with HRMS to update employee leaves automatically
Out of Scope
• Role-based task list template
• Access tool via mobile and tablet
Cost Item Estimated Project Cost Actual Spend Cost until completion Variance
Software $2300 $900 $1400 NA
Cost Estimate Hardware $5000 $1500 $3500 +/- 1000
Other $750 $0 $750 +/- $100
Total $8050 $2400 $5650
• Timesheets will be updated by users daily.
Assumptions
• Timesheets task list will be updated once a month
• A Single system to record time hours for FTE and Contractors
• Run timesheet reports identifying missing entries
Deliverables • Generate reports identifying productive tasks and work hours
• Generate charts for steering committee packs
• Detailed user guide on steps to update the tool for all users
• Unplanned leaves not captured from the leave system
Constraints
• Timesheet view access for the team only to Direct managers

Pytje
Faleminderit…!

Referencat
❑Kapitulli 1, Kapitulli 6:
▪ Software Engineering: A Practitioner's Approach 9th Edition by Roger
Pressman (Author), Bruce Maxim (Author)

Modelet & Metodologjite e
Procesit për Zhvillimin e Softuerit
R a m i z H OX H A
2021/2022

Projekti i Softuerit
❑Një projekt është një grup i veprimeve të planifikuara dhe të realizuara nga
një grup njerëzish për të arritur një qëllim të caktuar, duke u kufizuar nga një
afat-kohor, dhe ka një kosto të caktuar.
❑Për të menaxhuar një projekt është e nevojshme të:

▪ Përcaktoni metodologjinë e zhvillimi të softuerit.
▪ Menaxhoni njerëzit e përfshirë
▪ Menaxhoni kufizimet teknike
▪ Menaxhoni mjetet e disponueshme …

Procesi i Zhvillimit të Softueri
❑Metodologjia e Zhvillimit të Softuerit - është korniza e përdorur për të planifikuar,
kontrolluar dhe strukturuar procesin e zhvillimit të sistemit softuerik.
❑Gjithashtu quhet:
▪ Cikli i jetsimit të zhvillimit të softuerit ose Procesi i zhvillimit të softuerit
❑Fazat SDLC adresojnë kompleksitetin që qëndron në themel të zhvillimit
të softuerit dhe përpjekjeve për të përmirësuar procesin.
▪ Qëllimi është të sigurohet që rezultatet përfundimtare të përputhen me cilësinë dhe
funksionalitetin e sistemit.
▪ Përfshine aktivitete, qëllimi i të cilave është zhvillimi ose përmisim i softuerit.

❑SDLC është qasja standarde e industrisë për
menaxhimin e fazave të një projekti inxhinierik
❑Aktivitetet/fazat e përgjithshme në të
gjitha proceset e softuerit/SDLC.
▪ Specifikimi/Analiza (Planefikimi & definimi i
kërkesave të sistemit dhe përdoruesit).
▪ Dizajnimi (Dizajnimi i arkitektures, programit,
GUI, etj).
▪ Implementimi (Kodimimi i sistemit)
▪ Validimi (Testimit dhe Miratimi)
▪ Evuluimi (Mirmbajtja dhe Zbatimit/Dorzimi)

Procesi i Zhvillimit të Softueri…
Specifikoni
Kërkesat e Produktit
Produktin
Specifikoni
Kërkesat e Softuerit
Softuerin
Krijoni
Dizajni i Nivelit të Lartë
Arkitekturë sw
Dizajno
Modulet
Dizajni i Nivelit të Ultë (detajuar)
Implemtimi Kodi Burimor

(kodimi)
Procesi i softuerit është një grup aktivitetesh që
Testimi &
ndërlidhet me ndërtimit e softuerit. Validimi
Sistemi i Ndertuar
Zbatimi (Instalimi)
Këto aktivitete përfshijnë zhvillimin e produktit softuerikë & Mirmbajtja
nga fillimi e deri në përfundim.

❑Megjithatë, një process softuerik përfshin gjithashtu përshkrimin e procesit
i cili përfshin:
▪ Produktet: rezultatet e një aktiviteti. p.sh, Specifikimi i Kërkesës për Softuerin (SRS) ndoshta
një model për arkitekturën e softuerit.
▪ Rolet: përgjegjësitë e njerëzve të përfshirë në proces. p.sh, menaxheri i projektit,
programuesi, testuesi etj.
▪ Para-Kushtet dhe Pas-Kushtet :
o p.sh, kushtet paraprake të dizajnit arkitekturor janë kërkesat e miratuara nga
klienti, ndërsa gjendja pas është diagramet që përshkruajnë arkitekturën që janë
shqyrtuar.

❑Cikli i jetsimit të Softuerit:
▪ Përcakton të gjitha fazat/aktivitetet e zhvillimit të softuerit, duke filluar nga specifikimet e
kërkesave të klientit, deri në fazat e fundit të krijimi i softuerit.
❑Këto faza janë të organizuara sipas modeleve që drejtojnë (guide) inxhinierin në
aktivitetet e tij.
▪ Modelet Lineare (Linear models)
▪ Modelet Përsëritëse (Iterative models)
▪ Modelet Rritëse (Incremental models)
▪ Modelet Adaptive (Adaptive models)
▪ Modelet Ekstreme (Extreme models)

Modelet e zhvillimit të Softuerit

❑Modeli Linear
▪ Aktivitetet ose fazat e varura janë ekzekutuar në një mënyrë sekuenciale duke mos ofruar ciklin e
regimit (feedback).
▪ Zgjidhja ofrohet vetëm në fazën finale (përfundimtare).
▪ Qëllimet, kërkesat dhe zgjidhjet e definuara mirë, ofrojnë shumë-pak ndryshim për
kërkesat e fushëverpimit të projektit. Modeli Linear-Sekuencial
▪ Modeli linear-sekuencial referohet gjithashtu si

Modeli Ujëvara i cili është shumë i thjeshtë për tu
kuptuar dhe përdorur.
▪ Në këtë model (modeli ujëvarës) secila fazë duhet të

përfundojë para se të fillojë faza tjetër dhe nuk ka
mbivendosje (overlapping) të fazave.

❑Modeli Rritës (Incremental)
▪ Ngjajshem si modeli linear, por ky model për secilen fazë (iteracion) lëshohet (ofrohet) një zgjidhje
e pjesshme ose deliverable.
▪ Këto iteracione janë zakonisht komplimente për njëra-tjetrën, me përfundimi e të gjitha iteracionet,
produkti është i plotë.
▪ Qëllimet, kërkesat dhe zhvillimi është bërë korrekt pa pasur nevojë të e kthehemi
mbrapa,(orar më agresiv.)
▪ Qasje rritëse me e dobishme në krahasim me atë sekuenciale,
veçanërisht kur madhësia e projektit nuk është e vogël.
▪ Minimizon rrezikun pasi secili inkrement (iteracion) mund të ofrohet
në 2-3 muaj.
▪ Ciklet e shkurta të rritjes përmirësojnë bashkëpunimin e klientit me
ate të zhvillimit (zhvilluesit).
▪ Ofron produktin final në formë të komponenteve (builds).

Modelet e zhvillimit të Softuerit…
❑Modeli Përsëritës (Iterative)
▪ Fazat përsëriten, kemi mundesi feedback’ut pas përfundimit të secilit iteracion.
▪ Në fund të iteracionit mund të rezultoj me një zgjidhje të pjesshme ose përfundimtare.
▪ Qëllimet e definuara mirë, jo të gjitha funksionet
(karakterisitikat) e njohura, strategjia learn-by-doing
▪ Aftësia për t’i përfshirë ndryshimet në çdo iteracion
▪ Iteracionet e vogëla ofrojnë bashkëpunim me të shpeshtë me klientin në fund të çdo
iteracioni.
▪ Ofron verzione dhe feadback më të hershëm mbi produktin, zbut rrezikun e hendekut
në pritjet e klientit dhe të kuptuarit të ekipit të zhvilluesve.
▪ Feadback (Reagimet) përdoren për të rishikuar prioritetet e projektit dhe për të bërë
ndryshime në kërkesat, funksionalitetet, planifikimet, risurce, etj.
Një qasje iterative më e dobishme krahasuar me qasjen rritëse, posaçërisht kur
kërkesat e projektit pritet të ndryshojnë shumë

Rritëse vs Përsëritës (Incremental vs Iterative)
Incremental
Iterative

Rritëse & Përsëritës (Incremental & Iterative)…

Metodologjitë e zhvillimit të softuerit

❑Metodologjitë e zhvillimit të softuerit:
o Waterfall / Ujëvarës
o V-Model
o Prototyping / Prototipit
o Spiral
o RAD
o Unified Process / Procesi i Unifikuar
o Agile/i Shkathët
o DevOps

Metodologjia Ad-hoc (Big Bang)
❑Në mënyrë tipike, “nuk konsiderohet” një lloj i metodologjisë!
▪ Klienti shpreh nevojat e tij, dhe zhvilluesi thjesht bën punën!
❑Përparsi:
▪ E thjeshtë dhe e drejtpërdrejtë
▪ E përshtatshme për sisteme të vogla dhe të thjeshta
❑Mangësi: Një problem i madh nëse:

▪ Klienti nuk i shpreh saktë nevojat e tij.
▪ Zhvilluesi nuk di si të procedojë me implementimin
▪ ... dhe kjo nuk ka mbështetjen e ndonjë ndryshimi në kërkesat

Metodologjia Waterfall / Ujëvarës
❑Model linear
▪ Testimi bëhet pasi kodi të zhvillohet plotësisht
❑ Përparsi
▪ Kërkesa është e qartë para se të fillojë zhvillimi (kodimi)
▪ Secila fazë përfundon në një periudhë specifike kohore.
▪ Si model linear, është i lehtë për tu zbatuar
▪ Secila fazë rezulton me një dokumentim përkatës të duhur
❑ Mangësi:
▪ Mund të shfaqen probleme kur kalojmë nga një faza në tjetren.
▪ Nuk është fleksibil dhe nuk mbështet ndonjë ndryshim të kërkesave
▪ Klienti e sheh produktin pasi të mbarojnë të gjitha fazat.

Metodologjia e Prototipit
❑ Metodologjia e Prototipit ofron një version inicial të një
prototipi të aplikacionit
▪ Simulon vetëm disa aspekte të produktit përfundimtar dhe mundesi
për të identifikuar problemet dhe zgjidhjet e mundshme.
❑ Përparsi
▪ Përfshirje më e madhe e përdoruesve/klienteve në produkt, para
implementimit të tij.
▪ Përdoruesit/klientet e kan më të qartë se çfare do të ofroj softuerit
që po zhvillohet.
▪ Ulet koha dhe kostot pasi që defektet mund të identifikohen shumë
më herët.
▪ Feedback më të shpejta nga përdoruesit që rezultojn në zgjidhje më
të mira.
▪ Funksionet që mungojnë ose ato konfuze apo të vështira mund të
identifikohen lehtësisht.
▪ Ide të reja për dizajnim/funksione.

Metodologjia e Prototipit…
❑Mangësi:
▪ Rreziku i analizës të pamjaftueshme së kërkesave për shkak të varësisë shumë nga
prototipi.
▪ Përdoruesit mund të ngatërrohen me prototipet dhe sistemet reale.
▪ Praktikishtë, kjo metodologji mund të rrisë kompleksitetin e sistemit pasi qëllimi i
sistemit mund të zgjerohet përtej planeve origjinale.
▪ Zhvilluesit mund të përpiqen të ripërdorin prototipet ekzistuese për të ndërtuar
sistemin e vërtetë, edhe kur nuk është teknikisht i realizueshëm.
▪ Investimet në prototip mund të jetë larta nëse nuk kontrollohet si duhet.

Metodologjia e Modelit-V
❑Versioni i modifikuar i metodës së ujëvarë (modeli linear)
▪ Fazat janë pasqyruar për të verifikuar dhe validuar secilen prej tyre.
▪ Testuesit dhe zhvilluesit punojnë paralelisht, test Rastet përgatiten për secilen faze.
❑ Përparsi
▪ Njëjt si ujëvara + testuesi është i përfshirë nga faza e
kërkesës.
❑ Mangësi:
▪ I ngurtë
▪ Nëse ndryshimet ndodhin në mes të rrugës, jo vetëm
dokumentacioni i kërkesave, por edhe
dokumentacioni i testimit duhet të ndryshohet
▪ Nuk është i përshtatshëm për projekte afatshkurtra
pasi kërkon rishikime në secilën fazë

Metodologjia Spiral-e
❑ Modeli linear dhe rritës + Prototipi
▪ Focus në vlerësimin e rrezikut
▪ 4 faza kryesore:
o Percaktimin e Objektivave, Analizon Rreziqet,
Inxhinieria (dizajn, kodim, testim) dhe Planifikimi.
▪ Modeli spiral është i favorizuar për projekte të
mëdha, të shtrenjta dhe të ndërlikuara
❑ Kur të përdorim modelin spiral:
o Kur vlersohet kostoja dhe rreziku është i rëndësishëm.
o Kur krijimi i një prototipi është i përshtatshëm
o Kërkesat janë komplekse
o Projeket kosiderohen ne rrezik nga niveli mesëm në të
lartë
o Priten ndryshime të rëndësishme/të mëdha
o Përdoruesit janë të pasigurt për nevojat e tyre

Metodologjia Spiral-e…
❑Përparsi:
▪ Sasi të lartë të analizës së rrezikut.
▪ Feedback të hershme dhe të shpeshta nga përdoruesit si rezultati i
perdorimeve te prototipeve
▪ Softueri ofrohet në fazat e hershme
❑Mangësi:
▪ Mund të jetë i kushtueshëm
▪ Analiza e rrezikut kërkon ekspertizë shumë specifike
▪ Nuk është adekuat për projekte të vogla

Metodologjia RAD: Rapid Application Development
❑RAD: Zhvillimi i shpejtë i aplikacionev (Iterative, incremental dhe adaptative)
▪ Përdor planifikim minimal në favor të prototipeve të shpejta.
❑Mbledh kërkesat e klientëve përmes:
▪ Workshops ose fokus grupeve
▪ Testimi i hershëm i prototipeve duke përdorur konceptin përsëritës
▪ Ripërdorimi i prototipave ekzistues
▪ Integrimi i vazhdueshëm.

Metodologjia RAD: Rapid Application Development…
❑Projekti mund të ndahet në module të vogla ku çdo modul mund të caktohet
në mënyrë të pavarur ekipeve të veçanta.
❑Kur përdoret Metodologjia RAD?
▪ Kur një sistem duhet të prodhohet në një kohe të shkurtër (2-3 muaj)
▪ Kur dihen kërkesat
▪ Kur përdoruesi do të përfshihet gjatë gjithë ciklit jetësor të projektit
▪ Kur rreziku teknik është më i vogël
▪ E zbatueshme për sistemet modulare
▪ Kur një buxhet është mjaft i lartë për të përballuar dizajnuesit për
modelim së bashku me koston e mjeteve të automatizuara për
gjenerimin e kodit.

Metodologjia UP (Procesi i Unifikuar )
❑PU – model Iterative dhe incremental, i drejtuar në USE CASE dhe i orientuar
ne arkitekturen e sistemit.
1) Inception (Zanafilla), ka për qëllim të vendos këkesat e biznesit për sistemin. Gjatë kësaj faze
identifikohen entitetet e jashtme (njerëzit dhe sistemet) që do të ndër veprojnë me sistemin që po e
ndërtojmë
2) Elaboration (Elaburimi), ka për qëllim të kuptuarit e problemit, krijimin konceptual të arkitekturës së
sistemit dhe krijimin e planit të zhvillimit.
3) Construction (Ndërtimi), është fazë ku dizajnohet, programohet dhe testohet sistemi
4) Transition (Trazicioni) është faza finale e RUP ku produkti kalon në shfrytëzim (deployed)

❑ Inception (Zanafilla): 10% kohës, 5% përpjekje (Effort).
▪ Ndihmon për të përcaktuar fizibilitetin e projektit dhe
çfarë dëshiron konsumatori.
▪ Identifikimi e funksioneve kryesore të sistemit
o Një modelim fillestar të Use Case’es (10-20% të sistemit)
o Një ose disa prototipa.
❑ Elaboration (Elaburimi) : 30% kohës, 20% përpjekje (Effort)
▪ Definon dhe përcakton arkitekturen në bazë të
aplikacionit
▪ I kuptojm më thell kërkesat
o Modelim të plotë të 80% Use Casave.
o Përcaktojm kërkesta Jo-Funksionale
▪ Përshkrimi i arkitekturës së softuerit
▪ Prototipi arkitektonik i ekzekutueshëm

Metodologjia UP (Procesi i Unifikuar)…
❑ Construction (Ndërtimi): 50% kohës, 65% përpjekje (Effort).
▪ Iterativisht kompleton zhvillimin/kodimin e plotë të
produktit.
▪ Integron aplikaciomin në platforma adekuate
▪ Ofron manuale te përdorimit.
❑ Transition: 10% kohës, 30% përpjekje (Effort).
▪ Dorzon produktin (aplikacionin) te klienti/përdoruesi
▪ Ralizon testimin Beta për të vërtetuar sistemin e ri
kundrejt përvojës së përdoruesit
▪ Trajnimi i përdoruesve dhe mirëmbajtësve

Metodologjia Agile
❑Grupi i metodave të zhvillimit të
softverit
❑Bazuar në zhvillimin përsëritës+rritje
❑Fraza më të rëndësishme:
▪ ekipe vetë-organizuese, ndër-funksionale
▪ planifikim adaptues,
▪ zhvillimi evolucionar dhe dorzim (delivery),
▪ Një qasje përsëritëse (iterative), bllok-kohe (time-
boxed), e orientuar drejt njerëzve dhe e përqendruar
në rezultat,
▪ dorzimi i softverit në mënyrë graduale
▪ reagim (feedback) i shpejtë dhe fleksibël ndaj
ndryshimeve.
❑Një kornizë konceptuale
Metodologjia Agile…
❑Metodologjia e Agile thekson 4 vlera dhe 12 parime për zhvillimin e softuerit.

Nga 4 vlerat e Agile rrjedhin 12 parimet e mëposhtme

❑ Benefitet:
▪ Fokusim ne Perdorues – Tregim të Perdoruesit me fokus biznisor duke determinuar kriteret e pranimit për
karakteristikat/funksionet e produktit/aplikacionit.
▪ Fokusim në vlerën e Biznesit- dorzimi i pjese së aplikacioni (funksioneve) që ofron vlere biznisore bazuar
në rëndesine e biznesit të klientit.
▪ Përmirëson Cilësinë - fokusohet në cilësi të lartë të zhvillimit, testimit dhe bashkëpunimit duke e ndarë
projektin në njësi të menaxhueshme.
▪ Transparenca - mundësi që klientët të përfshihet dhe të monitorojnë gjatë gjithë proceseve në projekt.
▪ Dorëzimi i hershëm dhe i parashikueshëm - shërbime, produkte ose funksione të reja të cilat dorëzohen ne
orar fiks sipas Sprintave.
▪ Parashikim të kostos dhe orarit- orar-fiks, klienti mund të kuptojë koston e përafërt të secilit funksion,
prandaj përmirëson vendimmarrjen, jep përparësi funksioneve dhe rendesin për iteracione shtesë.
▪ Lejon ndryshimin -Ekipet bëjnë ndryshime në mënyrë që të përmirësojnë funksionet dhe
efektivitetin. Ndryshimet mund të alokohen ne iteracionin e ardhshem.
▪ Inkuadrim i palëve të interesuara. Palët e interesuara dhe zhvilluesit punojnë ngushtë çdo ditë.

Metodologjia DevOps
❑Mungesë bashkëpunimi midis Zhvilluesve dhe Inxhinierëve Operativ, kjo ngadalësoi
procesin e zhvillimit dhe dorzimeve të aplikacionit.
▪ Megjithëse metodologjia Agile solli shkathtësi në zhvillim, ajo nuk arriti të sjellë shkathtësi në operim.
❑ DevOps është një metodë e zhvillimit të softuerit

që drejton zhvillimin dhe operimin e aplikacioni në
mënyr vazhdueshme për të përmisuar
produktivitetin dhe ofruar bashkpunim më të mirë
mes ekipeve (zhvillimit dhe operimit)
▪ DevOps është një proces i vazhdueshëm i ndërtimit, testimit, vendosjes (deployments) dhe monitorimit.

Metodologjia DevOps…
❑ Automatizimi është çelësi i DevOps.
❑ DevOps përbëhet nga faza të ndryshme si:
▪ zhvillimi i vazhdueshëm, integrimi i vazhdueshëm, testimi i vazhdueshëm, vendosja e vazhdueshme dhe monitorimi i
vazhdueshëm.

Procesi Ujëvares vs Agile

Procesi Ujëvares vs Agile…

Pytje
Faleminderit…!

Modelet e procesit për zhvillimin e softuerit
(linear, iterative, agile)
R a m i z H OX H A
2020/2021

Projekti i Softuerit
❑Një projekt është një grup i veprimeve të planifikuara dhe të realizuara nga
një grup njerëzish për të arritur një qëllim të caktuar, duke u kufizuar nga një
afat-kohor, dhe ka një kosto të caktuar.
❑Për të menaxhuar një projekt është e nevojshme të:

▪ Përcaktoni metodologjinë e zhvillimi të softuerit.
▪ Menaxhoni njerëzit e përfshirë
▪ Menaxhoni kufizimet teknike
▪ Menaxhoni mjetet e disponueshme …

❑Metodologjia e Zhvillimit të Softuerit - është korniza e përdorur për të planifikuar,
kontrolluar dhe strukturuar procesin e zhvillimit të sistemit softuerik.
❑Gjithashtu quhet:
▪ Cikli i jetës për zhvillimin e softuerit
▪ Procesi i zhvillimit të softuerit
❑Përfshine aktivitete, qëllimi i të cilave është zhvillimi ose përmisim i softuerit.
❑Aktivitetet e përgjithshme në të gjitha proceset e softuerit
▪ Specifikimi/Analiza (Definimi i kërkesave të sistemit dhe përdoruesit).
▪ Dizajnimi (Dizajnimi i arkitektures, programit, GUI, etj).
▪ Zhvillimi (Kodimimi i sistemit)
▪ Validimi (Testimit dhe Miratimi)
▪ Evuluimi (Mirmbajtja dhe Zbatimit/Dorzimi)

Specifikoni
Kërkesat e Produktit
Produktin
Specifikoni
Kërkesat e Softuerit
Softuerin
Krijoni
Dizajni i Nivelit të Lartë
Arkitekturë sw
Dizajno
Modulet
Dizajni i Nivelit të Ultë (detajuar)
Implemtimi Kodi Burimor

(kodimi)
Procesi i softuerit është një grup aktivitetesh që
Testimi &
ndërlidhet me ndërtimit e softuerit. Validimi
Sistemi i Ndertuar
Zbatimi (Instalimi)
Këto aktivitete përfshijnë zhvillimin e produktit softuerikë & Mirmbajtja
nga fillimi e deri në përfundim.
❑Megjithatë, një process softuerik përfshin gjithashtu përshkrimin e procesit i cili
përfshin:
▪ Produktet: rezultatet e një aktiviteti. p.sh, Specifikimi i Kërkesës për
Softuerin (SRS) ndoshta një model për arkitekturën e softuerit.
▪ Rolet: përgjegjësitë e njerëzve të përfshirë në proces. p.sh, menaxheri i
projektit, programuesi, etj.
▪ Kushtet para dhe pas: kushtet që duhet të jenë të përfshira para dhe pas
një aktiviteti.
o p.sh, kushtet paraprake të dizajnit arkitekturor janë kërkesat e miratuara nga klienti,
ndërsa gjendja pas është diagramet që përshkruajnë arkitekturën që janë shqyrtuar.

❑Cikli i jetesës së softuerit:
▪ Përcakton të gjitha fazat e zhvillimit të softuerit, duke filluar nga specifikimet e
kërkesave të klientit, deri në fazat e fundit të krijimi i softuerit.
❑Këto faza janë të organizuara sipas modeleve që drejtojnë (guide)

inxhinierin në aktivitetet e tij.
▪ Modelet Lineare (Linear models)
▪ Modelet Përsëritëse (Iterative models)
▪ Modelet Rritëse (Incremental models)
▪ Modelet Adaptive (Adaptive models)
▪ Modelet Ekstreme (Extreme models)


❑Modeli Linear
▪ Aktivitetet ose fazat e varura që janë ekzekutuar në një mënyrë sekuenciale duke mos ofruar
ciklin e regimit (feedback).
▪ Zgjidhja ofrohet vetëm në fazën finale (përfundimtare).
▪ Qëllimet, kërkesat dhe zgjidhjet e definuara mirë, ofrojnë shumë-pak ndryshim për
kërkesat e fushëverpimit të projektit.
Modeli Linear-Sekuencial
▪ Modeli linear-sekuencial referohet gjithashtu si Modeli

Ujëvara i cili është shumë i thjeshtë për tu kuptuar dhe
përdorur.
▪ Në këtë model (modeli ujëvarës) secila fazë duhet të

përfundojë para se të fillojë faza tjetër dhe nuk ka
mbivendosje (overlapping) të fazave.

❑Modeli Rritës (Incremental)
▪ Njësoj si modeli linear, përveç se për secilen fazë (iteracion) lëshohet (ofrohet) një zgjidhje e
pjesshme ose deliverable.
▪ Këto iteracione janë zakonisht komplimente për njëra-tjetrën. Pasi të kemi përfunduar të gjitha
iteracionet, produkti është i plotë.
▪ Qëllimet, kërkesat dhe zhvillimi është bërë korrekt pa pasur nevojë të e kthehemi
mbrapa,(orar më agresiv.)
▪ Qasje rritëse me e dobishme në krahasim me atë
sekuenciale, veçanërisht kur madhësia e projektit nuk
është e vogël.
▪ Minimizon rrezikun pasi secili inkrement (iteracion) mund
të ofrohet në 2-3 muaj.
▪ Ciklet e shkurta të rritjes përmirësojnë bashkëpunimin e
klientit me ate të zhvillimit (zhvilluesit).
▪ Ofron produktin final në formë të komponenteve (builds).

Modelet e zhvillimit të Softuerit…
❑Modeli Përsëritës (Iterative)
▪ Fazat përsëriten, kemi mundesi feedback’ut pas përfundimit të secilit iteracion.
▪ Në fund të iteracionit mund të rezultoj me një zgjidhje të pjesshme ose përfundimtare.
▪ Qëllimet e definuara mirë, jo të gjitha funksionet
(karakterisitikat) e njohura, strategjia learn-by-doing
▪ Aftësia për t’i përfshirë ndryshimet në çdo iteracion
▪ Iteracionet e vogëla ofrojnë bashkëpunim me të shpeshtë me
klientin në fund të çdo iteracioni.
▪ Ofron verzione dhe feadback më të hershëm mbi produktin, zbut
rrezikun e hendekut në pritjet e klientit dhe të kuptuarit të ekipit të
zhvilluesve.
▪ Feadback (Reagimet) përdoren për të rishikuar prioritetet e projektit
dhe për të bërë ndryshime në kërkesat, funksionalitetet, planifikimet,
risurce,
Një qasjeetj.
iterative më e dobishme krahasuar me qasjen rritëse, posaçërisht kur
kërkesat e projektit pritet të ndryshojnë shumë
Rritëse vs Përsëritës (Incremental vs Iterative)
Incremental
Iterative

Rritëse & Përsëritës (Incremental & Iterative)…

An Iterative Waterfall Isn’t Agile


❑Metodologjitë e zhvillimit të softuerit:
o Ad-hoc
o Waterfall / Ujëvarës
o Prototyping / Prototipit
o V-Model
o Spiral
o RAD
o Unified Process / Procesi i Unifikuar
o Agile/i Shkathët

Metodologjia Ad-hoc (Big Bang)
❑Në mënyrë tipike, “nuk konsiderohet” një lloj i metodologjisë!
▪ Klienti shpreh nevojat e tij, dhe zhvilluesi thjesht bën punën!
❑Përparsi:
▪ E thjeshtë dhe e drejtpërdrejtë
▪ E përshtatshme për sisteme të vogla dhe të thjeshta
❑Mangësi: Një problem i madh nëse:

▪ Klienti nuk i shpreh saktë nevojat e tij.
▪ Zhvilluesi nuk di si të procedojë me implementimin
▪ ... dhe kjo nuk ka mbështetjen e ndonjë ndryshimi në kërkesat

Metodologjia Waterfall / Ujëvarës
❑Model linear
▪ Testimi bëhet pasi kodi të zhvillohet plotësisht
❑ Përparsi
▪ Kërkesa është e qartë para se të fillojë zhvillimi (kodimi)
▪ Secila fazë përfundon në një periudhë specifike kohore.
▪ Si model linear, është i lehtë për tu zbatuar
▪ Secila fazë rezulton me një dokumentim përkatës të duhur
❑ Mangësi:
▪ Mund të shfaqen probleme kur kalojmë nga një faza në tjetren.
▪ Nuk është fleksibil dhe nuk mbështet ndonjë ndryshim të kërkesave
▪ Klienti e sheh produktin pasi të mbarojnë të gjitha fazat.

Metodologjia e Prototipit
❑ Metodologjia e Prototipit ofron një version inicial të një prototipi
të aplikacionit
▪ Simulon vetëm disa aspekte të produktit përfundimtar dhe mundesi për
të identifikuar problemet dhe zgjidhjet e mundshme.
❑ Përparsi
▪ Përfshirje më e madhe e përdoruesve/klienteve në produkt, para
implementimit të tij.
▪ Përdoruesit/klientet e kan më të qartë se çfare do të ofroj softuerit
që po zhvillohet.
▪ Ulet koha dhe kostot pasi që defektet mund të identifikohen shumë më
herët.
▪ Feedback më të shpejta nga përdoruesit që rezultojn në zgjidhje më
të mira.
▪ Funksionet që mungojnë ose ato konfuze apo të vështira mund të
identifikohen lehtësisht.
▪ Ide të reja për dizajnim/funksione.

Metodologjia e Prototipit…
❑Mangësi:
▪ Rreziku i analizës të pamjaftueshme së kërkesave për shkak të varësisë shumë nga
prototipi.
▪ Përdoruesit mund të ngatërrohen me prototipet dhe sistemet reale.
▪ Praktikishtë, kjo metodologji mund të rrisë kompleksitetin e sistemit pasi qëllimi i
sistemit mund të zgjerohet përtej planeve origjinale.
▪ Zhvilluesit mund të përpiqen të ripërdorin prototipet ekzistuese për të ndërtuar
sistemin e vërtetë, edhe kur nuk është teknikisht i realizueshëm.
▪ Investimet në prototip mund të jetë larta nëse nuk kontrollohet si duhet.

Metodologjia e Modelit-V
❑Versioni i modifikuar i metodës së ujëvarë (modeli linear)
▪ Fazat janë pasqyruar për të verifikuar dhe validuar secilen prej tyre.
▪ Testuesit dhe zhvilluesit punojnë paralelisht, test Rastet përgatiten për secilen faze.
❑ Përparsi
▪ Njëjt si ujëvara + testuesi është i përfshirë nga faza e
kërkesës.
❑ Mangësi:
▪ I ngurtë
▪ Nëse ndryshimet ndodhin në mes të rrugës, jo vetëm
dokumentacioni i kërkesave, por edhe
dokumentacioni i testimit duhet të ndryshohet
▪ Nuk është i përshtatshëm për projekte afatshkurtra
pasi kërkon rishikime në secilën fazë

Metodologjia Spiral-e
❑ Modeli linear dhe rritës + Prototipi
▪ Focus në vlerësimin e rrezikut
▪ 4 faza kryesore:
o Percaktimin e Objektivave, Analizon Rreziqet,
Inxhinieria (dizajn, kodim, testim) dhe Planifikimi.
▪ Modeli spiral është i favorizuar për projekte të
mëdha, të shtrenjta dhe të ndërlikuara
❑ Kur të përdorim modelin spiral:
o Kur vlersohet kostoja dhe rreziku është i rëndësishëm.
o Kur krijimi i një prototipi është i përshtatshëm
o Kërkesat janë komplekse
o Projeket kosiderohen ne rrezik nga niveli mesëm në të
lartë
o Priten ndryshime të rëndësishme/të mëdha
o Përdoruesit janë të pasigurt për nevojat e tyre

Metodologjia Spiral-e…
❑Përparsi:
▪ Sasi të lartë të analizës së rrezikut.
▪ Feedback të hershme dhe të shpeshta nga përdoruesit si rezultati i perdorimeve te
prototipeve
▪ Softueri ofrohet në fazat e hershme
❑ Mangësi:
▪ Mund të jetë i kushtueshëm
▪ Analiza e rrezikut kërkon ekspertizë shumë specifike
▪ Nuk është adekuat për projekte të vogla

Metodologjia RAD: Rapid Application Development
❑RAD: Zhvillimi i shpejtë i aplikacionev (Iterative, incremental dhe adaptative)
▪ Përdor planifikim minimal në favor të prototipeve të shpejta.
❑Mbledh kërkesat e klientëve përmes:
▪ Workshops ose fokus grupeve
▪ Testimi i hershëm i prototipeve duke përdorur konceptin përsëritës
▪ Ripërdorimi i prototipave ekzistues
▪ Integrimi i vazhdueshëm.

Metodologjia RAD: Rapid Application Development…
❑Projekti mund të ndahet në module të vogla ku çdo modul mund të caktohet në
mënyrë të pavarur ekipeve të veçanta.
❑Kur përdoret Metodologjia RAD?
▪ Kur një sistem duhet të prodhohet në një kohe të shkurtër (2-3 muaj)
▪ Kur dihen kërkesat
▪ Kur përdoruesi do të përfshihet gjatë gjithë ciklit jetësor të projektit
▪ Kur rreziku teknik është më i vogël
▪ E zbatueshme për sistemet modulare
▪ Kur një buxhet është mjaft i lartë për të përballuar dizajnuesit për
modelim së bashku me koston e mjeteve të automatizuara për
gjenerimin e kodit.

❑PU – model Iterative dhe incremental, i drejtuar në USE CASE dhe i orientuar ne
arkitekturen e sistemit.
1) Inception (Zanafilla), ka për qëllim të vendos këkesat e biznesit për sistemin. Gjatë kësaj faze
identifikohen entitetet e jashtme (njerëzit dhe sistemet) që do të ndër veprojnë me sistemin që po e
ndërtojmë
2) Elaboration (Elaburimi), ka për qëllim të kuptuarit e problemit, krijimin konceptual të arkitekturës së
sistemit dhe krijimin e planit të zhvillimit.
3) Construction (Ndërtimi), është fazë ku dizajnohet, programohet dhe testohet sistemi
4) Transition (Trazicioni) është faza finale e RUP ku produkti kalon në shfrytëzim (deployed)

❑ Inception (Zanafilla): 10% kohës, 5% përpjekje (Effort).
▪ Ndihmon për të përcaktuar fizibilitetin e projektit dhe çfarë
dëshiron konsumatori.
▪ Identifikimi e funksioneve kryesore të sistemit
o Një modelim fillestar të Use Case’es (10-20% të sistemit)
o Një ose disa prototipa.
❑ Elaboration (Elaburimi) : 30% kohës, 20% përpjekje (Effort)
▪ Definon dhe përcakton arkitekturen në bazë të aplikacionit
▪ I kuptojm më thell kërkesat
o Modelim të plotë të 80% Use Casave.
o Përcaktojm kërkesta Jo-Funksionale
▪ Përshkrimi i arkitekturës së softuerit
▪ Prototipi arkitektonik i ekzekutueshëm

Metodologjia UP (Procesi i Unifikuar)…
❑ Construction (Ndërtimi): 50% kohës, 65% përpjekje (Effort).
▪ Iterativisht kompleton zhvillimin/kodimin e plotë të
produktit.
▪ Integron aplikaciomin në platforma adekuate
▪ Ofron manuale te përdorimit.
❑ Transition: 10% kohës, 30% përpjekje (Effort).
▪ Dorzon produktin (aplikacionin) te klienti/përdoruesi
▪ Ralizon testimin Beta për të vërtetuar sistemin e ri
kundrejt përvojës së përdoruesit
▪ Trajnimi i përdoruesve dhe mirëmbajtësve

Metodologjia Agile
❑Grupi i metodave të zhvillimit të softverit
❑Bazuar në zhvillimin përsëritës+rritje
❑Fraza më të rëndësishme:
▪ ekipe vetë-organizuese, ndër-funksionale
▪ planifikim adaptues,
▪ zhvillimi evolucionar dhe dorzim (delivery),
▪ Një qasje përsëritëse (iterative), bllok-kohe (time-
boxed), e orientuar drejt njerëzve dhe e përqendruar
në rezultat,
▪ dorzimi i softverit në mënyrë graduale
▪ reagim (feedback) i shpejtë dhe fleksibël ndaj
ndryshimeve.
❑Një kornizë konceptuale

❑Metodologjia e Agile thekson 4 vlera dhe 12 parime për zhvillimin e softuerit.

Nga 4 vlerat e Agile rrjedhin 12 parimet e mëposhtme

❑ Benefitet:
▪ Fokusim ne Perdorues – Tregim të Perdoruesit me fokus biznisor duke determinuar kriteret e pranimit për
karakteristikat/funksionet e produktit/aplikacionit.
▪ Fokusim në vlerën e Biznesit- dorzimi i pjese së aplikacioni (funksioneve) që ofron vlere biznisore bazuar
në rëndesine e biznesit të klientit.
▪ Përmirëson Cilësinë - fokusohet në cilësi të lartë të zhvillimit, testimit dhe bashkëpunimit duke e ndarë
projektin në njësi të menaxhueshme.
▪ Transparenca - mundësi që klientët të përfshihet dhe të monitorojnë gjatë gjithë proceseve në projekt.
▪ Dorëzimi i hershëm dhe i parashikueshëm - shërbime, produkte ose funksione të reja të cilat dorëzohen ne
orar fiks sipas Sprintave.
▪ Parashikim të kostos dhe orarit- orar-fiks, klienti mund të kuptojë koston e përafërt të secilit funksion,
prandaj përmirëson vendimmarrjen, jep përparësi funksioneve dhe rendesin për iteracione shtesë.
▪ Lejon ndryshimin -Ekipet bëjnë ndryshime në mënyrë që të përmirësojnë funksionet dhe efektivitetin.
Ndryshimet mund të alokohen ne iteracionin e ardhshem.
▪ Inkuadrim i palëve të interesuara. Palët e interesuara dhe zhvilluesit punojnë ngushtë çdo ditë.

Pyetje
Faleminderit…!

Agile dhe Korniza SCRUM
R a m i z H OX H A
2020/2021

Çështje (Arsyje) për Agile
❑ Si dështojnë projektet
▪ Dorëzimi me vonës
▪ Dorëzimi mbi buxhetin
▪ Dorëzimi i gjërave të gabuara
▪ E paqëndrueshme në rrethinen e zbatimit (production environment)
▪ Të kushtueshme për tu mirëmbajtur

Çështje (Arsyje) për Agile
❑Pse Projektet Dështojnë
“Sa më vonë të gjejmë një defekt, aq më e shtrenjtë është ta rregulloni! ”
Implementimi Testimi Dorzimi &
Analiza Dizajni
(kodimi) (Validimi) Mirmbajtja
Procesi në projektet tradicionale
❑Raliteti shfaq:
▪ Project plans are “wonderful”!!?
▪ Rregullimet & supozimet bëhen gjatë analizës,
dizajnit, kodit
▪ Zhvillohet ri-planifikimi
▪ Shembull: Faza e testimit në fund
o Testuesi ngjen një defekt
o Programuesi pretendon se ai ndoqi specifikimet
o Arkitekti fajëson analistin e biznesit etj.
o Kosto eksponenciale.

Çështje (Arsyje) për Agile…
❑Një profeci e vetë-përmbushjes
❑Procesi tradicional i pirë për të minimizuar kostot e ndryshimit
▪ Plani i projektit
▪ Specifikimi i kërkesave
▪ Dokumente të nivelit të lartë të dizajnit
▪ Dokumente të nivelit të ulët të dizajnit
▪ Ideja: Specifikoni gjithçka, pastaj ekzekutoni
▪ Ky proces mund të shkaktojë kosto eksponenciale të ndryshimit
❑Një profeci vetë-përmbushëse
✓ Kjo ka kuptim për një urë, anije ose një ndërtesë, por
▪ softueri (dhe Lego) ndryshohen lehtë!

Si metodat Agile i adresojnë rreziqet e projektit
❑Jo-më dorzime me vones dhe mbi buxhet
▪ Përsëritje të vogla
▪ Lehtë për të llogaritur buxhetin
▪ Së pari kërkesat me prioritet të lartë
❑Jo-më dorzime të produktit të gabuar
▪ Komunikim i ngusht me palët e interesuara
▪ Ciklet e shkurtra të feedback-ut
❑Jo-më i paqëndrueshm (jo-stabile) në zbatim (rrethine e dorzimit)
▪ Dorzim/zbatim në secilen iteracion (sprint)
▪ Shkallë e lartë e automatizimit
❑Jo-më i mirmbajtje të kushtueshme.
▪ Mirmbajtja fillon me Sprint 2
▪ Mirëmbajtja e versioneve të shumta gjatë zhvillimit

Metodologjia Agile
❑Çfarë ofron metodologjia Agile (shkathët)?
❑Me Agile ju ndertoni produktin që klientët me të vërtetë e kërkojn (duan).
▪ Duke ralizuar produktin në form incrementale – përdorim të cikleve të shkurtër (“sprints").
▪ Çdo cikël përfshin dizajni, kodimin/zhvillimin, testimin dhe zhbatimin (deploment).
▪ Klienti apo palet-interest e shohi rezultatet e secilit sprint dhe ofroj feedback (reagime).
▪ Në sprinti e radhes ekipi ripërpunon produktin dhe prezenton përseri në fund të sprintit.
Si i tillë, zhvillimi i Agile

është një proces i
vazhdueshëm.

Fundamentals of Agile & SCRUM
❑Agile i referohet një grupi “metodash dhe praktikash të
bazuara në vlerat dhe parimet e shprehura në Manifestin Agile”, i cili
përfshin gjëra të tilla si:
▪ bashkëpunimi, vetë-organizimi dhe funksionaliteti i
tërthortë (ndër-funksionale) i ekipeve.
❑SCRUM është një kornizë që përdoret për të zbatuar

zhvillimin e Agile.
▪ Ekipet që përdorin kornizat e Agile si SCRUM reagojnë më
shpejt dhe i përgjigjen më saktë ndryshimit që mund të
paraqitet.
▪ Dhe duke u fokusuar, bashkëpunuar dhe komunikuar, ekipet
mund të arrijnë atë që me të vërtetë duhet të bëhet - së
bashku.

The Agile Manifesto
❑Metodologjia e Agile thekson 4 vlera dhe 12 parime (principe) për zhvillimin e softuerit.

Nga 4 vlerat e Agile rrjedhin 12 parimet (principet) e mëposhtme

Fundamentals of Agile & SCRUM
❑Theks të veqant në:
▪ Zhvillim përsëritës (Iterative) & rritës (incremental)
▪ Relaximi (flexibilitet) në menaxhim dhe dokumentim, planifikim adaptues
▪ Komunikim i shpeshtë me përfaqësuesit e klientëve
▪ Puna organizohet përmes "tregimeve të përdoruesve” (user stories)
▪ Ciklet e shkurtra bllok-kohe (time-boxed) të zhvillimit (sprinta me 15-30 dite).
▪ Fokusi në rezultat dhe qualitet
▪ Adoptim i praktikave më të mira.
❑ Kompanitë që kanë miratuar një kornizë të shkathët si Scrum raportojnë përfitimet e

mëposhtme:
▪ Rritje të aftësis së menaxhimit në ndryshime të prioriteteve
▪ Shikim (visibility)më e mirë në projekte
▪ Më shumë harmonizim midis biznesit dhe TI (sistemeve)
▪ Koha më e shpejtë në treg. (Faster time to market)

Perdorimi i metodave Agile

SCRUM
❑ SCRUM është një framework me qasje Agile që përdoret në zhvillimin e softuerit.
❑Me Scrum, një ekip organizohet në 3 role specifike:
▪ Product Owner (PO), Scrum Master (SM) dhe pjesën tjetër ekipi i zhvillimit.
▪ Ekipi e ndan ngarkesën e saj

të punës në afate të shkurtra
kohore të quajtura sprinte.
▪ Çdo sprint zgjat dy javë ose

një muaj

SCRUM…
❑Scrum zbaton parimet e Agile si një bashkësi e artefakteve, praktikave dhe
roleve dhe parimeve.
▪ Korniza e punës së scrum-it përcakton: 3-role, 5-ngjarje(ivenëte), 3-artifakte (objekte), dhe 6-
principe (parime).

rrjedha e punës në kornizën e SCRUM-it

Ekipi i SCRUM-it
❑I gjithë ekipi i përfshin në SCRUM

Ekipi i SCRUM-it…
Product Owner (PO)
❑Përgjegjësitë
▪ Ralizimi e vlerës së produktit.
▪ Komunikim me Klientin
o Punon me palët e interesit për të kuptuar nevojat e tyre dhe të
krijoj një Vizion dhe Product Backlog që synon të arrijë Vizionin.
o Personi i kontaktit për ekipin
▪ Product Backlog
o Tregimet e Përdoruesit
o Prioritetet
▪ Kriteret e Pranimit & Testet

Ekipi i SCRUM-it…
Scrum Master(SM)
▪ Scrum Master nuk ka përgjegjësi për dorëzimin (delivering) e projektit .
❑ Përgjegjësitë
▪ Scrum Master është një fasitator, mentor, trajner i anëtarëve të ekipit.
▪ Organizoni takimin ditore (daily meeting) në këmbe dhe pjesëmarrs në të gjitha takimet e
Scrum-it
o Fasiliton dhe moderon Planifikimin e Sprintit, Scrum-et ditore, Reviews e Sprint dhe Takimet
Retrospektive
▪ Krijoni Task Board dhe Sprint Burndown Chart në fillim të çdo Sprinti
o Asiston PO me product Backlog
▪ Largon bllokimet - ndihmoni ekipin të qëndrojë i përqendruar në detyrat që duhet të bëhen
gjatë çdo iteracioni (sprinit)
▪ Zbaton praktikat dhe parimet e Scrum’it - sigurohuni që puna të mos ngadalësohet.

Ekipi i SCRUM-it…
Zhvilluesit DevT (pjesa e tjeter e ekipit)
▪ Ekipi i zhvillimit janë njerëzit që e kryejnë punën.
❑Karakterestika e ekipit të zhvillimi në Scrum:

▪ Ekip vetë-organizuese, kërkohet për të konvertuar Product Backlog në Inkrement.
▪ Ekip ndër-funksional, me aftësi të ndryshme të nevojshme për të krijuar Inkrement të
produktit.
▪ Nuk ka nën-ekipet në DevT, ata mund të formohet nga fusha si testimi, analiza e biznesit,
progrmer, apo arkitekt i softuerit.
▪ DevT si i tëri kan përgjegjësi në projekt, jo anëtarët individualisht.
▪ Cilësitë thelbësore - Programim në dysh, TDD (Unit test të automatizuara), Vetë-motivues (nuk
ka hirarki sinior-junior. Ekipi i tërë duhet të punojë vetë), punon për ekip (team player).

Ekipi i SCRUM-it…
Zhvilluesit (pjesa e tjeter e ekipit)
▪ Ekipi i zhvillimit janë njerëzit që e kryejnë punën.
❑Përgjegjësitë:
▪ Performon ekzekutimin e Sprint’it – kryen detyrat e dizajnimit, programimit, integrimit dhe
testimit te artikujve të Product backlog në Inkremente.
▪ Inspekon dhe Adapton – në Scrum’in ditore inspekton progresin drejt qëllimit të sprintit dhe
përsht planin për punën e ditës aktuale. Po ashtu në fund të secilit sprit përfshihet në
aktivitetet e inspektimit për review të sprintit dhe retrospektiven e sprintit.
▪ Kujdeset për Pruduct backlog – përfshin krijimin dhe rafinimin, vlerësimin, dhe prioritizon
artikujt e product backlog’ut.

Product Backlog në SCRUM
❑Product Backlog: https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/product-backlog/example
▪ është një listë e renditur e karakteristikave (features-përshkrime të shkurtra) që

nevojiten, pjesë e produktit final.
▪ Këto mund të jenë [tregimet e përdoruesve], bugs fixes, vetit jo-funksionale, etj.

Kërkesat në SCRUM
❑Në Scrum, kërkesat shpesh definohet si tregime të përdoruesit (user stories):
“Si [Lloji i përdoruesit], une dua qe [Funksion] në mënyrë që [ arsyja]”
❑Kërkesat duhet të përmbushin vetitë e INVEST:

▪ I – Independent (pavarur)
▪ N – Negotiable (I negociueshem)
▪ V – Valuable (i vlershëm)
▪ E – Estimable (i llogaritshëm)
▪ S – Small ( i vogël)
▪ T – Testable (i testueshëm)

Sprint Planning Meeting në SCRUM
❑Definon/krijon Sprintin
▪ Vlersohen artikujt (features) e Backlog
▪ Lëvizni artikujt nga Produkti në Sprint
Backlog
❑Definohet Puna
▪ Ndan/zberthen features ne tasks (detyra)
▪ PO nuk është e domosdoshme të jetë prezent
❑Koha totale: 2 orë në javë të Sprintit
❑ A sprint planning meeting zhvillohet përpara
fillimit të një sprintit.
▪ Qëllimi i këtij takimi është të përcaktojë planin e sprintit dhe
të vendosë një qëllim (goal) të sprintit
▪ Gjatë takimit të planifikimit të sprintit, PO përshkruan features
me prioritet më të lartë te të gjithë ekipi.

Tasks (detyrat) në SCRUM
❑Për një planifikim më të mirë, tregimet ndahen/zberthehen në detyra
❑Tasks should be SMART: ❑ Example: In order to easily be able to follow my friends' tweets,
▪ S – Specific ❑ User storie as <a registered user>, I want <to automatically follow all of my
▪ M – Measurable gmail contacts> that have twitter accounts.
▪ A – Achievable ❑ Your tasks might be:
▪ R – Relevant ▪ Add an option to the menu
▪ T – Time-boxed ▪ Add a new gmail authentication screen
▪ Add a twitter authentication screen
▪ Add a contact selection screen
▪ Add a controller that calls into your service layer
▪ Save contacts to the database
▪ Modify your existing gmail API calling service to get contacts
▪ Add a twitter API calling service to follow selected contacts

Sprint Backlog në SCRUM
❑Sprint Backlog:
▪ është një listë e detyrave të identifikuara nga ekipi i Scrum që do të
kryhen gjatë nje sprintit.
▪ Gjatë takimit të planifikimit të sprintit, ekipi zgjedh një numër të features
nga Product Backlog
▪ zakonisht në formën e tregimeve të përdoruesve, dhe identifikon detyrat
e nevojshme për të përfunduar çdo tregim të përdoruesit.
Shumica e ekipeve gjithashtu vlerësojnë

se sa orë do të marrë secila detyrë për të
kryer dikë në ekip.

p.sh, detyra e krijimit të
bazës së të dhënave ndahet
në detyrat e mëposhtme.
Sprint Backlog:
lista e kërkesave(artikujëve) që-duhët ralizuar
p.sh, detyra e krijimit e faqes

së qasjen (ndahet në detyrat e
mëposhtme.)
Ramiz HOXHA & Fisnik PREKAZI © 2018 UBT 27

Daily Scrum Meeting
❑What is a Daily Scrum?
▪ Duration: About 15 minutes
▪ Participants: Scrum Master, the Scrum Team and Product Owner
▪ Status update: Last achievements, Next steps, and Problems
❑Rule and Guideline:

▪ Start of a working day at the same time and place
▪ The Scrum Master serves as a facilitator in the meeting
▪ The meeting is held with the whole team standing up so as to not prolong the meeting more
than 15 minutes
▪ Each member of the Scrum Team is expected to answer the three questions mentioned above
▪ Each member of the Scrum Team should take no more than 2 to 3 minutes to answer the
above questions

Sprint Review Meeting në SCRUM
❑Acceptance of Features
▪ Demo to PO
o PO should be prepared
o Optional: invite other stakeholders
▪ Comments by developers
❑Attendees include:
▪ the Scrum Team and key stakeholders invited by the Product Owner;
▪ The PO explains what Product Backlog items have been “Done” and what has
not been “Done”;
▪ The Developers discuss what went well during the Sprint, what problems it
ran into, and how those problems were solved;
▪ The Developers demonstrate the work that it has “Done” and answers
questions about the Increment;
▪ The Product Owner discusses the Product Backlog as it stands.

Retrospective Meeting në SCRUM
❑Internal team evaluation
▪ PO not required
▪ Discuss process and problems
▪ Measure improvements

Product Increment në SCRUM
❑Potentially shippable increment
▪ Complete according to Definition of Done
o Even if not actually released
▪ No regrets if project ended now

Burn-down Chart ne SCRUM
❑Grafiku e burn-down matë punën e përfunduar në projekt gjatë një afati
kohor.
▪ pastaj krahasoet me kohën në dispozicion për të përfunduar projektin.

Kohe-zgjatja e Takimeve ne SCRUM
❑Takime të shpeshta a rezultojn në “humbje të kohes”!!
fig. ngjarjet në Scrum dhe koha e ralizimit për secilën ngjarje

Fig ..:shembull të bordi i detyrave (taksave) të Sprint
(b)
(a)
Struktura e tregimit të përdoruesit (user stories):
As a [Type of User],
I need [Function to Perform]
so that [Business Value]
Si [Lloji i përdoruesit], më duhët [Funksioni për të kryer] në mënyrë që [Vlera e biznesit]
p.sh: Si blerës librash, më duhët të paguaj duke përdorur kartën time të kreditit, në mënyrë që unë mund të blejë një libër të zgjedhur.

Pyetje
Faleminderit…!

Inxhinieria e kerkesave (Definimi i Product-backlog) SCRUM
R a m i z H OX H A
2021/2022

Inxhinieria e Kërkesave
❑Inxhinieria e kërkesave është termi i një spektër të gjerë të detyrave dhe teknikave
që çojnë në të kuptuarit e kërkesave.
Inxhinieria e
Kërkesave
Inxhinieria e Menaxhimi i
Kërkesave kërkesave
Nxjerrja Analiza Specifikim Validimi

Inxhinieria e Kërkesave…
❑Procesi i të kuptuarit të problemit që duhet zgjidhur, rezultateve që përfshin nevojat e
biznesit dhe çështjet teknike që e kufizojnë atë, quhet inxhinieri e kërkesave.
❑Inxhinieria e Kërkesave mund të përmblidhet si një grup aktivitetesh që siguron që një

ekip po ndërton produktin e duhur.
❑Ky proces përfshin ekip zhvilluesish ose inxhinierësh softuerësh, analistësh biznesi, klientë
dhe përdoruesit e fundit.

Analiza (Definimi) i Kërkesave
❑ Është e vështirë për të ndërtuar një zgjidhje nëse nuk i njihni 3 lloje të kërkesave:
▪ Kërkesat e biznesit
Inxhinieria e kërkesave është procesi i mbledhjes, verifikimit (validimit)
▪ Kërkesat përdoruesit dhe dhe menaxhimit të kërkesave thelbësore për zhvillimin e softuerit.
▪ Kërkesat sistemit
llojet e kërkesave

Analiza (Definimi) i Kërkesave….
❑Kërkesat e biznesit përshkruajnë nevojat e biznesit të nivelit të lartë, të tilla si rritja e
prezences në treg, përmirësimi i vlerës së jetës së klientëve.
p.sh: letësimi i qasjes në përzgjedhje të produkteve
❑Kërkesat e përdoruesit mbulojnë qëllimet e ndryshme që përdorues mund të arrijnë

duke përdorur produktin dhe zakonisht dokumentohen në formën e tregimeve të
përdoruesve, rasteve të përdorimit (use cases) dhe skenarëve.
p.sh: une si klient dua që të më mundsohet krijmi i një whishlistë
në mënyrë që të këthehem më vonë për të blerë ato produkte
❑Kërkesat e sistemit/softuerit përshkruajnë se si duhet të funksionojë sistemi për të
përmbushur kërkesat e biznesit dhe të përdoruesit. Ato përfshijnë kërkesa funksionale dhe
kërkesa jofunksionale.
p.sh: klienti klikon ne product e perzgjedhur, kliko add to cart
produkti shtohet ne liste me sasi dhe qmimt te produktit etj….

Analiza (Definimi) i Kërkesave…
❑Të gjitha modelet e përmbajnë aktivitetin e analizës së kërkesave
Fazat e modelit të ujëvarës(Waterfall) Modeli rritës - incremental
SCRUM

❑Qëllimi i fazës së analizës është që të kuptojmë realisht kërkesat e sistemit të “ri” dhe të
zhvillohet një sistem që trajton kërkesat “Ç’farë & Si”
❑Përcaktimi i kërkesave të softuerit/sistemit së bashku me:
▪ klientin,
▪ përdoruesin,
▪ menagjemnti etj.
1. Me i definu detyrat/shërbimet e që sistemi duhet ti ofrojë
2. Me i definu kufizimet ndër të cilat sistemi duhet të funksionojë
3. Me i definu caçet e sistemit.
❑Në mënyrë konsensuale dhe të kuptueshme për të dy palët
❑Kjo fazë përcakton funksionimin e sistemit prej perspektivës së
klientit/përdoruesit

Sfida e parë është gjetja e njerëzve/përsonave të duhur për të marrë pjesë në
identifikimin e kërkesave.
❑P.sh si:
– Menaxherët (managers)
– Përdoruesit (users)
– Idealisht, të gjitha palët kryesore të interesit (ideally, all key
stakeholders)
Sfida e dytë është grumbullimin dhe integrimin e informacioneve

Teknikat e grumbullimi i kërkesave
❑ Teknikat e grumbullimit të kërkesave mund të ndryshojnë nga njëri projekt në tjetrin.
▪ Ekzistojn teknikat e grumbullimit të kërkesave të dobishme për ju në një projekt, por mund të mos jenë aq
produktive në projektin tjetër ose në ndonjë kompani tjetër.
▪ Teknikat përfshijnë vizualizimi e kërkesave si bordet-tregimeve, prototipat, skenarët mund të dobishme për përdorues e
sistemit të por janë të varfura ne definimin e zgjidhjes teknike.
❑ Prandaj dobia e një teknikë përcaktohet nga nevoja e tij dhe benefitet që ofron në një projekt të veçantë.
❑ Disa nga teknikat e mbledhjes së kërkesave zakonisht përfshijnë:
o Intervista o Brainstorming
o Pyetësorët o JAD
o Obzervimi
o Fokus grupe
o Seminaret e faselituar
o Prototipimi o Analiza e dokumentacionit

Definimi i kërkesave në SCRUM

Definimi i kërkesave në SCRUM
❑ SCRUM është një metodë iterative joformale & Agile rritëse e zhvillimit të softuerit , e
përdorur për të menaxhuar produktin nga faza dizajnimit deri në përfundim.
▪Zhvillim produktit në Scrum dhe në sekuencal-
linear kërkesat trajtojnë shumë ndryshe.
▪Scrum i shikon kërkesat si një shkallë të
rëndësishme të lirisë ku ne mund të manipulojmë
për të përmbushur qëllimet tona të biznesit.

Teknikat e nxjerrjes së kërkesave në SCRUM
❑Kërkesat për një project bazuar në modelin Scrum janë mbledhur në Product Backlog dhe të
detajuar me anë të teknikave të zhvilimit-tregimeve apo tregimet e përdoruesit.
▪ Në Scrum, tregimet e përdoruesit veprojnë si kërkesa.
❑ Ka disa teknika që mund t'i përdorni për të nxjerrur tregimet e përdoruesve

Teknikat e nxjerrjes së kërkesave në SCRUM…
❑Metodat e mëposhtme mund të ndihmojnë Product Owner të nxjerr kërkesat apo
user stories (tregimet e përdoruesit).
Intervistat: Intervistojm grup të ndryshëm përdoruesish
ose përdoruesve të caktuar nëse produkti/shërbimi ende nuk
është implementuar.
Duke bëre pyetje të hapura-të-mbyllur me përmbajtje
“SI" ose “PSE".
Obzermvimet: Duke shikuar ose obzervuar njërzit duke

përdorur produktet ose shërbimet

Teknikat e nxjerrjes së kërkesave në SCRUM…
Prototipet: Përdorimi i mjeteve të tilla si shënimet ose kartat ngjitjes,
PowerPoint, dhe wireframes për të ilustruar idetë, tregojmë versionet
paraprake të produktit, dhe për të fasilituar diskutimet.
Sondazhet: Përdorimi i sondazheve kur product owner verbalisht i pyet të

anketuarit pyetje të paracaktuara ose pyetësorë ku shërbimet e
paraqiten nëpërmjet formularëve (online ose në format të
dokumenti).
Punëtoria/seminaret: Kjo është teknike e tipit si brainstorming ku grupi

identifikon sa më shumë ide të tregimit të përdoruesve.
Kjo formë mbështet nxjerrjes e një sasie sa me të madhe të ideve,
sugjerohet që pjesëmarrësit të mos pajtohen/nuk pajtohen ose
të vlerësojnë shërbimet gjatë punëtorisë.

Kërkesat në SCRUM…
❑Product Backlog:
▪ është një listë e renditur e karakteristikave (features; përshkrime të shkurta) që nevojiten,
pjesë e produktit final.
▪ Këto mund të jenë [tregimet e përdoruesve], bugs fixes, vetit jo-funksionale, etj.
Scrum uses placeholders for requirements

Kërkesat në SCRUM…
❑ekipet e definojn Artikujt e Product backlog’ut (PBI) si tregime të përdoruesit user stories):
“Si [Lloji i përdoruesit], une dua qe [Funksion] në mënyrë që [ arsyja]”
▪ Por ka edhe forma tjera ku disa ekipe preferojnë raste përdorimi (use cases), dhe të tjerët zgjedhin të
përfaqësojnë PBI-të e tyre në formatet e tyre të personalizuara
▪ Një tregim i mirë e përdoruesit është ai që përfshin një përshkrim dhe ka kriteret e pranimit të definuar.
▪ Me pak fjalë, tregimet e mira të përdorues zbatojn parimin INVEST.

Çka janë tregimet e përdoruesve
❑Praktik e zakonshme e definimit të Product Backlog’ut.
Tregim i përdoruesit është një mjet i përdorur në modelin Agile te zhvillimit të softuerit për të kapur
përshkrimin e një tipari (feature) të softuerit nga një perspektivë e përdoruesit.
Tregim i përdoruesit përshkruan llojin e përdoruesit, çfarë ata duan dhe pse,
Një Tregim i përdoruesit ndihmon për të krijuar një përshkrim të thjeshtuar të një kërkese.
Një shembull i thjeshtë i kësaj mund të jetë:
Si blerës në internet, unë dua të shtoj një artikull në shportën time,

në mënyrë që ta blej atë
Çka janë tregimet e përdoruesve…
❑Shablloni (template) i Tregimeve të përdoruesëve
Kush (roli i përdoruesit)
Çfarë (qëllimi)
Pse (arsye)
Tiitulli: Pagesa me anë të përdorimit të Kartës së Kreditit Priority (Prioriteti): 25
Si blerës librash, mund të paguaj duke përdorur kartën time të kreditit, kështu që unë mund të blejë një libër të zgjedhur.
Shënim: mbështetë viza, master, amex

Kufizimet: Duhet përdorur e-banking e bankës tuaj
Estimate: 13pts

❑Disa shembuj të Tregimeve të përdoruesëve:

❑Lista e kontrollit për Tregimin e Perdoruesit .
Mbajini të shkurtër
Bëni ato të thjeshta
Shkruani nga këndvështrimi i përdoruesit
Bëni të qartë vlerën / përfitimin e tregimit - cila është arsyeja e tregimit?
Përshkruani një pjesë të funksionalitetit. Nëse duhet ta shkruani dhe ta ndani në 2
tregime
Shkruaj tregimet si ekip
Përdorni kriteret e pranimit për të treguar një MVP (Minimum Viable Product)

Theme, Epic, User Stories dhe Tasks
❑Në mbledhim kërkesat si tema (theme) dhe epika (epic). Pastaj ndajmë këto
epike në tregime të përdoruesve (user stories) që mund të implementohen
në një Sprint të vetëm.
/ tasks
Product Backlog (PBIs),

Epic, User Stories dhe Tasks
❑Epics –TP/US janë si një overview e fetures së produktit. Përshkruaj tregime në nivelit
përgjithsimit të një tregimi, të zberthyera në tregime të vogla.
❑Tasks / Detyrat - pjesët e zbërthyera të një tregim që paraqet ‘SI’ do të ralizohet TP.
▪ Detyrat zakonisht definohen nga njerëzit që bëjnë punën (zhvilluesit, Testuesit, etj).

Tasks (detyrat) në SCRUM
❑Për një planifikim më të mirë, tregimet ndahen/zberthehen në detyra
❑Duhet të jëte SMART: P.sh: Në mënyrë që të mund të ndjek lehtësisht cicërimat (tweets) e miqve të mi,
▪ S – Specific Tregimi i përdoruesit:
▪ M – Measurable si një <përdorues i regjistruar>, unë dua që <automatikisht të ndjek (follow) të gjithë kontaktet
e mia të gmail’it> që kanë llogari në Twitter.
▪ A – Achievable
➢ Detyrat (tasks) tuaja mund të jenë:
▪ R – Relevant ▪ Shtoni një mundësi në meny
▪ T – Time-boxed ▪ Shto dritare e re per autetifikim ne gmail.
▪ Shto dritare e re per autetifikim ne twitter.
▪ Shto dritaren të përzgjedhjes së kontaktit
▪ Shtoni një kontrollues (controller) që thërret shtresën tuaj të shërbimit (service layer)
▪ Ruaj kontaktet ne baze te te dhenave.
▪ Modifikoni shërbimin API ekzistues të gmail’it për të marrë kontakte nga llogaria e gmail’it
▪ Shtoni një shërbim të thret API në Twitter për të ndjekur (follow) kontaktet e zgjedhura

Shembull: Theme, Epic, Tregime dhe Tasks në Agile
❑ Epic 1
▪ As a customer, I want to be able to wishlists so that I can return later
to buy shortlisted products.
▪ User Stories
o User Story 1
o As a customer, I want to be able to save a product in my wishlist so
that I view it again later
o User Story 2
o As a customer, I want to be able to view my wishlist so that I can buy items
from it.
❑ Epic 2
▪ As a customer, I want the ability to add items to my cart
page.
▪ User Stories
o User Story 1
o A user can add his/hers chosen items to the cart.
o User Story 2
o Users can remove unwanted items. from their cart

Shembull: Theme, Epic, Tregime dhe Tasks në Agile

Shembull: Epic, User Stories dhe Tasks…
Epic
User Stories

Çka janë Kriteret e Pranimit
❑Kriteret e Pranimit (Acceptance criteria)
Qëllimi i kritereve të Pranimit është të artikulojë saktësisht kur
tregimi e përdoruesit bëhet nga këndvështrimi i pronarit të
produkteve për të prodhuar testin e pranimit (acceptance tests).
Ekipi i Sigurimit të Cilësisë duhet t'i referohet atij për të shkruar

teste të pranimit për të konfirmuar nëse tregimi i përdoruesit është
në të vërtetë i duhur.
Eshtë përgjegjësia e pronarit të produktit të verifikojë nëse kriteret

e pranimit mbulojnë atë që pritet që tregim i përdoruesi është bërë
siç është ralizuar.

Çka janë Kriteret e Pranimit…
❑Shembull një Tregimi të përdoruesit me Kriteret e Pranimit:
As a Facebook user I want to Login so that I can be connected on my social network.

Accepted criteria
As a Facebook user I should be able to:
▪ See Login screen with username and password and a login button
▪ Login to Facebook account with correct credentials
▪ See error message if entered incorrect credentials
▪ etc

Çka janë Kriteret e Pranimit…
ID e Tregimit: STK001
Emri i Tregimit: Porosia e Kosumatorit
Përshkrimi: Si një Kosumator, dua të bëjë një porosi, më qëllim që të kem të dorzuar ushqimin në shtëpin time.
Konfirmimi: p.sh.; Kriteri i Pranimit (e.x: Acceptance Criteria):

Funksionale:
▪ A mund ta ruaj porosinë time dhe të kthehem më vonë?
▪ A mund ta ndryshoj porosinë time para se të paguaj për të?
▪ A mund të shoh një koston totale të së asaj që kam zgjedhur deri më tani?
Jo-funksionale: disponueshmëria:
▪ A mund të vendos një porosi në çdo kohë (24 orë në ditë ose 24/7/365)?
▪ A mund ta shoh porosinë në çdo kohë (24 orë në ditë ose 24/7/365) deri në duke përfshirë shpërndarjen)?
Jo-funksionale: siguria:
▪ A sigurohet që persona të paautorizuar dhe klientë të tjerë që nuk e shohin porosinë time?
3C-të e Tregimeve të përdoruesëve
❑Çka janë 3C-të (Card, Conversations and Confirmation) e tregimeve të përdoruesve:
▪ 3 C-të Kartela, Biseda dhe Konfirmimi janë, proces përmes të cilit Tregimet e Përdoruesit zberthehen dhe
përgaten ato për implementim.
▪ Karta (ideja fillestare e tipareve)
o Artikuj (Tregimi i përdoruesëve) nga backlog të shkuara në Karta ku përshkrimi i tyre është i thjesht dhe
mjaftushem laboron per nje kërkeses (feature) të sistemit.
▪ Biseda (diskutim në ekip për të arritur mirëkuptim të përbashkët)
o Kërkesat e hollësishme identifikohen vetëm pasi artikulli (feature) e backlog’ut të shtohet në një sprint. Ky
dialog bëhet ndërmjet pronarit të produktit dhe ekipit të zhvillimit.
▪ Konfirmimi ( Kriteret e Pranimit)
o Kriteret sigurojnë qe artikujt e backlog’ut të i plotësojn specifikat sipas pronarit të produktit. Konsumatori do
të vlerësojë PBI kundërej kritereve të pranuara, dhe nëse kalojnë të gjitha testet miratoni PBI deri në fund të
sprintit.
o Kriteret e pranimit përdoren për të përcaktuar kur tregimet e përdoruesit ka përmbushur qëllimin e
përdoruesit

3C-të e Tregimeve të përdoruesëve …
❑Mostra e një Karte të një tregimi të perdoruesit
Karta (card):
Si student, Unë dua te e paraqes provimin në afatin e prillit, në mënyrë që të me mundësohet hyj në provim.
Biseda (Convarsation):
Ekstrakt i takimeve të palëve të interest, is PO, BO the tjeret në lidhje me tregimi e përdoruesve
Zhvilluesi: Cilet student mund te e paraqesin provimi
Product Owner: Studenti qe ka ndjekur lenden dhe eshte i regjistruar.
. . . . . .
Konfirmimi / Kriteret e Pranimit (Confirmation / Accepted criteria):
Nëse Një student është i regjistruar
Dhe ka ndjekur ligjërata dhe nuk është i notuar paraprakish
Kur lista e lëndeve shfaqet nga sistemi
Dhe studenti përzgjedh lëndet duke klikuar në kutinë e zgjedhjes (checkbox)
Dhe ka zgjedhur max dy lënd te për afatin jo te rregull
Dhe studenti konfirmon duke shtypur butonin e OK.
Pastaj sistem shfaq (printon) listen e konfirmimit te provimeve që student ka studenti.

Pyetje
Faleminderit…!

Klasifikimi i Kërkesave: Funksionale & Jo-Funksionale
R a m i z H OX H A
20201/2022

Klasifikimi i kërkesave
❑ Kërkesat e biznesit.: Pikpamja e biznesit; pse është i nevojshëm projekti.
❑ Kërkesat e përdoruesit (palëve të interest ): Pikpamja e përdoruesit; çfarë u nevojitet përdoruesve për të bërë
ky sistem.
❑ Kërkesat e Sistemit: Pikpamja e sistemit; çfarë duhet të bëjë sistemi.
o Kërkesat jofunksionale NFRs përshkruajnë karakteristikat e përgjithshme të një sistemi, këto njihen gjithashtu si
atribute të cilësisë.
✓ NFRs janë edhe kërkesa operaacionale apo teknike
o Kërkesat funksionale përshkruajnë se si duhet të sjellet një sistem, cilat janë tiparet (features) dhe funksionet e tij.

Klasifikimi i kërkesave…
Mos harroni rregullin e artë: çfarë pret përdoruesi nga ky sistem?
Kerkesat Funksionale Kerkesat Jo Funcsionale

Funksionet (features) e produktit, Vetitë e produktit,
Përshkruan përvojën e përdoruesve. Sa e lehtë për t'u
Përshkruan veprimin e përdoruesve,
përdorur? Sa shpejt ekzekutohet?
Funksionet që mund të kapin në rastin Kufizimet globale që rezultojnë në koston e zhvillimit dhe
e përdorimit (use case), operimit.
Mund të shihet/identifikohet si modul
Është bazamenti i modulit të programit
individual i programit

shembull: kërkesat Funksionale
❑Çka duhët të bëj sistemi - përshkruan funksionet ose shërbimet e sistemit.
❑ p.sh;
▪ klienti duhet të ketë mundësi përmes internetit të procedoj një ‘transaksion bankarë’.
▪ përdoruesi duhet të ketë mundësi të ‘shfletoj listat e termineve’ për të gjitha klinikat”.
▪ sistemi duhet të gjenerojë çdo ditë, për çdo klinikë, listën e pacientëve dhe terminet cilët e kan
të caktuar atë ditë.
▪ secili anëtar i stafit që përdor sistemin duhet të identifikohet në mënyrë unike nga ID e puntori
me 8 shifra”.
Pjesa që definon
kërkesës funksionale

kërkesat Jo-Funksionale
❑Kërkesat Jo-funksionale
▪ Nuk kanë relacion direkt me kërkesat e përdoruesit
❑ Këto përcaktojnë vetitë dhe kufizimet e sistemit, p.sh. besueshmërinë, kohën e

përgjigjes (20 sec) dhe kërkesat për magazinimi e të dhënave (Server 2007 R2), etj.
❑ Menaxhimi i procesit mund të specifikohen gjithashtu duke mandatuar një IDE
(NetBeans) të veçantë, gjuhën e programimit ose metodën e zhvillimit.
❑Kërkesat jo-funksionale mund të ndikojnë në arkitekturën e përgjithshme të

një sistemi në përcaktimi e të komponentëve/module, teknologjise etj.
▪ P.sh, për të siguruar përmbushjen e kërkesave të performancës, ju duhet të organizoni sistemin
për të minimizuar komunikimin ndërmjet komponentëve/moduleve.

kategoritë e Kërkesave sipas: FURPS +
❑FURPS dhe FURPS+
▪ Functional (Funksionale): funksionet, shërbimet, siguria.
▪ Usability (Përdorshmëria): faktorët në përdorshmeri të njeriut, ndihma, dokumentacioni
▪ Reliability (Besueshmëria/Qendrushmeria): Frekuenca e dështimit, rikuperueshmëria,
parashikueshmëria
▪ Performance (Përformanca): kohët e përgjigjes, throughputi, saktësia, disponueshmëria,
përdorimi i risursëve
▪ Supportability (Mbështetja): Përshtatshmëria, mirëmbajtja, internacionalizimi, konfigurabiliteti
❑+
▪ Implementation (Implementimi): gjuhët dhe mjetet, hardueri, kufizimet e risurseve
▪ Interface (Interfasa): Interfaiset me sistemet e jashtme
▪ Operations (Operacionet): Menaxhimi i sistemit ku do të përdoret
▪ Packaging
▪ Juridike/legale

shembull: kërkesat jo-Funksionale
❑Si duhet t’i bëjë sistemi- përshkruan karakteristika ose atributet e cilësisë të sistemit.
❑ p.sh;
▪ klienti duhet të ketë mundësi përmes internetit të procedoj një transaksion bankarë
▪ përdoruesi duhet të ketë mundësi të shfletoj listat e termineve për të gjitha klinikat”.
▪ sistemi duhet të gjenerojë çdo ditë, për çdo klinikë, listën e pacientëve dhe terminet cilët e kan të
caktuar atë ditë.
▪ secili anëtar i stafit që përdor sistemin duhet të identifikohet në mënyrë unike nga ID e puntori me 8
shifra.
Pjesa që definon
kërkesën jofunksionale

Shembull:
kërkesat Jo-funksionale në sistemin Mentcare
Kërkesat në produkt
❑ Sistemi Mentcare do të jetë në dispozicion për të gjithë klinikat gjatë orëve të rregull të
punës (Hëne-Premte, 08:30-17:30). Downtime në orar e rregull të punës nuk duhet të kalojë
5 sec në asnjë ditë.
Kërkesa organizative
❑ Përdoruesit e sistemit Mentcare do të autethetikohet duke përdorur kartën e identitetit të
autoritetit shëndetësor.
Kërkesa e jashtme
❑ Sistemi do të zbatojë dispozitat për privatësinë e pacientit siç përcaktohet në HStan-03-
2006-priv.

Kërkesat e fushës/domain(operacionale)
❑Domeni operacional i sistemit imponon kërkesat në sistem.
▪ p.sh: Sistemi operativ (UNIX, Microsoft, Ubunto, etj), IDE, shpejtsia e procesorit, rrethina e zbatimit
të sistemit (p.sh MS SQL, Appachi, Microsoft ISS, HTTP Server…etj)
▪ p.sh; sistem i kontrollimit të trenave duhet të marrë parasysh karakteristikat e frenimit në
kushte të ndryshme atmosferike.
❑ Kërkesat e domain-it (fushës) janë kërkesa të reja funksionale, kufizime në kërkesat
ekzistuese ose përcaktimi i llogaritjeve specifike.
❑ Nëse kërkesat e domain (fushës) nuk janë të kënaqur, sistemi mund të jetë i
pazbatueshëm.
Kërkesat e domain-it pasqyrojnë mjedisin në të cilin sistemi funksionon/operon kështu, kur flasim
për fushë aplikacionit/sistemit, nënkuptojmë mjedise të tilla si operimi i trenave, të dhënat
mjekësore (e-health), e-commerce etj.

Kërkesat Funksionale vs joFunksionale
Kërkesat Funksionale Kërkesat Jo-funksionale
Ato definojn një sistem ose komponent te tij. Ato përcaktojnë atributin e cilësisë së një sistemi
Ato specifikojnë, "Çfarë duhet të bëjë sistemi?" Ato specifikojnë, "Si duhet t'i përmbushë sistemi kërkesat funksionale?"
Zakonisht Përdoruesi specifikon kërkesën Kërkesa jofunksionale specifikohet nga personat teknikë
funksionale. p.sh. Arkitekt, drejtues teknikë dhe zhvillues të programeve kompjuterikë.
Të e detyrueshme të plotësohen këto kërkesa. “Nuk është e detyrueshme” të plotësohen këto kërkesa.
Identifikohet në rast përdorimi (use case). Identifikohet si atribut i cilësisë.

Definohen në një nivel të komponentit/modulit. Aplikohen në gjithe sistemin.
Ju ndihmon të verifikoni funksionalitetin e softuerit. Ju ndihmon të verifikoni performancën e softuerit.

Definimi/klasefikimi i kërkesave në Agile

Rikujtim: Definimi/klasefikimi i kërkesave në Agile

Rikujtim: klasefikimi i kërkesave në Agile…
❑Kërkesat Funksionale dhe joFunksionale

Definimi/klasefikimi i kërkesave në Agile…
❑Kërkesat funksionale të sistemit përshkruajnë sjelljen e synuar të produktit.
▪ “Çdo kërkesë që specifikon se çfarë (what) duhet të bëjë sistemi."
❑P.sh,
sjellja e
Rezultati
▪ “Dërgoni email kur një klient i ri regjistrohet “ Input outuput
sistemit
▪ " Hapni një llogari të re "
▪ “Sistemi i pagesave krediton Klientit për Udëtimin”
❑Qëllimet janë të përshkruajnë të gjitha ndërveprimet midis përdoruesve dhe sistemit.
❑ Nëse ekipi i zhvillimit përdor metodologjinë Agile, ata do të organizojnë tregimet e

përdoruesve në PBI, një listë e renditur të funksioneve të produktit
▪ Si menaxher i financave, dua që t’ju dërgohet punonjësve në email informacionet e raportit të pages, qe secili
punonjës të e dije shumen e pages neto dhe shumen e paguar të kontributeve.

❑Kërkesat Jo-funksionale (NFR) definojn atribute të tilla si:
▪ disponueshmëria, mirëmbajtja, performanca, besueshmëria, shkallëzimi, siguria dhe
përdorshmëria.
❑P.sh një kerkese joFunksionale në kontekstin e modelit linar (ujvares):
▪ Dritarja e pagesës duhet të jetë në dispozicion për klientët brenda 10 sekondave 97% e kohës së requestes.
❑Definimi/identifikimi i NFRs (Jo-Funksionale) në modelin Agile:

▪ Definimi eksplicit i artikujve në Product Backlog’ut.
▪ Si Kritere të Pranimit në Tregime të përdoruesit.
▪ ose si pjesë e Ekipit Definition of Done (DoD).

❑Kërkesat jo-funksionale si PBI: krijimin e artikujve eksplicit të backlog’ut (si tregime përdoruesit
ose aktivizues apo mundësues Teknik).
❑P.sh NFRs si Tregimet e Përdoruesit:

▪ Si blerës, unë dua që uebfaqja të jetë e disponueshme 98% të kohës kur dua ta përdor atë në mënyrë që të
mund të bëj blerjen dhe të mos kem nevojë të gjej diku tjetër për të blerë produktin.
▪ Si një klient online bankar, unë dua të bëje kontrollimin e gjendjes së llogarisë time bankare dhe ajo të shfaqet brenda
5 sekondave në kërkesën në mënyrë që të mos zhgënjehem dhe të shoh nëse kam fonde për të paguar faturat e
mia.
▪ Si klient, dua të jem në gjendje të ekzekutoj produktin tuaj në të gjitha versionet e Windows nga Windows 2000 e tutje.

❑Kërkesat jo-funksionale si PBI; p.sh NFRs si Tregimet e Përdoruesit:

klasefikimi i kërkesave në Agile…
❑Kërkesat jo-funksionale si AC: Kriteret e Pranimit (AC) janë kushtet që duhet të plotësohen për
artikull/feature (PBI) të pranohet.
❑ P.sh: i përdorimit të AC për NFRs: Konteksti i NFRs është nenvizuar
▪ Si një Analist Financiar, unë dua të shoh transaksionet mujore për klientët e mi në mënyrë që t'i këshilloj ata për
investime të mundshme.
▪ Kriteret e Pranimit
o Sistemi shfaq të gjitha transaksionet që përmbushin parametrat e kërkimit brenda 10 sekondave
nga marrja e kërkesës.
o Transaksionet për klientët e etiketuar si konfidenciale shfaqen vetëm te përdoruesit me nivelin
e 2 të sigurisë.
o Vlera e transaksionit mujore mbi 1000 euro është verefikuar me nenviz me ngjyre të kalter.

kritere të Pranimit (AC) & 3C-të

Rikujtim: 3C-të e Tregimeve të përdoruesëve
❑Çka janë 3C-të (Card, Conversations and Confirmation) e tregimeve të
përdoruesve:
▪ 3 C-të Kartela, Biseda dhe Konfirmimi janë, proces përmes të cilit Tregimet e Përdoruesit
zberthehen dhe përgaten ato për implementim.
▪ Karta (ideja fillestare e tipareve)
o Artikuj (Tregimi i përdoruesëve) nga backlog të shkuara në Karta ku përshkrimi i tyre është i thjesht dhe
mjaftushem laboron per nje kërkeses (feature) të sistemit.
▪ Biseda (diskutim në ekip për të arritur mirëkuptim të përbashkët)
o Kërkesat e hollësishme identifikohen vetëm pasi artikulli (feature) e backlog’ut të shtohet në një sprint. Ky dialog
bëhet ndërmjet pronarit të produktit dhe ekipit të zhvillimit.
▪ Konfirmimi ( Kriteret e Pranimit)
o Kriteret sigurojnë qe artikujt e backlog’ut të i plotësojn specifikat sipas pronarit të produktit. Konsumatori do të
vlerësojë PBI kundërej kritereve të pranuara, dhe nëse kalojnë të gjitha testet miratoni PBI deri në fund të sprintit.
o Kriteret e pranimit përdoren për të përcaktuar kur tregimet e përdoruesit ka përmbushur qëllimin e përdoruesit

kritere të Pranimit (AC)
❑Tregimet e përdoruesve dhe kriteret e pranimit (AC) si format kryesore të
dokumentimit të kërkesave.
▪ Një tregim përdoruesi është një përshkrim i gjuhës natyrale i një tipari (feature). Zakonisht shoqërohet me
kritere të pranimit (AC).
▪ Kriteret e pranimit (AC) janë kushtet që duhet të
përmbushë një produkt softuer për tu pranuar nga një
përdorues, nga një klient ose nga një sistem tjetër.

kritere të Pranimit (AC)…
❑Llojet dhe strukturat e kritereve të pranimit (AC) mund të shkruhet në formate të
ndryshme.
❑Ka dy më të zakonshmet, dhe opsioni i tretë është të krijoni formatin tuaj:

1. orientuar në skenar (Given [Nëse] / When [Kur] / Then [Pastaj])
2. orientuar nga rregulli (listë kontrolli)
3.formatit te personalizuara
❑Formati i definimt të AC sipas shkrimi të orientuar në skenar [Dhënë/Kur/ Atëherë]

▪ Dhënë ndonjë parakusht
▪ Kur bëj ndonjë veprim
▪ Atëherë unë pres ndonjë rezultat

Shembull: kritere të Pranimit (AC)…
❑P.sh, AC sipas shkrimi të orientuar në skenar :
▪ Si përdorues, unë dua të jem në gjendje të rikuperoj fjalëkalimin në llogarinë time, kështu që unë do të jem në
gjendje të hyj në llogarinë time në rast se kam harruar fjalëkalimin.
❑Skenari: Keni harruar fjalëkalimin

▪ Dhënë: Përdoruesi ka naviguar në faqen login
▪ Kur: Përdoruesi zgjedh opsionin kam-harruar fjalëkalimin
▪ Dhe: Fut një email të vlefshëm për ta pranuar linkun për rikuperimin e fjalëkalimit
▪ Atëherë : Sistemi dërgoi linkun në emailin adresen e dhëne.
▪ Dhënë: Përdoruesi ka pranuar linkun përmes email’it
▪ Kur: Përdoruesi navigon përmes linkut të paranuar në email
▪ Atëherë: Sistemi i mundëson përdoruesit të vendosë një fjalëkalim të ri.

kritere të Pranimit (AC).…
❑AC e orientuar në skenari dhe ralizimi sipas 3C-të.
Karta (card):
Si student, Unë dua te e paraqes provimin në afatin e prillit, në mënyrë që të me mundësohet hyj në provim.
Biseda (Convarsation):
Ekstrakt i takimeve të palëve të interest, is PO, BO the tjeret në lidhje me tregimi e përdoruesve
Zhvilluesi: Cilet student mund te e paraqesin provimi
Product Owner: Studenti qe ka ndjekur lenden dhe eshte i regjistruar.
. . . . . .
Konfirmimi / Kriteret e Pranimit (Confirmation / Accepted criteria):
Dhënë/Nëse Një student është i regjistruar
Dhe ka ndjekur ligjërata dhe nuk është i notuar paraprakish
Kur lista e lëndeve shfaqet nga sistemi
Dhe studenti përzgjedh lëndet duke klikuar në kutinë e zgjedhjes (checkbox)
Dhe ka zgjedhur max dy lënd te për afatin jo te rregull
Dhe studenti konfirmon duke shtypur butonin e OK.
Atëherë sistem shfaq (printon) listen e konfirmimit te provimeve që student ka studenti.

AC sipas shkrimi sipas formatit të përsonalizuar
kritere të Pranimit (AC)…

Shembull: sipas formatit tuaj

Shembull: AC dhe FR + NFRs …
ID e Tregimit: STK001 AC sipas shkrimi sipas formatit të përsonalizuar…
Emri i Tregimit: Porosia e Kosumatorit
Përshkrimi: Si një Kosumator, dua të bëjë një porosi, më qëllim që të kem të dorzuar ushqimin në shtëpin time.
Konfirmimi: p.sh.; Kriteri i Pranimit (e.x: Acceptance Criteria):

Funksionale:
▪ A mund ta ruaj porosinë time dhe të kthehem më vonë?
▪ A mund ta ndryshoj porosinë time para se të paguaj për të?
▪ A mund të shoh një koston totale të së asaj që kam zgjedhur deri më tani?
Jo-funksionale: disponueshmëria:
▪ A mund të vendos një porosinë çdo kohë (24 orë në ditë ose 24/7/365)?
▪ A mund ta shoh porosinë në çdo kohë (24 orë në ditë ose 24/7/365) deri në duke përfshirë shpërndarjen)?
Jo-funksionale: siguria:
▪ A sigurohet që persona të paautorizuar dhe klientë të tjerë që nuk e shohin porosinë time?

Shembull: kritere të Pranimit (AC)…
AC sipas shkrimi sipas formatit të përsonalizuar….
❑ US: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel
options.
❑Basic search interface acceptance criteria-NFRs
▪ The search field is placed on the top bar Konteksti i NFRs është nenvizuar
▪ Search starts once the user clicks “Search”
▪ The field contains a placeholder with a grey-colored text: “Where are you going?”
▪ The placeholder disappears once the user starts typing
▪ Search is performed if a user types in a city, hotel name, street, or all combined
▪ Search is in English, French, German, and Ukrainian
▪ The user can’t type more than 200 symbols
▪ The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the
warning message: “Search input cannot contain special symbols.”

Kërkesat jo-funksionale si DoD
❑ Në Agile, ju përdorni DoD për të thënë se çfarë keni bërë në çfarë standardi cilësie kur
deklaroni diçka të bërë.
❑ Konceptualisht definition of done-DoD është një listë kontrolluese e llojeve të punës që ekipi
pritet të përfundojë me sukses përpara se të deklarojë punën e tyre mund të dorzohet.
❑ Në nivelin më abstrakt, një listë kontrolli i DoD mund të përfshijë:
▪ A është Dizajnuar
▪ A është Ndertuar
▪ A është Integruar
▪ A është Testuar
▪ A është Dokumentuar
❑ DoD vs AC:
▪ DoD aplikohet si tërsi i të gjithë punën tuaj. AC aplikoni vetëm për një artikull të vetëm në
prapambetjen tuaj.
▪ DoD sqaron se çfarë bëni ju si ekip. AC sqaron se çfarë bën produkti - funksionalitetin e tij.

Kërkesat jo-funksionale si DoD…
❑Përdorimi më i zakonshëm i DoD është në nivelin e ralizimi (delivery) në
ekipit.
▪ DoD në këtë nivel do të thotë që Pronari i Produktit shqyrtoi dhe pranoi tregimet e përdoruesit.
❑Shembuj i DoD në nivelin e Tregimit të Përdoruesit:
▪ Testet e njësisë/unit së kaluara (unit test passed)
▪ Kodi u rishikua (code reviewed)
▪ Kriteret e pranimit janë përmbushur
▪ Testet funksionale të kaluara
▪ Kërkesat jo-funksionale të përmbushura
▪ Pronari i Produktit pranon Tregimet e Përdoruesit

❑DoD në këtë nivel mund të nënkuptojë se kualifikohet të shtohet në një
version.
❑Shembuj i DoD në nivelin e Feature:
▪ Kriteret e pranimit janë përmbushur
▪ Integruar në një ndërtim të pastër
▪ Promovohet në një mjedis më të lartë
▪ Kalojnë testet e regresionit të automatizuar
▪ Testet funksionale të nivelit të feature të kaluara
▪ Përmbush kërkesat e pajtueshmërisë
▪ Funksionaliteti i dokumentuar në dokumentacionin e nevojshëm të përdoruesit të përdoruesit

❑DoD në këtë nivel mund t'i referohet një prioritetet strategjike organizative,
plani i portofolit te artikullit, ose ndonjë koleksioni tjetër të features që
plotësojnë një nevojë të tregut.
❑Shembuj i DoD në nivelin e EPIC:
▪ Integrimi nga fundi në fund ka përfunduar
▪ Kalojnë testet e regresionit
▪ Promovohet në mjedisin e prodhimit (e klientit)
▪ Përmbush pritjet e përcaktuara të tregut

Pyetje
Faleminderit…!

Modelet tjera identifikimi/analizes së Kërkesave:
Use Case & Skenari
R a m i z H OX H A
2021/2022

Modelet tjera: identifikimi/analiza e Kërkesave
❑Është e vështirë të kalosh në aktivitete teknike të inxhinierisë së softuerit derisa
të kuptoni se si do të përdorim apo t’i kalobarojm funksionet (features) në
modelimin e sistemit për përdoruesit (end users) të tij.
❑Për ta arritur këtë, zhvilluesit dhe përdoruesit mund të krijojnë një sërë
skenarësh që identifikojnë fillet se si t’e përdorim sistemin që do të ndërtohet.
▪ Skenarët, të quajtur shpesh raste përdorimi, ofrojnë një përshkrim se si do të përdoret
sistemi.
oRastet e përdorimit (Use cases) dhe
oDiagrami i Rasteve të Përdorimit

zhvillimi i Skenarve dhe Rasteve të Përdorimit
❑Rast i përdorimi (use case) dhe Skenari tregon një tregim/ngjarje të specifikuar
rreth mënyrës se si një përdorues (duke luajtur disa role të mundshme) ndërvepron
me sistemin në një grup të caktuar rrethanash.
❑Hapi i parë për të shkruar një rast përdorimi/skenar është përcaktimi i grupit të
"aktorëve" që do të përfshihen në tregim.
▪ Aktorët janë njerëz (ose pajisje) të ndryshme që përdorin sistemin ose produktin brenda kontekstit
të funksionit dhe sjelljes që do të përshkruhen se si sistemi operon.
▪ Aktori dhe përdoruesi nuk janë domosdoshmërisht e njëjta gjë.
▪ Një përdorues tipik mund të luajë disa role të ndryshme kur përdor një sistem, ndërsa një aktor
përfaqëson një klasë entitetesh të jashtme (shpesh, por jo gjithmonë, njerëz) që luajnë vetëm
një rol në kontekstin e rastit të përdorimit/skenarit.

zhvillimi i Skenarit në definimi i Kërkesave
❑Skenari është një përshkrim i ndërveprimit të Aktorit (personit) me sistemin.
❑Skenarët ndihmojn në analizen dhe dizajnimin e kërkesave të përdoruesit,
▪ Shembull: skenari i pa-përpunuar dhe përpunuar.
❑Pas përpunimit të skenarit kërkesa zhvillohet në nivel të kërkeses së sistemit
nr Emri Skenarit Përshkrimi Skenarit të pa-përpunuar (Përdoruesi) Përshkrimi Skenarit të përpunuar (Inxhinieri i Kërkesave)
Sistem verifikon kartelen e kreditit te Klientit dhe të
Taulanti ka nevoj të terheq para në bankomat 100 € PIN numrit, më pastaj shfaq opsionin për tërheqje të
nga llogaria e ti rrjedhse. Ai ka nevoj për valuta parave në valuata të ndryshme si (5€, 10€, 20€, 50€,
Tërheqja e
prje 10 € që të paguaj Taxin. 100€, 200€ dhe vlerat të ndryshme sipas nevojës së
1 Parave në
Taulanti po ashtu dëshiron një faturë të printuar përdoruesit p.sh, 35€). Po ashtu shfaq opcionin e
Bankomat
pasi ai gjithmon ka dëshir të ketë informata apo printim të fatures me informata të bilancit të
gjurmë për secilin transaksion në llogain e tij. përditsuar. Më pastaj sistemi njfton klientin të merr
kartelen e krediti dhe ofron parat të kërkuara.
2 ….. …… ……….

Definimi i kërkesave: Skenari…
❑ Skenari - është një vegël që përdoret gjatë analizës së kërkesave për me përshkru interaksion të caktuar me
sistemin.
❑ P.sh: Skenari: Klienti perdor online banking për një Transakcion Bankar
▪ Personi: Filan Fisteku, pronar i një biznesi.
▪ Ambienti: Nga kompanija me notebook personal, permes Google Crome
❑ Skenari:
1.FF starton Google Crom dhe jep adresen e bankes
2.FF autentikohet përmes loginit dhe kodit
3.Hapet faqja fillestare ku paraqiten të gjitha menyte kryesore
4.FF zgjedh menyne “transakcion bankar”.
5.Hapet forma për transakcione bankare me të gjitha fushat e nevojshme
6.FF jep IBAN e përfituesit dhe shumën e caktuar
7.Sistemi kontrollon IBAN, vlerën e dhënë dhe lajmëron përdoruesin për suksesin apo mos
suksesin e transakcionit.
8.FF klikon linkun logoff dhe çlajmërohet

User Story vs Use Case
❑Ekziston një keqkuptim i zakonshëm, ne modelet Agile zëvendësohet
nevoja për Use Case me User Stories.
❑"A është një User Story e njëjta gjë si një Use Case?"
▪ Nëse jo, cila është më mirë? Cilin duhet të përdorni? Apo mund të përdoren të dyja?
▪ User Story përqendrohen te rezultati dhe përfitimi i gjërave që ju po përshkruani,

ndërsa,
▪ Use Case (Rastet e Përdorimit) përshkruajnë mënyrën se si do të veprojë sistemi
juaj.
▪ User Story është shkruhar nga këndvështrimi i përdoruesit, përdoret gjuhën natyrale të
biznesit dhe - vetvetiu - nuk tregon tërë ngjarjen.

User Story vs Use Case…
❑US & UC – Ngjashmëria. Nëse marrim parasysh komponentit kryesor në të dy qasjet:
▪ Tregimet e Përdoruesve (US) përmbajnë rolin e përdoruesit, qëllimin dhe kriteret e pranimit.
▪ Rastet e përdorimit (UC) përmbajnë elemente ekuivalente: një aktor, rrjedhën e ngjarjeve dhe pas-
kushtet (post-condition) përkatësisht (një model i hollësishëm i UC mund të përmbajë
shumë më tepër elementë të tjerë). Elementet baze të Use Case’it
Elementet baze të User Stories
vs

❑US & UC – Ndryshimi.
❑Detajet e një Tregimi i Përdoruesi mund të mos dokumentohen në të njëjtën
skajshmëri me një Çështje Përdorimi.
▪ Tregimet e përdoruesve (us) lënë qëllimisht shumë detaje të rëndësishme.
▪ US kanë për qëllim të nxjerrin më shume detaje gjate bisedes duke bërë pyetje gjatë
takimeve të skrumit.
▪ Inkrementet të vogla për marrjen e komenteve më shpesh, në vend se të keni specifikime
më të hollësishme të kërkesave si në Rastet e Përdorimit (uc).

❑ Rikujtojm: Çfarë është tregim i përdoruesit (us)?
❑ US definon se kush (who), çfarë (what) dhe pse (why) e një tipari/funksioni (feature) të
produktit.
❑ Struktura e tregimit të përdoruesit (us)
▪ Ato shpesh përmbajnë vetëm një fjali ose disa rreshta të shkruara në strukturën
vijuese: Si një (përdorues) - Kush
Unë dua të (kryej një veprim) - Çfarë
Kështu që unë mund (të arrij një qëllim) - Pse
▪ Një kriter i pranimit zakonisht bie dakord se cilat rezultate të us duhet të plotësohen.
P.sh: "Si udhetare, unë dua të kem një biletë digjitale me barkod për udhëtim me tren në telefonin tim, në
mënyrë që të mos kem nevojë ta shtyp atë dhe të mbaj një letër me vete."
Dhënë (si ndodhin gjërat)
Formati vijues AC: Kur (veprimi i ndërmarrë)
Atëherë/Pastaj (rezultati i këtij veprimi)

❑Çfarë është Rast i përdorimit (use case - uc)?
▪ UC përshkruajnë procesin hap pas hapi që kalon një përdorues për të përmbushur qëllim
duke përdorur një sistem softuerësh.
▪ Në terma teknikë, është përshkrimi i ndërveprimit midis sistemit dhe aktorëve.
Çfarë përfshijnë - Use Case Çfarë NUK përfshijnë - Use Case

Kush po përdor sistemin
Gjuha specifike të implementimit
Çfarë dëshiron të bëjë përdoruesi
Qëllimi i përdoruesit
• Hapat që përdoruesi merr për të përmbushur një
Detaje rreth GUI ose dritareve.
detyrë të caktuar.
• Si duhet t'i përgjigjet sistemi një veprimi

❑Elementet e Rastit të përdorimit (use case).
▪ UC përshkruan një kombinim të elementeve të mëposhtëm:
o Aktori - kushdo ose çdo gjë që kryen një sjellje (i cili po përdor sistemin),
o Palët e interesit - dikush ose diçka me interes të veçantë në sjelljen e sistemit në
diskutim,
o Aktori Primar - palë e interesit që fillon një bashkëveprim me sistemin për të arritur një
qëllim ,
o Para ose pas kushtet - çfarë duhet të jetë e vërtetë ose të ndodhë para dhe pas mbarimit
të rastit të përdorimit.
o Triggers - kjo është ngjarja që shkakton fillimin e çështjes së përdorimit apo uc.
o Skenarët kryesorë të suksesit [Rrjedha themelore] – hapat e ralizuar në të cilin asgjë nuk
shkon keq.
o Pathet alternative [Rrjedha alternative] - këto pathe janë një ndryshim në skenarin
kryesore. Këto përjashtime janë ato që ndodhin kur gjërat shkojnë keq në nivelin e
sistemit.

Llojet e përshkrimit të Use Cases
❑Përshkrim i shkurtër (brife) i Use Case’it
Rasti i përdorimit
Regjistrimi i Porosis
(use case):
Aktori Asisteni i dyqanit (Arkatari/ja)
Një klient afrohet për të bërë një porosi. Asisteni i dyqanit (Arkatari/ja) përdor sistemin për të
krijuar një porosi të re, për të shtuar artikuj në porosi, për të gjurmuar informacionin e klientit,
Skenari
për të ruajtur porosinë dhe për të printuar formularin dhe faturën e porosisë. Gjatë rrugës,
sistemi shfaq detaje për mallrat, nëntotalin dhe totalin
Event (Ngjarja) Use case Hapat e use cases Aktori

Shtoni artikujt e dëshiruar,
Klienti bën një Regjistrimi i Regjistroni klientin , Asisteni i dyqanit
porosi Porosis Ruani porosinë, (Arkatari/ja)
Printoni formularin e porosisë dhe faturën

Shembull: përshkrimit të UC sipas Elementeve të saj

Përshkrim i plot (full description) i Use Case’it
Llojet e përshkrimit të
Use Cases

Use Case Name: Withdraw Cash
Actor(s): Customer (primary), Banking System (secondary)
Summary Description: Allows any bank customer to withdraw cash from their bank account.
Priority: Must Have
Status: Medium Level of details
The bank customer has a card to insert into the ATM
Pre-Condition:
The ATM is online properly
The bank customer has received their cash (and optionally a receipt)
Post-Condition(s):
The bank has debited the customer's bank account and recorded details of the transaction
1. The customer enters their card into the ATM
2. The ATM verifies that the card is a valid bank card
3. The ATM requests a PIN code
Llojet e përshkrimit të
4. The customer enters their PIN code
5. The ATM validates the bank card against the PIN code
6. The ATM presents service options including "Withdraw"
7. The customer chooses "Withdraw"
Use Cases Basic Path:

8. The ATM presents options for amounts
9. The customer selects an amount or enters an amount
10. The ATM verifies that it has enough cash in its hopper
11. The ATM verifies that the customer is below withdraw limits
12. The ATM verifies sufficient funds in the customer's bank account
13. The ATM debits the customer's bank account
14. The ATM returns the customer's bank card
15. The customer takes their bank card
16. The ATM issues the customer's cash
17. The customer takes their cash
2a. Invalid card
2b. Card upside down
5a. Stolen card
5b. PIN invalid
Përshkrim i plot (full description) i Use 10a. Insufficient cash in the hopper
10b. Wrong denomination of cash in the hopper
Case’it Alternative Paths:
11a. Withdrawal above withdraw limits
12a. Insufficient funds in customer's bank account
14a. Bank card stuck in machine
15a. Customer fails to take their bank card
16a. Cash stuck in machine
17a. Customer fails to take their cash
a ATM cannot communicate with Banking System
b Customer does not respond to ATM prompt
NF1: Time for complete transaction
NF2: Security for PIN entry
Non-Functional
NF3: Time to allow collection of card and cash
Requirements:
NF4: Language support
NF5: Blind and partially blind support
Use Case diagrami
❑Diagrami i rastit të përdorimit (use case)
oAktorë – shfrytëzes i sistemit në një rol të caktuar
oAktorë mund të jenë:
✓Personi
✓Sistem i jashtëm - harduer
✓Sistem i jashtëm - softuer
✓Use case – është një punë (funksion) që duhet ta kryej aktori

me ndihmën e sistemit
✓Aktori është gjithmonë përfituesi i use case-it
Diagrami i rastit të përdorimit (use case) përdoret për të analizuar kërkesat e nivelit të lartë të sistemit.

Use case – Sistemi Bankar online

Use case – Sistemi Bankar online…
Aktori është
një rol jo individ

Use case - Sistemi Bankar (Bankomati)

Relacionet mes use cases <<include>>
• <<includes>> përdoret për ngjarjet që janë pjesë e use case-it burimor (p.sh kontrollo bilancin)
Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 21

Relacionet mes use cases <<extend>>
• <<extend>> përdoret për ngjarjet që është funksion i zgjeruar i use case-it burimor (p.sh
printo dhe rauj si hard-kopje)

Use case – Online Banking System

Identifikimi dhe përshkrimi i use case
1. Mos u bë perfeksionist. Nuk ka nevojë me ja qëllu me të parën
2. Identifiko aktorët së pari
3. Përcakto se çka duhet të bëjnë aktorët → përcakto use cases
4. Përpilo një listë të use cases

Shembull: procesin i Use Cas’it të aplikimit për kredi

Shembull: procesin i Use case’it Agjensioni i Udhtimit
Use case
Sistemi
Asocimi
Aktori

Shumbull me gabime

Pyetje
Faleminderit…!

Faza: Dizajnit apo Modelimit te Sistemit
R a m i z H OX H A
2021/2022

Rikujtim: Qasja sipas rrjedha së procesit të SCRUM’it
përseritse

Komponentet/elementet
e një sistemi softuerik

Bazat e Dizajnit të Softuerit
❑Dizajni është pjesë e rëndësishme e çdo procesi të zhvillimit të sistemeve të TI-së.
❑Forma dhe funksionimi i sistemit të krijuar IT varet nga ky aktivitet.
Është një proces me anë të të cilit kërkesat përkthehen

në plan për ndërtimin e një softueri.
Procesi i Dizajni i
SRS
Dizajnit Softuerit
Domeni i Domeni i
Problemit Zgjidhjes
(SRS: specifikimet e kërkesave të softuerit

Bazat e Dizajnit të Softuerit…
❑ Dizajni në Agile
▪ Çdo vendim i dizajnit që merrni duhet
të drejtohet apo orjentuar (driven) nga kërkesat
▪funksionale dhe jofunksionale.

❑Dizajni brenda kontekstit të Inxhinierisë së Softuerit
▪ Dizajni i softuerit qëndron në bërthamën teknike të inxhinierisë së softuerit dhe zbatohet
pavarësisht nga modeli i procesit të softuerit që përdoret.
▪ Dizajn funksional e bën kodimin dhe mirëmbajtjen shumë të thjeshtë.
❑Dizajni i softuerit përfshin grupin e

▪ parimeteve, koncepteve, dhe praktikave
❑që çojnë në zhvillimin e një sistemi ose produkti me cilësi të lartë
❑Duke filluar pasi kërkesat e softuerit janë analizuar dhe modeluar

▪ Dizajni i softuerit është veprimi i fundit inxhinierik i softuerit brenda aktivitetit të modelimit dhe
vendos skenën për ndërtimin (implementimin dhe testimin e kodit)

❑Dizajni i softuerit është pjesa më kreative e procesit të zhvillimit
Kërkesat Analiza Dizajni Modeli

Inxhinierike Modelit Inxhinierike Dizajnit
Procesi i Dizajnimit të Softuerit

Plani (blueprint) për
ndërtimin e softuerit

❑FURPS - atributet e Cilësisë/Qualitetit të Softuerit
F Funksionaliteti U Përdorshmëria
vlerësohet sipas grupit të veçorive dhe aftësive të vlerësohet duke marrë në konsideratë faktorët
aplikacionit, përgjithsisht funksioneve dhe sigurisë së njerëzorë, estetikën e përgjithshme, konsistencën,
sistemit. përdorshmerin dhe dokumentacionin.
R Besueshmëria P Performanca
vlerësohet duke matur frekuencën dhe qendrushmëris ndaj
dështimeve, saktësisë së rezultateve, mesataren e kohës së matet nga shpejtësia e procesimit, koha e reagimit,
dështimit (MTTF), aftësinë për të rikuperuar /recover konsumi i risurseve, throughput dhe efikasiteti
nga gabimet
S Përkrahshmëria
matet nga aftësia për t’u zgjeruar programin, përshtatshmëria, shërbimi, testueshmëria, përputhshmëria.

produktet e punës së Dizajnit të Softuerit
❑Që një dizajn të implementohet lehtësisht në një gjuhë programimi
konvencionale, artikujt e mëposhtëm duhet të dizajnohen gjatë fazës së dizajnimit.
▪ Module të ndryshme të nevojshme për implementimin e zgjidhjes së dizajnimit.
▪ Kontrolli i relacioneve ndërmjet moduleve të identifikuara. Relacionet njihet gjithashtu
si lidhjet apo relacioni e invokimit ndërmjet moduleve.
▪ Interfeisa midis moduleve të ndryshme. Interfeisat midis moduleve të ndryshme identifikon
dhënat e saktë për t’u shkëmber midis moduleve.
▪ Algoritmet e nevojshme për të implementuar çdo modul individual
▪ Strukturat e të dhënave të moduleve individuale.

elementet e Modelit të Dizajnit në Inxhinieri Softuerësh
❑Elementet e Dizajnit të të Dhënave/Klasësve
▪ modeli i të dhënave dhe/ose informacionit që përfaqësohet në një nivel të lartë abstraksioni (user’s view për të
dhënat)
▪ dizajnimi i strukturave të të dhënave dhe algoritmeve të lidhura me to.
▪ niveli i aplikacionit, përkthimi i një modeli të dhënash në një bazë të dhënash / warehouse dhënash.
❑Elementet e Dizajnit Arkitekturor
▪ Strukturimi i nënsistemeve/moduleve të ndërlidhura, që shpesh rrjedhin brenda analizës modelimit të kërkesave.
▪ Çdo nënsistem mund të ketë arkitekturën e vet (p.sh., një GUI mund të strukturohet sipas një stilit
arkitekturor për interfeisin e përdoruesit).
❑Elementet e Dizajnit të Interfeisit
▪ (1) ndërfaqja e përdoruesit (UI/UX)
▪ (2) ndërfaqet e jashtme: mekanizmi i komunikimit ndër-procesor (IPC-paternat/API) me sisteme, pajisje, rrjeta tjera
▪ (3) ndërfaqet e brendshme: mekanizmi i komunikimit ndër-procesor (IPC-paternat/API/Procedurat) mes
komponentëve të ndryshëm të brendshëm.

elementet e Modelit të Dizajnit në Inxhinieri Softuerësh…
❑Elementet e Dizajnimit në nivel të Komponentit
▪ Përshkruani detajet e brendshme të secilit komponent (lloje të ndryshme entitetesh: objekt, shërbimet,
sensorë, interfeisat etj.)
▪ Komponenti i reprezentohet në formë diagrami UML (diagrami i aktivitetit, diagrami i komponentit-pamja
e kutisë së bardhë/e zezë, diagrami i moduleve - detajet e modelit të entiteteve)
▪ Pseudo-kodi (gjuhë programimi)
❑ Elementet e Dizajnimit në nivel të Zbtimit(Deployment)
▪ Përshkruani mjedisin fizik kompjuterik të komponentin që do të mbështesë softuerin.
▪ UML Diagrami i deployment tregon detajet e dizajnit të mjedisit kompjuterik (p.sh:, harduerin-
sensorëtit, platformat, IDE konfigurimi).

parimet e Dizajnimit të Sistemit në Inxhinieri Softuerësh
❑Ekzistojnë disa parime kryesore që duhet konsideruar në modelin e dizajnit në programimin e
orientuar në objekte (OOP):
▪ Abstraksioni
o Procesi i fshehjes së të dhënave të brendshme dhe implementimit për botën e jashtme.
▪ Modelet/Paternat
▪ Ndarja e të dhënave (Separation of data)
▪ Modulariteti
▪ Fshehja/mbrojtja e të dhënave (Data hiding)
▪ Pavarësia funksionale (Functional independence)
▪ Rifaktorimi

Nivelet e dizajnit të Softuerit
1) Dizajn Arkitekturor
2) Dizajn preliminal (Niveli i Lartë).
3) Dizajn i detajuar (Niveli i Ulët).
System
Sub-Systems/components
High-Level Design
Modules/Packages
Classes
Low-Level Design
Methods

Procesi me nivelet i Dizajnit
Architectural High-level Low-level

Procesi i Dizajnit të Softuerit
1. Dizajni duhet të ekspozojë një patern arkitektektonike si:
▪ (client server (call return), pipe-filter, MVC, Layer, event-driven, Hexagonal, Microservice etj)
o komponimi i komponenteve dhe implementimi në mënyre evolucionare, duke faselituar testimin dhe dorzimi.
2. Dizajni i modelit të domenit të jetë modular (modularitet):
▪ strukturimi në mënyrë logjike në nën-domene ose nën-sisteme gjegjesishte module.
3. Dizajn i orientuar-nivel komponenti (dizajnin e mbrenda e komponentit):
▪ në strukturim të të dhënave të përshtatshme për modelet e Klasave/entitetev të varura nga
paternat të njohura të strukturimit të të dhënave.
▪ në komponente që ekspozojnë karakteristika funksionale të pavarura.
▪ në ndërfaqet (interfeisa ose API’ja) që thjeshtzojn kompleksitetin e lidhjeve midis komponentëve me mjedisin e
jashtëm.

Procesi i Dizajnit të Softuerit…
4. Dizajn duhët të përmbaj në form të theksuar apo të veqant:
▪ bazen e të dhënave, arkitekturën, interfeisat, dhe komponentët (moduleve).
5. Dizajn duhet të bazohet në mekanizat e procesit softuerik:
▪ përdorim një modelit përseritse&rritës (agile) që është nxitur nga informacionet e marra gjatë
analizës kërkesave të softuerit.
6. Dizajn duhet të reprezentohet duke përdorur:
▪ simbolet që në mënyrë efektive dhe të qartë komunikojn përmbajtjen e tyre.

aktivitetet e Procesit të Dizajnit të Softuerit
Aktiviteti i Dizajnit: Aktiviteti i Dizajnit Elementet ose Çështje
Dizajni i rrethinës ose mjedisit Pajisjet, Rrjetet, Serverët
Softueri (strukturimi i module,
Dizajni i arkitektures së aplikacionit dhe
komponenteve, etj) dhe Konfikurimet bazuar
softuerit/programit
ne paternen e arkiektuares
Dizajni i interfasës së sistemit Mjeti për komunikim (API) me sisteme tjera
Dizajni i ndërfaqeve të përdoruesve GUI: Dritarja e përdoruesit , Raportet
Definimi dhe modelimit te moduleve dhe
Dizajni i kompoenteve
modeleve entiteteve/objekteve
Magazinimi i informacioneve apo të
Dizajni i bazës së të dhënave
dhënave
Dizajni i kontrollit qasjes dhe Sigurës së
Firewalls, Qasjet/Kontrolli qasjes
sistemit

Dizajni i Arkitekturës së Softuerit
❑Aktiviteti më i rëndësishëm i dizajnimi është zhvillimi i "arkitekturës" së
sistemit.
❑Arkitektura =
▪ Dizajni i nivelit të lartë të sistemit
▪ Përcakton strukturën bazë të sistemit
❑Zakonisht bëhet nga inxhinierë me shumë përvojë të quajtur "arkitektë“
❑Arkitektët shërbejnë gjithashtu si një lidhje midis anëve të biznesit dhe atyre
teknike të kompanisë.

Dizajni i Arkitekturës së Softuerit…
❑Arkitektura përcakton apo definon:
▪ Nënsistemet/Modulet (subsystems) kryesore
o Nënsistemet/Modulet janë fusha kryesore e funksionalitetit
o Nënsistemet/Modulet komplekse mund të zbërthehen në nënsisteme më të vogla
▪ Përgjegjësitë e secilit nënsistem
▪ Varësitë midis nënsistemeve
▪ Ndërfaqet/interfeisat midis nënsistemeve/moduleve
▪ Modelet/paternat e komunikimit midis nënsistemeve/moduleve
▪ Teknologjitë e implementimit.
o Sistemet operative, gjuhët e programimit, UI, rrjetet kompjuterike, bazat e të dhënave, etj.
▪ Vendosja (Deployment) fizike e sistemit
o Topologjia e sistemit
✓ Çfarë lloj makinerish (hardware) do të nevojiten?
✓ Si do të lidhen (komunikojn)?
o Pasqurimi i komponentëve logjikë të softuerit në pajisje fizike (hardware)
Dizajni i Arkitekturës së Softuerit…
❑Pasi të jetë definuar arkitektura e përgjithshme, ekipe ose individë të ndryshëm mund të
dizajnojnë paralelisht nënsistemet/modulet.
❑Definimi i ndërfaqeve (interfaces) të mira ndërmjet nënsistemeve është kritik.

▪ Ndërfaqet duhet të jenë sa më të thjeshta
▪ Jepuni dizajnuesve të nën-sistemit liri maksimale
▪ Kufizoni efektet pa-organizuar të ndryshimeve në nënsisteme/module.

Paternat: Arkitektures softuerike
❑Arkitekture shtresore (layer):
▪ Komponentët e arkitekturës shtresore janë të organizuara në shtresa horizontale fig më poshtë,
▪ Secila shtresë që kryen një rol apo përgjegjsi specifik brenda aplikacionit.
▪ Paterna nuk specifikon numrin dhe llojet e shtresave që duhet të ekzistojnë në të,
▪ Standarte i ka 4-Shtresa:
o Prezantimi, Aplikacionit (biznesi/service) , Qasjes të Dhënave, Infrastuktures/integrimit
BO- Business Objects
Prezentimit HTML/CSS, JS, Servlet, JSP, ASPx, Spring/.NET MVC
DTO- Data Transfer Objects
Logjika Aplikacionit /Shërbimeve BO’s DTO’s API/Services ESB
ESB- Enterprise Service Beans
DAO- Data Access Object
ORM- Object Relational Mappings
DA – Qasje të Dhënave DAO ORM ADO.NET JPA ADO- Application Data Objects
Entitetet ose Objektet e Domainit JPA- Java Persistence API
Infrastruktures/Integrimit JMS- Java Message Service
JMS JDBC WS Client JAX-WS/RS WS- Web Service
JDBC- Java Database Connection
MOM- Message Object Middleware
Service të
MOM DB palës tretë

Shembull: arkitekrures n-shtresore
✓ Mund të përmbajë shtresa shtesë të hapura, si një fig Arkitektura n-shtresore/nivel
me shtresen e shërbimeve
shtresë e shërbimit, që mund të përdoren për t’u qasur
shërbimeve e mbrenda shtresës së biznesit.
fig organizimi i kodit të aplikacionit n-shtresore/nivel

Paternat: Arkitektures softuerike…
❑Arkitektura MVC.
▪ MVC qëndron për Model View Controller
❑Frameworka MVC është një patern arkitektonik që ndan aplikacion në tre komponentë
logjikë kryesorë
▪ Model, View dhe Controller
❑Secili komponent i arkitektures është ndërtuar të trajtoj
specifikisht aspektet e implementimit të një aplikacioni
❑MVC ndan logjikën e biznesit dhe shtresën e prezantimit nga njëra-tjetra.

❑Arkitektura MVC është bërë e njohur për dizajnimi e Ueb aplikacioneve.

Paternat: Arkitektures softuerik…
Ndërvepron me Modelin dhe View
merrni inputet e përdoruesit Ndërvepron me bazën e të dhënave
(parametrat e kërkuar/requests) Ekzekuton logjikën e biznesit
Paterna e Arkitektures Servlets Java Class

MVC të Aplikacionit filter Modeli
2
Kontrolleri
Klienti 1
3 BDH
5
JSP pages
View
Serveri Aplikacioni

Struktura e organizimit të MVC
App_Data - mund të përmbajë skedarë me të dhënave të aplikacionit si fila ( LocalDB, mdf, xml) dhe filja të tjerë
që lidhen me të dhënat. IIS kurrë nuk do të shërbejë fijla nga folderat e App_Data.
App_Start folder mund të përmbajë file të Klasave të cilat do të ekzekutohen kur fillon aplikacioni. fajlat e
konfigurimit si AuthConfig.cs, BundleConfig.cs, FilterConfig.cs, RouteConfig.cs etj. MVC 5 përfshin BundleConfig.cs,
FilterConfig.cs dhe RouteConfig.cs si default.
Content folder përmban fajla statikë si fajla të CSS, imazhe dhe fajla ikonash. Aplikacioni MVC 5 përfshin
bootstrap.css, bootstrap.min.css dhe Site.css si default.
Controllers folder përmban klas fijla për kontrollerin. Kontrollorët merren me kërkesën (requests) e përdoruesve
dhe kthen një përgjigje (respons).
Models folder përmban fijla të klasave të BO. Në mënyrë tipike, klasa e modelit përfshin vetit (properties) publike,
të cilat do të përdoren nga aplikacioni për të mbajtur dhe manipuluar të dhënat e aplikacionit.
Scripts folder contains fajlat e JavaScript ose Angular për aplikacionin. MVC 5 përfshin fajla të javascript për
bootstrap, jquery 1.10 dhe modernizues si default.
Views folder përmban fajla html për aplikacionin. Tipik VIEW fajlat është një fajl .cshtml ku ju krijoni html dhe
HTML/CSS, JS, Servlet, JSP, ASPx, Spring/.NET MVC

Paternat: Arkitektures softuerik…
❑Arkitektura Hexagonale
▪ Arkitektura Hexagonale është një alternativë ndaj paternes arkitektures shtresore.
▪ Kjo patern i arkitekturës organizon logjiken e biznesit në qendër.
▪ Emërtimet alternative të kësaj: Ports & Adapters/Clean architecture/onion architecture

Struktura e organizimit të Kodit në Hexagonal

Paternat: Arkitektures softuerike…
❑Arkitektura Mikroshërbimeve
▪ një aplikacion monolit është një njësi e vetme e përbashkët,
▪ një aplikacion me arkitekturë mikroshërbimeve - zbërthyer në njësi më të vogla të pavarura.
▪ Modulet/serviset e komunikojnë me njëri-tjetrin përmes metodave të definuar të quajtura API
(Ndërfaqet e Programimit të Aplikimit).
Arkitekturë e Microservice

UML-Diagrami i Komponenteve përshkruan që
Arkitekturen microservice e aplikacionit
Shembulli:
daigramit të
komponenteve

Dizajnimi i GUI së Përdoruesit
❑Dizajni i ndërfaqes së përdoruesit ose dizajni UI/UX në përgjithësi i referohet paraqitjes vizuale të
elementeve me të cilët një përdorues mund të bashkëveprojë në një aplikacion/softuer.
▪ “për përdoruesin, intrerface është sistemi!!”
❑UI mund të jetë butonat, lista drop-down, ose shtrirja vizuale e një faqe në Ueb.
❑Modelet e ndërfaqes së përdoruesit duhet të jenë tërheqëse për përdoruesit e, por
duhet të jenë funksionale dhe të krijuara me përdoruesit në mendje.

Dizajnimi i Bazës së të Dhënës
❑ Përdorimi i modelit të domainit të klases ose ERD
❑ Arkitektura e Bazës së të dhënave
▪ BDH centralizuar ms SQL Rrjeti NoSQ
o + Më e lehtë për të organizuar, modifikuar, kërkuar dhe komunikimit L
backups
o - Mund të jetë më i ngadalshëm për shkak të shfrytëzimit/
ngarkesë të lartë Oracle
▪ BDH shperndar ose distributuar
o + Qasja e të dhënave dhe kërkimi më shpejtë për system të
madhë me ngargesa të larta.
o - Mund të jetë më i ngadalshëm në përdorimin e të dhënave
jo lokale
o - Duhet të siguroheni që të dhënat janë të qëndrueshme /
të sinkronizuara
❑ Skemat Financat
▪ Tabelat dhe kolonat në relacion Administrata
BDH
❑ Kufizimite i integritetit centralizuar
Shitjes
▪ Referencat për çelësat e huaj - për tabela lidhëse
Shembull: Menaxhimi i Decentralizuar i të Dhënave
Baza e të Dhënave e Centralizuar
VS
Baza e të Dhënave e Decentralizuar

Shembull: Menaxhimi i Decentralizuar i të Dhënave...
Parimet e mikro-shërbimeve: Menaxhimi i Decentralizuar i të Dhënave

Dizajni i interfaces/nderkomunikimit së sistemit
❑Interfaca (API)e sistemit procesoj inputet, bashkëveprojnë me sisteme të tjera në kohë reale.
▪ Kështu që sistemet e ndryshme mund të komunikojn me njëri-tjetrin
▪ Interfesat e sistemit lidhen me

sisteme të tjera në mënyra të ndryshme
✓ Ruani të dhënat nga nje sistemi tjeter
i përdor.
✓ Lexoni të dhënat e një sistemi tjetër
✓ Bëne kërkesa në kohe reale për
informacion.
▪ Shërbime të softuerike (SaaS)

Shembull: Interface e Sistemit XML/JSON
Application program interface (API) –

The set of public methods that are available to the outside world

dizajnimi i Siguris dhe Kontrollit të Sistemit
❑ Kontrolli i ndërfaqes së përdoruesit
▪ Autorizimet e përdoruesit
❑ Kontrolli në nivel të aplikacionit
▪ Transaksionet janë "atomike“
❑ Kontrollet në bazë të të dhënave
▪ Nuk ka anomali të bazës së të dhënave
❑ Kontrollet në Rrjet
▪ Antivirus and Anti-malware, Firewalls, Network Segmentation, qasjet, VPN, etj
Network Security Types

Referencat
❑ Software Engineering A Practitioners Approach by Roger Pressman,

Bruce Maxim
▪ Kapitulli 9, 10, 11

Pyetje
Faleminderit…!

Faza: Dizajnit - Modulariteti
R a m i z H OX H A
2021/2022

Modulariteti
PJ E SA D Y TË

Rikujtojm: Procesi me nivelet i Dizajnit
Architectural High-level Low-level

Rikujtojm: parimet e Dizajnimit të Sistemit
❑Ekzistojnë disa parime ose principe kryesore që duhet konsideruar në modelin e dizajnit në
programimin e orientuar në objekte (OOP):
▪ Abstraksioni
o Procesi i fshehjes së të dhënave të brendshme dhe implementimit për botën e jashtme.
▪ Modelet/Paternat
▪ Ndarja e të dhënave (Separation of data)
▪Modulariteti
▪ Fshehja/mbrojtja e të dhënave (Data hiding)
▪ Pavarësia funksionale (Functional independence)
▪ Rifaktorimi

Parimi i Dizajnit - Modulariteti
❑Ç’ka është modulariteti (ose modularizimi):
▪ Zbërthimi i softuerit në një numër komponentësh më të vegjël sa më të pavarur, të këmbyeshme
që të jetë e mundur, përcaktuar funksionalitete ose përgjegjësi të ndryshme në komponentë të
ndryshëm të quajtur module, që janë të integruara për të përmbushur kërkesat e problemit.
❑ Moduli në programimin modular përmban gjithçka të nevojshme për të ekzekutuar
funksionalitet të dëshiruar.
Secili modul mund të programohet veçmas dhe është dizajnuar për të arritur funksionalitet
specifike.
❑ p.sh moduli ose komponenti përmban:
Entitete (klasa, servisi, package, UI-komponenti, interfesi, sensori etj)
Video per modulet ref: https://www.youtube.com/watch?v=20JP8w6_nVA

Parimi i Dizajnit – Modulariteti…
❑Çfarë është një Sistem Modular?
▪ Sistemi Modular është një sistem modulesh, ndërfaqesh (ose interfesash) dhe
rregullash konfigurimi që mundësojn konfigurimin e produkteve për ekzekutimi të
funksioneve.
▪ Suksesi është ndërtuar mbi fleksibilitetin, agilitetin dhe efektshmëri.
▪ Këto module duhet të jenë të lehta për t’u implementuar, kuptuar, testuar, modifikuar, zëvendësuar
ose fshirë në mënyrë të izoluar pa ndonjë ndikim të madh në pjesën tjetër të sistemit.

❑Çfarë është një modul?
▪ Një modul është një pjesë e funksionesh të grupuar që ekspozohe me një interfeis, me anë të së
cilës modulet e tjerë mund të komunikojnë me të.
▪ Modulin gjithashtu mund të përshkruarajm si një komponent ose një bounded context
(kontekst i kufizuar).
Modulet:
Çdo modul ka një interfajse dhe një trup
Relacioni ‘është pjesë’ midis moduleve
Moduli Interfeisi Protokollo

❑Parimet dhe Heuristics për Modularitetin e mirë:
1. High Cohesion
2. Loose Coupling
3. Information Hiding
4. SOLID
o Single Responsibility Principle (SRP)
o Open / Close Principle (OCP)
o Liskov Substitution Principle (LSP)
o Interface Segregation Principle (ISP)
o Dependency Inversion Principle (DIP)

si duhet t'i zbërthejmë (decompose) Modulet?
❑Moduli duhet të ketë vetëm një përgjegjësi të vetme, që është Parimi i Përgjegjësisë së Vetëm
(Single Responsibility Principle).
❑ Pavarësia funksionale e një moduli mund të matet duke përdorur bashkimin
(coupling) dhe kohezionin (cohesion).
▪ coupling: është matja e shkallës së ndërvarësisë midis moduleve, dizajni i mirë i softuerit do
të ketë lidhje të dobët (low coupling).
▪ kohezioni: është një masë e shkallës në të cilën elementet e modulit janë të lidhura funksionalisht.
oështë shkalla ku të gjithë elementët përcaktohen drejt kryerjes së një detyre të vetme në atë module/komponenet.
okohezioni është ngjitësi i brendshëm që e mban modulin së bashku.
odizajn i mirë i softuerit do të ketë kohezion të lartë

si duhet t'i dekompozimi (decompose) Modulet?…
❑Cohesion vs Coupling:
▪ Secili modul duhet të implementohet në një
mënyrë që të ketë më pak varësi (less
dependency) nga modulet e tjera dhe
▪ Elementet brenda këtij moduli duhet të
lidhen funksionalisht së bashku.
❑Një dizajn i mirë i softuerit kërkon

▪ kohezion të lartë dhe coupling të ulët.

si duhet t'i dekompozimi (decompose) Modulet?...
❑Difenernca mes kohezionit (kohezion) dhe bashkimit (coupling)
kohezionit (kohezion) bashkimit (coupling)
Kohezioni përkufizohet si shkalla e relacioneve coupling përcaktohet si shkalla e
midis elementeve të të njëjtit modul. ndërvarësisë ndërmjet moduleve.
Është një qasje brenda modulit Është një qasje ndër-moduleve
Preferohet bashkim e ulët (low coupling)
Preferohet kohezioni i lartë për shkak të
pasi rezulton në më pak varësi midis
përmirësimit të fokusit në një detyrë specifike.
moduleve.
Kohezioni përdoret për të treguar fuqinë Coupling përdoret për të treguar
funksionale relative të modulit. pavarësinë relative midis moduleve.
Në kohezion, moduli përqendrohet në një detyrë Në nderlidhja, e një modul i veçantë lidhet
të caktuar. me module të tjera.
Kohezioni njihet edhe me emrin 'Lidhja brenda Coupling njihet edhe me emrin 'Lidhja
modulit'. ndër-module'.

❑kohezionit (kohezion) vs bashkimit (coupling)
Klienti dhe porosia janë të lidhura ngushtë me Porosija duhet të dijë vetëm id e klientit ka
njëri-tjetrin. nevojë për një referencë për objektin e klientit.
Klienti po ruan listën e të gjitha porosive të bëra
nga një klient, ndërsa porosia po ruan Ne mund t'i lidhim dobët (loose coupled) të
referencën për objektin Klienti. dy klasat duke bërë këto ndryshime

❑kohezionit (kohezion) vs bashkimit (coupling)
Një modul mund të jetë një klasë ose një paketë ose
edhe një mikroshërbim.
p.sh, të gjitha metodat brenda një klase User duhet të

përfaqësojnë sjelljen e përdoruesit.
Thuhet se një modul ka kohezion të ulët nëse përmban elementë të pa-nderlidhur.

P.sh, një klasë User që përmban një metodë se si të vërtetohet adresa e emailit
Klasa e User mund të jetë përgjegjëse për ruajtjen e adresës së emailit të përdoruesit, por jo për
vërtetimin e saj ose dërgimin e një emaili. Këto duhet t'i përkasë një klase tjetër si Email.
nderlidhur me Parimin e Përgjegjësisë së Vetme (SRP-SOLID)

Shumbull: Kohezion i Lartë, Bashkim (Couplingi) Ulët
▪ Nëse kemi një REST API që duhet të menaxhojë
Përdoruesit, Postimet dhe Mesazhin Privat midis
përdoruesve, p.sh fig 9.
▪ klasa RestApplication po menaxhon kërkesat REST API.
▪ Çështja është se moduli Web Rest App varet nga të
gjitha klasat e tjera (module tjera).
▪ Ky është një shembull i qartë i kohezionit të ulët dhe
coupling të lartë sepse varet shumë nga klasat e
brendshme të moduleve të tjera.
fig. 9

Shumbull: Kohezion i Lartë, Bashkim (Couplingi) Ulët…
▪ Rootes janë ende në klasën RestApplication,
por tani kjo nuk kujdeset për logjikën e çdo veprimi,
por ju është deleguar atë te klasave të Shërbimive
në secilin modul.
▪ Kjo e bën kodin tuaj më koheziv dhe më pak të
lidhur ngushtë, sepse nëse një klasë e
brendshme (p.sh, disa klasat DAO) ndryshon
përveç klasave të shërbimeve,
▪ klasa RestApplication nuk intereson pasi nuk ka
përgjegjësia të trajtojë më logjikën e tyre specifike.
fig. 10
▪ Njihet si paterna-fasad dhe është një mjet i mirë për ta bërë kodin tuaj më-koheziv dhe më
pak të lidhur-ngushtë me modulet tuaja.
dekompozimi (zbërthimi) funksional i Moduleve
❑ Zbërthimi funksional është një metodë e përdorur për të dizajnuar një strukturë të
detajuar të komponentëve ose moduleve të softuerit.
▪ Zbërthimi funksional specifikon funksionet, aktivitetet, proceset ose veprimet që komponenti ose
moduli i softuerit duhet të kryejë.
❑Procesi i zbërthimit funksional

▪ zbërthimi funksional është një teknikë standarde për të
dizajnuar softuer,
▪ zbërthimi mund të ralizohet lart-poshtë (vazhdon të
rafinojë funksionet) ose poshtë-lart.

Procesi i dekompozimi (zbërthimit) funksional
❑Identifikoni funksionin e përgjithshëm (funksioni bizinisor)
▪ definoni qartë se çfarë detyre duhet të kryejë softueri, pajisja, procesi apo komponenti juaj.
▪ spefinoni cilat janë detyrat më e përgjithshme (higer-level) që duhet të kryejë softueri.
❑Identifikoni grupin e nënfunksioneve
▪ identifikoni grupin e nënfunksioneve për funksionet të nivelit-lart, pyesni veten se cilat janë detyrat ose
funksionet që duhet të bëni menjëherë përpara funksionit më të përgjithshëm.
❑Identifiko nën-funksionin e nivelit tjetër
▪ nënfunksioni që keni identifikuar në hapin 2, duhet të përsosni secilin prej tyre. Ju duhet të
identifikoni nënfunksionet e tyre.
❑Kontrollo FDD-në
▪ ekzaminoni me kujdes diagramin (FDD-diagrami i dekompozimi funksional). Sigurohuni që mos keni
lënë ndonjë funksion që mund të përfshihet në diagram.

Procesi i dekompozimi (zbërthimit) funksional…
❑Hapi 1.
▪ Cili është funksionimi i biznesit? Vizatoni nivelin e lartë
❑Hapi 2.
▪ Nga çka përbëhet ky funksion biznesi?
❑Hapi 3.
▪ Për secilën nga kutitë e nivelit të parë pyesni:
▪ Nga se përbëhet ky funksion?
▪ Vizatoni kutitë e nivelit tjetër. Përsëriteni për
nivele të mëtejshme sipas nevojës.

❑Nderlidhja mes moduleve
▪ Për të zbatuar funksionalitetin e një moduli, ai
ndonjëherë duhet të përdorë interfeisa të moduleve të
tjera.
▪ Moduli që përdor një modul tjetër nëpërmjet interfeisit së tij

ka një varësi nga ai modul tjetër. Sa më pak varësi, aq më mirë.
▪ Moduli B1 ofron interfeis B në modulin A dhe kërkon

interfeisa C dhe D.

❑Referimi grafik i zbërthimi të moduleve dhe simbolet përkates.
M3
M1 M4
M2
M8 M7
M8
aplikacioni

UML component diagrams model systems
from the perspective of components
(components), interfaces (lollipops and
sockets), and dependencies:

zbërthimi i moduleve mund të abstragohet në një pemë granulariteti

DDD: qasja e Dizajnit të Orientuar në Domen
❑ Ka 3 qështje që duhet kuptuar shumë qartë :
▪ Çfarë është Domeni ynë
▪ Cilat janë nën-domenet tona
▪ Cilat janë kontekstet tona të kufizuara (Bounded Context)
Ndarja e modeleve komplekse dhe të mëdha

në BC të veçanta
▪ Konteksti kufizues (BC) ndahet nga një vijë kufizuese të plotë
▪ Nën-domenet ndahen me vija të nderprera
▪ Asocimi i Konteksteve të ndryshme është referncuar me viza të plota (Context map)

DDD: qasja e Dizajnit të Orientuar në Domen…
Service ❑Domeni analizohet sipas qasjes top-down
Project ❑DDD ofron:
▪ Mjetet e Dizajnint Strategjik
Layers
▪ Mjetet e Dizajnint Taktik
Modules
Design Domain (e-commerce)
Patterns
Sub-domain Sub-domain Sub-domain
OOP
PAYMENT CUSTOMER SHIPPING
Service Service
classes Service
Service Service
Service
objects
exe / jar / zip

Një domen mund të ketë më shumë nën-domenet të cilat mund të
ketë shumë shërbime (service) që formojnë infrastrukturën e tyre.
Konteksti i kufizuar (Bounded Context)
❑ Bounded Context: DDD e organizon kodin përgjatë kufijve të përcaktuar mirë.
▪ vend që të keni një model të madh për domenin, ju keni shumë modele më të vegjël që definohen mirë
dhe kanë kufij të veçantë, të cilët duhet të inkapsulohem.
▪ Konteksti i kufizuar (BC) është ndarja natyrore brenda një biznesi / domeni / nën-domeni.
▪ BC paraqesin kufijtë e përgjegjësive të përcaktuara të entiteteve brenda këtij konteksti që nuk varen
nga konteksti tjetër ? Bounded Context
Kontekstet e kufizuara kanë të bëjnë me definimi e Shipping

Bounded Context
terminologjisë brenda kontekstit. Order Recipient
Every model is tied to a context Bookstore
Courier
p.sh, Kontekstet: Shipping & Book-Store. Order Book
Recipient & Customer janë entiteti i njëjtë ne kontekste Customer
te ndryshëm.

DDD: qasja e Dizajnit të Orientuar në Domen: Shembull i Bounded Contexts
Le të imagjinojmë se duhet të dizajnojmë një sistem të menaxhimit të Studentit, ku studentët mund të regjistrohen në sistem
duke zgjedhur kursin e tyre në përputhje me rregullat, duke paguar tarifën për kursin dhe pastaj ata do të listohen në një grup,
si rezultat të Ligjëruesit/Trajnerët dhe Studentët njoftohen për grupin data e fillimit dhe koha e caktuar për fillimi e ligjeratave
ne Kurs.
Si arkitekt, ju duhet të identifikoni kontekstin e kufizuar të domain’ve të ndryshme që lidhet me këtë logjikë biznesi. Nëse e
ndajmë logjikën e biznesit bazuar në funksionalitetin e lidhur, mund të gjejmë katër funksionalitete themelore.
• Procesi i regjistrimit: I cili kujdeset për regjistrimin e studentëve.
• Sistemi i Pagesave: I cili do të procedoj tarifën e Kursit dhe do të publikojë online statusin e pagesës.
• Orari për grupin: Pas konfirmimit të pagesës, ky funksion kontrollon disponueshmërinë e ligjëruesit, disponueshmërinë e
grupeve dhe bazuar në atë, krijon një grup dhe cakton kandidatët ose azhurnon grup ekzistues me kandidatin.
• Sistemi i njoftimit: Ai do të njoftojë si ligjëruesit ashtu edhe studentët për kohën dhe informacionin e vendndodhjeve.
Pra, ka 4 kontekste të kufizuara:
• Regjistrimi,
• Pagesat,
• Orari dhe
• Njoftimi.
Tani le të identifikojmë se si secili modul i përcaktuat paraprakisht përfaqëson Modelet te Ligjëruesit, Studentit dhe Kursit.
Deri tani kemi parë që të njëjtat Objekte
domai’neve si Ligjëruesi, Studenti, Kursi kanë
kuptim të ndryshëm dhe funksione (use-cases)
për Kontekst të ndryshëm.
Kjo është bukuria e Kontekstit të Kufizuar

DDD: qasja e Dizajnit të Orientuar në Domen …
❑Një Bounded Context (BC) shkembejn inforamta/dhena nga kontekste e ndryshëm
përfundimisht do të sinkronizohet dhe duhet të komunikojën.
▪ D.m.th me Context Map neve përshkruajmë kontaktin midis modeleve / konteksteve.
▪ Context Map - ofron relacionet dhe varësitë e tyre teknike dhe organizative ndermejt Bounded Contexts.
❑ Context Map Paternat / Llojet e relacioneve mes BC:
▪ Shared Kernel (SK)
▪ Customer / Supplier (CS) or Consumer-Driven
▪ Conformist (CF)
▪ Anticorruption Layer (ACL)
▪ Separate Ways (SW)
▪ Open Host Service (OHS)
▪ Published Language (PL)
▪ Event Publisher (EP)

DDD: qasja e Dizajnit të Orientuar në Domen …
❑kontekstet e kufizuara (modulet e mundshme) duhet të ndërveprojnë me njëri-
tjetrin
▪ p.sh, ne zgjedhim modelin e integrimit klient/furnizues (customer/supplier).
▪ Prandaj, konteksti i faturimit (furnizuesi) duhet të sigurojë mjete që konteksti i marketingut (klienti)
të ketë qasje në të dhënat ose funksionet e kërkuara.

Shembull: skenarit të sigurimit (Insurance)
❑Rasti: Paternat e Context Map per komunikim mes konteksteve

shumbulli: rasti regjistrimi i studentëve në orarin e Ligjeratave
p.sh: Pamja Logjike
Modulet

Dizajni i disa Moduleve për sistemin SmartFridge
▪ p.sh Interface antariFamiljes/IStudenti d.m.th me simbolin referohemi interface se

Entiteteve në vend të moduleve (entiteteve) konkrete
▪ nënkupton klasat/objektet /entitetet/ që implementojnë interface
▪ Nuk është një interface mbrenda Modulit përkates
Për t’i qasur metodatve e interfaces, interfaca duhet të "implementohet" nga një klasë tjetër me
fjalën kyçe implements dhe metodat duhet të implementohen në klasën e cila trashëgon vetitë
e interfaces.

http://www.codingthearchitecture.com/blogentries/7.html

Referencat
❑ Software Engineering A Practitioners Approach by Roger Pressman,

Bruce Maxim
▪ Kapitulli 9, 10, 11

Pyetje
Faleminderit…!

Faza: Dizajni i Modelit të Klasës (UML Diagrami i Klasës)
R a m i z H OX H A
2020/2021

UML definon dy lloj të Diagrameve

Çfarë është një Klasë
❑ Një Klasë është një plan (template) për Një object është një instance e Klasës
objektin. E gjithë qëllimi i Dizajnit të
Orientuar në Objekt (OOD) nuk ka të bëjë
me objektet, ka të bëjë me klasat, sepse
ne përdorim klasa për të krijuar objektet.
❑ Në fakt, klasat përshkruajnë llojin e

objekteve, ndërsa objektet janë raste të
instancave të klasave.
▪ p.sh: Një qen ka atributet - ngjyra, emri, raca,
si dhe sjelljet – hece(), shkunet(), leh(), han().

Çfarë është një Klasë…
❑Një Klasë është një përshkrim i një grupi objektesh të gjitha me role të
ngjashme në sistem, i cili përbëhet nga:
❑Vetit strukturore (atributeve) definojn se çka mund të ‘i dim’ për objektet e
klasës
▪ Reprezentojn gjendjen e një objekti të klasës
▪ Janë përshkrime të veçorive strukturore ose statike të një klase
❑Sjelljes (operacione) definojn se çka "mund të bëjën" objektet e klasës
▪ Definojnë mënyre në të cilen objektet mund të ndërveprojn
▪ Operacione janë përshkrime të sjelljeve ose karakteristika dinamike të klasës

Përspektivat e Diagramit të Klasës në UML
❑Një diagram mund të interpretohet nga këndvështrime të ndryshme:
▪ Konceptual: paraqet konceptet Objektet e domenit (Klasa e Domaint)
▪ Specifikimi: fokusi është në interfaces e të dhënave abstrakte Objektet e Interfacave (ADTs) në
softuer.
▪ Implementimi: përshkruan se si klasa do të implementoj interface e tyre, Objektet e Entiteteve
❑Perspektiva ndikon në sasinë e detajeve që duhen furnizuar dhe llojet e
relacioneve që ia vlen të paraqiten.
▪ Emri i klasës është i vetmi informacion i detyrueshëm.

qasja e Orientuar në Objekte (OO Aproach)
❑Objektet janë abstrakte të botës reale ose entitetet të sistemit

Diagrami i Klasës në UML
❑ Në inxhinieri softuerike, një diagrami i klasës në UML (Gjuhë e unifikuar për modelim)
është diagrami që paraqet aspektin statik që përshkruan strukturën e sistemit duke paraqitur
klasat e sistemit, atributet e tij, operacionet (ose metodat), dhe lidhjet/relacionet ndërmjet objekteve.
▪ Diagrami i klasëve, ilustroni modelet e të dhënave për sistemet e informacionit, pa marrë parasysh sa e
thjeshtë ose komplekse janë.
▪ Klasat përfaqsojnë entitetet e botës reale ose koncepte të sistemit.
Klasa e objekteve - një grup

objektesh që ndajnë atribute dhe
sjellje të përbashkëta, nganjëherë i
referohemi si një klasë.

Reprezentimi i një Klasë (simboli).
❑Një klasë përshkruan një grup objektesh që kanë:
▪ karakteristika/veti të ngjashme (atributet),
▪ sjellje të ngjajshme (operacione),
▪ relacione të përbashkëta me objekte të tjera, dhe
▪ kuptim të përbashkët ("semantikë").
▪ Atributet: një pjesë e rëndësishme e të
dhënave që përmbajnë vlera që përshkruajnë
secilen instance (karakteristikat) të klasës.
▪ E quajtur edhe fusha, variabla, veti.
▪ Metodat: gjithashtu i quajtur operacion ose

funksione.
▪ Ju lejojnë të specifikoni ndonjë funksion të
sjelljes së klasës.

Diagrami i Klasës në UML: Rasti i kampusit të UBT’s
❑Rasti i studimit të kampusi Universitar (Kolegji UBT).
▪ Ne kemi nevoj të i paraqesimi (reprezentojm) gjërat e ndryshme që janë në sistem, këte mund te
e bejme duke përdorur klasët.
▪ Pra, çfarë ka në kampusin e një universiteti, ka shumë student, profesor, departamente, puntor
administrative, objekte/ndërtesat, salla labaratorike, etj.
▪ Atributet: një pjesë e rëndësishme e
të dhënave që përmbajnë vlera që
përshkruajnë secilen instancë të
Atributet
klasës.
studenti
puntori administrativ
▪ E quajtur edhe fusha, variabla, veti.
Profesori Ndërtesat/objektet
Metodat
▪ Metodat: gjithashtu i quajtur

operacion ose funksione.
▪ Ju lejojnë të specifikoni ndonjë
funksion të sjelljes së klasës.

Shembulli i Kodit i cili pasqyron klasën e Pacientit të
treguar me poshte.
ky është një pseudo-kod dhe jo në një gjuhë specifike.

Diagramet e Klases në UML: Vizibilitetit në një klasë
❑Specifikuesit e qasjes (dukshmëria) së anëtarëve/variableve.
❑Të gjitha klasat kanë nivele të ndryshme të qasjes,
varësisht nga modifikuesi i qasjes (dukshmëris).
✓Kemi nivelet e mëposhtme të qasjes me simbolet përkatëse:
Qasja në Klasë (OOP) UML simbole

Qasja public +
Qasja private -
Qasja protected #
Qasja package ~
Qasja static nënvizuar

Diagramet e Klases në UML: Vizibilitetit në një klasë…
Qasja në UML
Klasë (OOP) simbolet
Anëtarët (atributet) e të dhënave publike janë të qasshëm brenda klasës,
public +
jashtë klasës, nga çdokush
Anëtarët (atributet) e të dhënave private janë të qasshëm vetëm brenda
private -
klasës në të cilën janë dëfinuar
Variablat e mbrojtura (protected) janë atributet të qasshëm brenda klasës në
protected #
të cilën janë definuar dhe nga të gjitha klasat e fëmijëve të klasës
Anëtarët e të dhënave package mund të janë të qasshëm brenda klasës në të
packege ~
cilën janë definuar dhe gjithashtu brenda të gjitha klasave në atë paketë
Anëtarët e të dhënave statike janë atributet që shfrytzohet (ndahen) nga të
static nënvizuar gjithë objektet e klasës. Ekziston vetëm një kopje e anëtarëve të të dhënave
statike

Diagramet e Klasës në UML: Relacionet
❑Një relacion është një term i përgjithshëm që mbulon llojet e veçanta të
lidhjeve logjike të gjetura në diagramet e klasës dhe objekteve.
❑UML përcakton relacionet e mëposhtme:
Dependency
Inheritance
Realization

Shembull: Relacionet në një diagram të klasës.

Diagramet e Klasës në UML:
Relacioni i gjeneralizimi/trashigimia
▪ Trashëgimia/Inheritance nënkupton që atributet, operacionet dhe relacionet
e një klase të nivelit më të lartë (superklasa) trashëgohen nga-të
bëra në dispozicion - nga një klasë e nivelit më të ulët (nënklasa).
▪ Kështu, klasat e nivelit më të ulët janë "lloj" të klasave të niveleve më
të larta .
▪ Ky relacion është specifike për një qasje të

orientuar drejt objektit për zhvillimin e sistemeve
softuerike.

Relacioni i gjeneralizimi/trashigimia
public class Personi {
protected String emri;
private int nrLeternjoftimit;
protected int mosha;
public String adresa;
Gjeneralizimi/ public void setAdresa(String adresa) {

Trashigimia this.adresa = adresa;
}
public String getEmri() {
return emri;
}
}
public class Studenti extends Personi {
private String ID_Studenti;
private float notaMesatare;
private int kreditet;
private static int numroStudentet;
public void printInfo() {

System.out.println();
}
public float getkalNotaMesatare() {
return notaMesatare;
}
public void setInfo(String IDStudenti, String emri, float nm ) {
this.ID_Studenti = IDStudenti;
this.emri = emri;
this. notaMesatare= nm;
}
}

Agregimi & Kompozimi
❑Relacioni i agregimit në diagram të klasës.
▪ nëse relacionet midis dy klasave asocimi është i ngushtë,
atëherë ajo përfaqësohet nga agregimi, është kështu një
formë e veçantë e asociimit.
▪ Agregimi reprezenton një klasë që përmban një klasë tjetër.
o Fig, tregon relacionin “has a" ku një Kampusi ka
Ndërtesa.
▪ Agregim gjithashtu reprezenton kompozim d.m.th, një
klasë e përbërë nga një klasë ose shumë klasë public class Salla {
}
tjetëra. public class Ndertesa {
private Salla[] salla;
▪ p.sh, një ndertesë përbëhet apo kompozohet nga sallat }
public class KampusiUniversitetit{
(klasat që përbëjnë ndërtesen) }
private Ndertesa ndertesa;

Relacioni i varësisë (Dependency)
❑Një relacioni i varësiës tregon një relacion semantike midis dy ose më shumë
elementeve.
▪ Vartësia e OrariLëndes në Lënden ekziston sepse Lënda përdoret edhe për operacionin
futjes/shtimit dhe fshirjen/heqjes të orarit të lëndes (OrariLëndes).

Diagramet e Klasës në UML: Asocimi
❑Relacioni i asocimit në UML Diagram Klasës.
▪ Nëse dy klasa në një model duhet të komunikojnë me njëri-tjetrin, duhet të ketë lidhje midis tyre.
Një asocim tregon atë lidhje.
▪ Asocimi ndërmjet dy klasave tregon si objektet në një anë të një asociacioni "njohin" objekte në
anën tjetër dhe mund të dërgojnë mesazhe tek ata.
▪ Nëse një asocim është drejtuar, mesazhet mund të kalojnë vetëm në atë drejtim
▪ Nëse asocimi nuk ka drejtim(direkcion), atëherë lidhja ështe definuar si një lidhje dydrejtimesh
dhe mesazhet mund të kalojnë në të dy drejtimet
▪ Sipas paracaktimit (default), të gjitha relacionet duhet të drejtohen, përveç nëse kërkesat
kërkojnë lidhje dydrejtimesh.

Diagramet e Klasës në UML: Asocimi…
❑Fig tregon dy klasa, Departamenti dhe Doktori, asocohen me njëra-tjetrën.
▪ Të dy klasat e departamentit dhe doktorit “use" njëra-tjetrën.
▪ Një asocim është relacion më bazik dhe më i zakonshme

midis dy klasave në modelet e orientuara drejt objektit

Asociacionet & pjesamarrja
❑Ne mund të tregojmë pjesmarrjen e një asocimi duke shtuar pjesmarjen e
shumëfishta në vijën që tregon lidhjen.
▪ Numrat prane klasave tregojne se sa është pjesmarrja ne këtë lidhje.
▪ Shembulli tregon kur një student ka një ose më shumë instruktorë:
Vlera e tregusit në pjesmarrje Simbolet e vlerave te pjesmarrjes

0 zero/asnje instance
1 një instance të vetëm
* Vlere e pakufizuar int jo negative e instancës
0..1 zero 0 ose një instance të vetme
0..* zero 0 ose numer të pakufizuar (shume) të instancës
1..* një ose më shumë instanca
3..6 Rang i specifikuar
© 2019 UBT
▪ Shembulli 1: Tregon kur min një profesor ose më shumë udhëzon/udhëzojnë shumë student, po
ashtu studentët kan shumë lëndë për të i ndegjuar.
emri i rolit
Drejtimi një-kahësh
i asocimit
emri i lidhjes
asocimit
© 2019 UBT
Shembulli 2:
▪ Një profesor ligjeron 1 deri në 3 lëndë
▪ Secila lënd ligjerohet nga vetëm një profesor.
▪ Një student mund të merr/ndegjojë 1-6 lëndë.
▪ Një lëndë mund të ketë 15-120 student.
© 2019 UBT
public class Profesori {
private String ID_Profesori;
Private String emri;
private float paga;
}
public class Studenti {
private String ID_Studenti;
Private String emri;
private int kredit;
}
public class Lenda {

private String emriLendes;
private Profesori ligjerusi;
}
public class GrupiLigjerates {

private Lenda[] lende;
private Studenti[] student;
private Lenda[] profesori;
ArrayList<Lenda> lende = new ArrayList<Lenda>();

ArrayList<Studenti> Student = new ArrayList<Studenti>();
public GrupiLigjerates(){
lende = new Lenda[6];
student = new Studenti[120];
……
}
}

Asocim bazik vs Dependecy
❑Asocim bazik
▪ Shigjeta tregon drejtimin e lidhjes. Lidhja tregon se Libri e
njeh autorin e tij, por një Person nuk di për librat që ata
janë autor. Krijon asocim/lidhje bazike
public class Book {
private String name; public class Person {
private String publisher; private String name;
private ArrayList<Person> authors; private int age;
// constructor public Person(String initialName) {

this.name = initialName;
this.age = 0;
public ArrayList<Person> getAuthors() { }
return this.authors; public void printPerson() {

} System.out.println(this.name + ", age " + this.age + " years");
}
public void addAuthor(Person author) {
public String getName() {
this.authors.add(author); return this.name;
} }
} }

Asocim bazik vs Dependency
❑Dependency/Varësi
▪ Lidhja e tregon se ekzistenca e klases Libri (book) është e varur
nga klasa Personi (Person)
public class Book {
private String name;
Kufizohet sipas dependency
private String publisher;
private ArrayList<Person> authors; public class Person {
private String name;
// constructor private int age;
Public Book (ArrayList<Person> Authors, String name, String publisher ){
this.authors= Authors; public Person(String initialName) {
this.name= name; this.name = initialName;
this.publisher= publisher; this.age = 0;
} }
public ArrayList<Person> getAuthors() { public void printPerson() {

System.out.println(this.name + ", age " + this.age + " years");
return this.authors; }
}
public String getName() {
public void addAuthor(Person author) { return this.name;
}
this.authors.add(author); }
}
}

Identifikoni klasat / entitetet e biznesit
❑Identifikimi i klaseve:
▪ Analizo User Stories (tregimet e perdoruesit)
▪ Identifiko klasat
o Emrat → Klasa
o Mbiemrat → Attribute
o Foljet → Operacione (funksione, metoda)

Shembulli i diagramit të Klasës
RA S TI S TUD IMIT: S MA RT PA RG IN G – MOD UL I PAG E SA

Kujtojm: Fusheveprimi i projektit - Smart Parking
Smart Parking është dhënë një tender nga komuna e Prishtinës për zhvillimin e një sistemit “Smart
Parking”.
Aplikacion final do te ofroj mundësi për te rezervuar parkingun nga distanca duke përdorur një APP Mobile i
cili përdor service googl location. Parkingu mund te rezervohet nëse ka vend e lire varësisht nga adresa ku
dëshirojmë të mbërrijmë.
Qe nga fillimi konstatohet se kërkesat për aplikacioni janë te qarta. Por me klientin gjegjësisht komunën e
Prishtinës jemi pajtuar qe për arsye qe te ju afroj klientëve (vozitësve) mundësi për shfrytëzimi sa me te
shpejt te parkimit te vetuar me qe rast ne kem ofruar pjesërisht APP me disa funksione si shfaqja vizuale e
shtrirjes se parkingut përkatësish të hapësirave te lira (slloteve) njëkohësisht mundësi te pagesës ne
hyrje/dalje te parkingut.
Ky aplikacion do të mundësoj pagesën online dhe gjithashtu përfshinë funksionet si gjetja e lokacionit te
parkingut me te afere me hapësira të lira (sllote) dhe mundësi te plot te rezervimit nga distanca

Kujtojm : Smart Parking
❑ Duke u bazuar në rastin e studimit më larët janë idendifikuar emra në këto user stories: ❑ Përcaktimi i emrave
▪ 1. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut nga distanca.
▪ 2. Unë si vozitës dua te kem mundësinë e pagesës se parkingut. (entiteteve)
▪ 3. Unë si vozitës dua te kem mundësinë e anulimit te rezervimit te parkingut. ▪ Vozitesi
▪ 4. Unë si vozitës dua te kem mundësinë e listimit te rezervimeve te bera.
▪ Operatori i Parkingut
▪ 5. Unë si vozitës dua te kem mundësinë te shohë sllotet/vendet e lira/zena brenda parkingut.
▪ 6. Unë si vozitës dua qe sistemi te me dërgoj faturën per rezervimin e bere. ▪ Rezervimi
▪ 7. Unë si vozitës dua qe sistemi te me shfaqe lokacionin e parkingut me te afërt. ▪ Parkingu
▪ 8. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut edhe nëse nuk jam regjistruar. ▪ Pagesa
▪ 9. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut për vetura te ndryshme.
▪ 10. Unë si vozitës dua qe sistemi pas rezervimit te gjeneroj nje QR kod.
▪ Slloti/Vendi
▪ 11. Unë si operatori i parkingut dua te kem mundësinë te shohë rezervimet e bëra brenda ditës. ▪ Lokacioni
▪ 12. Unë si operatori i parkingut dua te kem mundësinë te shohë listën e pagesave te bera. ▪ Fatura
▪ 13. Unë si operatori i parkingut dua te kem mundësinë e regjistrimit/ndryshimit te slloteve/vendeve te
parkingut.
▪ Vetura
▪ 14. Unë si operatori i parkingut dua që sistemi te porta e hyrjes (gate) të verifikoj veturën përmes ▪ Sensori
skanimit të targës (sensori i verifikimit).
▪ Porta
▪ Targa

Kujtojm : Smart Parking…
❑ Idendifikim i foljeve në këto user stories:
▪ 1. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut nga distanca.
❑ Listimi i funksioneve (KF)
▪ 2. Unë si vozitës dua te kem mundësinë e pagesës se parkingut. ▪ rezervimit te parkingut nga
▪ 3. Unë si vozitës dua te kem mundësinë e anulimit te rezervimit te parkingut. distanca
▪ 4. Unë si vozitës dua te kem mundësinë e listimit te rezervimeve te bera. ▪ anulimit te rezervimit te parkingut
▪ 5. Unë si vozitës dua te kem mundësinë te shohë sllotet/vendet e lira/zena brenda parkingut. ▪ listimit te rezervimeve te bera
▪ 6. Unë si vozitës dua qe sistemi te me dërgoj faturën per rezervimin e bere.
▪ dërgoj faturën per rezervimin e
▪ 7. Unë si vozitës dua qe sistemi te me shfaqe lokacionin e parkingut me te afërt.
bere
▪ 8. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut edhe nëse nuk jam regjistruar.
▪ 9. Unë si vozitës dua te kem mundësinë e rezervimit te parkingut për vetura te ndryshme.
▪ shfaqe lokacionin e parkingut
▪ 10. Unë si vozitës dua qe sistemi pas rezervimit te gjeneroj nje QR kod. ▪ shohë sllotet/vendet
▪ 11. Unë si operatori i parkingut dua te kem mundësinë te shohë rezervimet e bëra brenda ditës. ▪ gjeneroj nje QR kod
▪ 12. Unë si operatori i parkingut dua te kem mundësinë te shohë listën e pagesave te bera. ▪ shohë rezervimet
▪ 13. Unë si operatori i parkingut dua te kem mundësinë e regjistrimit/ndryshimit te ▪ shohë listën e pagesave
slloteve/vendeve te parkingut.
▪ regjistro sllotet/vendet te
▪ 14. Unë si operatori i parkingut dua që sistemi te porta e hyrjes (gate) të verifikoj veturën përmes
skanimit të targës (sensori i verifikimit). parkingut
▪ ndrysho te sllotet/vendet te
parkingut
▪ skano i targen e vetures

Kujtojm: definimi i Moduleve - Smart Parking
▪ p.sh Entitetet IOperatori i parkindur, iKlenti, iPaguesi, iParkingu,

iRezervimi etj - këto simbole të entiteteve reprezentojn
(referencojn) modelin e entitetit të relacionit
(lidhjes/nderveprimt) me modulin refrencues.
▪ nënkupton klasat/objektet /entitetet/ që implementojnë

interface

Rasti studimit 1: Smart Parking
diagrami i klasës për modulin Pagesa

Klasa IRezervimi
Përmban modelin e
nevojshme të Modulin
Rezervimi
në Modulin Pagesa

Klasa Paguesi
Përmban modelin e
Përdoruesi/Entiteti Paguesi
në Modulin Pagesa

Klasa iKartelBankes
Përmban modelin e
Përdoruesi/Servisi Bankes
KartelaBankes
në Modulin Pagesa

Klasa Pagesa (agregatoti)
Përmban modelin e
nevojshme të Entitetit
agregatorit Pagesa
në Modulin Pagesa

Klasa Pagesa (Servisi)
Përmban modelin e
nevojshme të servisit
Pagesa
në Modulin Pagesa

Klasa Fatura
Përmban modelin e
nevojshme të Entitetit
Fatura
në Modulin Pagesa

Rasti studimit 1: diagrami i klasës për modulin Pagesa - Smart Parking
Detajet e diagramit
të Klasës
modulin Pagesa

Shembull tjere të diagrameve të klases dhe relacioneve mes tyre

Identifikoni klasat / entitetet e biznesit….
❑Me nënviza identifikohen emrat, mbiemrat dhe foljet nga User Stories.
Card:
Une si anëtarë i familjes duhet të kem mundësi të regjistrimin e produkteve ne sistem.
Conversation:
1. Kush ka mundësi ti regjistroj produktet?
Secili anëtar i familjes i cili ka llogari ne sistem mund të shtoj produkte.
Çfarë informata i nevojiten për produktin ?
Nevojiten të jepen emri i produktit, data e skadimit, kategoria dhe çmimi.
2. Ku realizohet ky proces?
Procesi realizohet ne mobile aplikacion dhe pastaj shtohet ne sistem.
Confirmation:
Given: Anëtari i familjes është i regjistruar në sistem (ka llogari)
When: Anëtari i familjes kyçet në sistem
And: Zgjedh opsionin ‘Regjistro produktin’
Given: Hapet dritarja ku plotësohen të dhënat për produktin
Then: Kur të dhënat e produktit shtohen si emri, data e skadimit, kategoria dhe çmimi.
When: Anëtari i familjes klikon butonin ‘Ruaj’
Then: Produkti regjistrohet në sistem
And: Anëtarit të familjes i bëhet konfirmimi që produkti është ‘Regjistruar me sukses’

Identifikoni klasat / entitetet e biznesit….
Card:
Une si anëtar i familjes duhet të kem mundësi të shtimit të produkteve ne frigorifer.
Conversation:
1. Cilat produkte mund t’i shtojmë në frigorifer?
Poroduketet të cilat janë paraprakisht të regjistruara.
1. Kush mund të bëjë shtimin e produkteve në frigorifer?
Të gjithë anëtarët e familjes të cilët kanë llogari në sistem
1. Si evidentohet shtimi ne frigorifer?
Sensoret ne dere të frigoriferit skanojnë kodin e produktit, e konverton ne një
identifikues, pastaj e shton produktin ne frigorifer dhe e shton sasinë përkatëse.
Confirmation:
Given: Anëtari i familjes është i regjistruar në sistem (ka llogari)
When: Anëtari i familjes kyçet në sistem
And: Zgjedh opsionin ‘Shto produktin’
Given: Hapet dritarja ku shfaqen të gjitha produktet të cilat janë të regjistruara paraprakisht.
Then: Anëtari i familjes zgjedh produktin përkatës
Given: Sensorët bëjnë leximin (skanimin) e barkodit
Then: Shfaqen të dhënat për produktin
Then: Anëtari i familjes konfirmon produktin e shfaqur
Then: Produkti shtohet në frigorifer

Dizajni i disa Moduleve për sistemin SmartFridge
▪ p.sh Interface antariFamiljes/IStudenti d.m.th me simbolin referohemi interface se

Entiteteve në vend të moduleve (entiteteve) konkrete
▪ nënkupton klasat/objektet /entitetet/ që implementojnë interface
Për t’i qasur metodatve e interfaces, interfaca duhet të "implementohet" nga një klasë tjetër me
fjalën kyçe implements dhe metodat duhet të implementohen në klasën e cila trashëgon vetitë
e interfaces.

Diagrami i disa moduleve dhe klaseve
në aplikacionin SmartFridge

Diagrami i disa moduleve dhe klaseve në aplikacionin SmartFridge….

shembuj: të klasës së studentëve
të klasën e domenit dhe të diagramet i dizajnit të klasës

llojet e asociacionev që mund të kemi në diagramet e Klasës

Shembull: një klase asociative në të cilën një seksion i veçantë përcakton
relacionet midis
Studentit dhe një Kursi
Studenti dhe Kursi kanë një relacion shumë-me-shumë, e cila

zgjidhet duke shtuar një klasë asocuar të quajtur Seksion midis
klasave Studenti dhe Kursi.
Diagrami ilustron një relacion të quajtur Seksion, e treguar me një

linjë të ndërprer të lidhur të shumë-me-shumë linja relacionesh

Një Agregacion përshkruhet shpesh si një relacion "ka një (has a)".
Agregacioni ofron një mjet për të treguar se i gjithë objekti është i përbërë
nga shuma e pjesëve të tij (objekte të tjera).
Në shembullin e regjistrimit të studentëve, departamenti ka një kurs dhe
kursi është për një departament.
Ky relacion është një relacion më e dobët, sepse një departament mund
të ndryshohet ose hiqet dhe kursi mund të ekzistojë ende. Diamanti në
fund të linjës së relacioni nuk është plotë (jo i mbushur).
Një Agregacion
Kompozimi (Përbërja), një relacion tërësa/pjesës në të cilën e tërë ka një përgjegjësi

për pjesën, është një relacion më e fortë dhe zakonisht tregohet me një diamant të
mbushur.
Nëse i tërë është fshirë, të gjitha pjesët fshihen. Për shembull, ekziston një relacion
midis asigmenti (detyre) dhe një kursi, si dhe midis një kursi dhe një provimi. Nëse
kursi është fshirë, asigmenti dhe provimi fshihen gjithashtu.

Një gjeneralizim përshkruan një relacion midis një lloji të përgjithshëm të
gjërave dhe llojeve më specifike të gjërave. Ky lloj relacioneve është
përshkruar shpesh si një relacion "është një (is a)".
P.sh, një makinë është një automjet dhe një kamion është një automjet, në
këtë rast, automjeti është një gjë gjenerale, ndërsa makina dhe kamioni janë
gjërat më specifike.
Trashëgimia. Disa klasa mund të kenë të njëjtat atribute dhe/ose

metoda. Kur kjo ndodhë, krijohet një klasë e generale që përmban
atributet dhe metodat e përbashkta. Klasa e specializuar trashëgon ose
merr atributet dhe metodat e klasës së gjenerale.
Përveç kësaj, klasa e specializuar ka atribute dhe metoda që janë unike

dhe të përcaktuara ose definuar vetëm në klasën e specializuar

Diagrami i Klases
për FloorPlan

Diagrami i klasës në UML, Rasti i blerjës online

Diagrami i klasës në UML, Rasti i GUI-it

Kur përdoret diagramet e klasës
❑Sa herë që doni të modelit/dizajnoni për gjërat në një sistem, dhe se si ato
lidhen me njëri-tjetrin (i quajtur nganjëherë modelimit të dhënave).
❑Jep një pamje të përqëndruar në të dhëna të dobishme për:
▪ Planifikimi i klasave që nevojiten në OOP
▪ Vendimarrje mbi skemën për bazat e të dhënave
❑Por keni kujdes që të mos anashkaloni në detaje!
▪ E zakonshme për të injoruar disa aspekte
▪ P.sh. Modelimi e Klasve dhe asociacionet, por jo veti (atributet) ose operacione

Pyetje
Faleminderit…!

Referencat
❑Kapitulli 10: Systems analysis and design 8 Ed. By Kenneth E. Kendall
❑ Kapitulli 5: Software Engineering. 9th ed. By Ian Sommerville

UML Diagrami i Aktiviteteve
R a m i z H OX H A
2020/2021

UML Unified Modelling Language
❑Gjuha e modelimit e unifikuar (UML) është një standard i simboleve në
industri për dizajnimin e sistemeve të orientuara në objekti, i mbështetur nga
Grupi i Menaxhimit të Objekteve (OMG).
❑UML-i është duke u adoptuar gjerësisht në shumë fusha të softuerit dhe

komunitetit të zhvillimit të sistemeve kompjuterike.

UML’i definon dy lloj të Diagrameve

Gjërat
Diagramet e UML në
dizajnimin e softuerit
Relacionet
▪ Gjërat (Things),
▪ Relacionet
(Relationships), and
▪ Diagramet (Diagrams)
Diagramet

Diagramet e UML në dizajnimin e softuerit…
Definimi ose përcaktimi i

Diagrami i rastit të përdorimit
Kërkesave Use Case Diagram
Strukturimi i Diagrami i Klases

Sistemit Class Diagram
Diagrami i Aktivitetit (Activity Diagrams)

Specifikimi i Diagrami i Sekuencës (Sequence Diagrams)
Sjelljeve në Sistem Interaction Diagrams
State Charts
(+ CRC cards)
Diagramet e UML në
dizajnimin e softuerit…

Diagramet e UML në
dizajnimin e softuerit…

Diagramet e UML në dizajnimin e softuerit…
Një pamje e përgjithshme e diagrameve të UML-it

Diagramet e Aktivitetit

Qëllimi i përdorimit të Diagramit të Aktivitetit
❑Arsyeja kryesore për të përdorur diagramet e aktivitetit është të modelojë
rrjedhën e punës të sistemi që është duke u dizajnuar.
▪ Diagramet e aktivitetit tregojnë renditjen e aktiviteteve në një proces, duke përfshirë
aktivitetet sekuenciale dhe paralele, dhe vendimet (kushtet) që bëhen.
▪ Një diagram aktiviteti zakonisht krijohet për një rast të përdorimit dhe mund të tregojë
skenarë të ndryshëm të mundshëm.
→Diagramet e aktivitetit nuk duhet të zëvendësojnë diagramet e ndërveprimit

dhe diagramet e gjendjës.
→Diagramet e aktivitetit nuk japin detaje se si sillen objektet ose se si
bashkëpunojnë objektet.

Qëllimi i përdorimit të Diagramit të Aktivitetit…
❑ Diagramet e aktivitetit mund të përdoren për qëllime të ndryshme:
▪ Analizimi dhe përshkrimi/vizatimi i proceseve
▪ Dokumentimi i rrjedhave të punës
▪ Paraqitjej e algoritmeve në mënyrë grafike
▪ Modelimi i hapave të rastit të perdorimit (Use cases)
▪ Modelimi i aspekteve sjelljeve të softuerit - metodave, shërbimeve (services)

Elementet/simbolet e Diagramit të Aktivitetit
❑Elementet e digramit të Aktivitetit

Simbolet përshkrimi Simbolet në një diagram të aktivitetit
Një aktivitet paraqet, ose një proces manual, siç është nënshkrimi i një dokumenti ligjor ose një
proces automatizuar, si një metodë ose një program.
Një shigjetë përfaqëson një ngjarje. Ngjarjet përfaqësojnë gjërat që ndodhin në një kohë dhe vend të
caktuar. Shigjeta përfaqësojnë drejtimin e rrjedhës në diagram. Pikat drejtimi i shigjetës paraqet/
tregon progresin e aktiviteteve
Një diamant përfaqëson ose një vendim (i quajtur edhe një degë) ose një bashkim. Vendimet kanë një
shigjetë që hyn në diamant dhe disa që dalin. Mund të përfshihet një kusht që tregon vlerat e
gjendjes. Bashkimet tregojnë disa ngjarje që kombinohen për të formuar një ngjarje.
Një drejtkëndësh i rafshët dhe i gjërë përfaqëson një shirit të sinkronizimit. Këto përdoren për të
treguar aktivitete paralele, dhe mund të kenë një ngjarje që futet në shiritin e sinkronizimit dhe disa
ngjarje që dalin prej saj, të quajtur një pirun (FORK)
Një sinkronizim në të cilin disa ngjarje që shkrihen/rezultojn në një ngjarje quhet një bashkim
(JOIN)
Ka dy simbole që tregojnë fillimin dhe fundin e diagramës. Fillimi shfaqet si një rreth i mbushur.
Gjendja përfundimtare shfaqet si një rreth i zi i rrethuar nga një rreth i bardhë.

Elementet/simbolet e
Diagramit të Aktivitetit…

Rast studimi: Procesi i zgjimit në mëngjes
❑Me një partner vizatoni një diagram për të kapur procesin e mëposhtëm (sikur
ta përshkruani në mënyrë grafike):
“Ju jeni duke fjetur në shtrat, priteni për alarmin tuaj. Kur
përfundon alarmi ju zgjoheni, vishuni dhe zbriseni në katin e
poshtëm. Ju pregaditeni pak mëngjes dhe përderisa ju hani
mengjesi ju gjithashtu lexoni gazetën e mëngjesit. Kur të mbaroni,
largoheni nga shtëpia.”

Rast studimi: Procesi i zgjimit në mëngjes…
❑Definimi i elementeve të diagramit te Aktivitetit
❑Cilat ishin karakteristikat e diagramin tuaj?
▪ Veprimet ose Ngjarjet (Actions or Events )

▪…

❑Definimi i elementeve të diagramit te Aktivitetit
❑Cilat ishin karakteristikat e diagramin tuaj?
▪ Veprimet ose Ngjarjet (Actions or Events )
▪ Sekuenca
▪ Paralele
▪ Një Start dhe Stop
▪ Vendimet’kushtet
▪ Ndarjet logjike?

❑UML ekuivalent me një FlowChart
▪Ofron një pamje të nivelit të lartë të asaj që po ndodh brenda një
Rasti të Përdorimit (use Case)
▪(Është një variant i një Diagrami të gjendjës në UML)

❑UML-Diagramet e Aktivitetit është e bazuar në:
▪ Aktivitetet
▪ Lidhjet me tranzicione
▪ Me një Start dhe një Stop
Start Aktiviteti tranzicion Aktiviteti Stop
zgjoheni Visheni

❑Pikat e vendimeve (degët) janë shënuar me simbolin e diamantit
▫ Një degë ka një përshkrim opsional
▫ Tranzicionet nga një dege janë emërtuar (kushtet)
Dega
Alarmi
Pret alarmin ndalet? Zgjohet
[PO]
[JO]

❑Shiritat (Forks dhe Joins)
▪ Përdoret për të treguar si gjërat ndodhin paralelisht
▪ Ose për të sjellë së bashku disa tranzicione
Fork Join
Han
mengjesin
Pregadit Largohet nga
mengjesin shtëpia
Lexon
gazeten

❑Vendosja e gjithe elementeve per rastin
[PO]
Alarmi
Pret alarmin ndale Zgjohet Visheni
?
[JO]
Shkon poshtë
Han
mengjesin
Pregadit Largohet nga
mengjesin shtëpia
Lexon gazeten

Përdorimi i Swimlanes
❑Swimlanes ndajn një diagram
▪ Përdoret për të treguar fusha të ndryshme logjike
❑Diagramet shpesh mund të ndahen në mënyra të ndryshme
▪ Sipas një Faze
▪ Sipas Aktorit
▪ Sipas Departamentit
❑Nuk ka asnjë mënyrë e drejtë
▪ Ndarja në çdo gjë që është mënyra më e dobishme

❑Përdorimi i Swimlanes
[PO]
Alarmi
Pret alarmin ndale Zgjohet Visheni
?
Lartë
[JO]
Shkon poshtë
Han
Poshtë
mengjesin
Largohet nga
Bënë mengjesin
shtëpia
Lexon gazeten

Shembull 2: Tërhiqni para nga një llogari bankare nëpërmjet ATMs (rasti i përdorimit)
UC_ID : UC_02
TITULLI/ UC EMRI: Tërhiqni para nga ATM (klienti ynë bankar)
ACTORI KTYESOR: Klienti ATM/Bankomat (Kosumatori)
AKTORIT E DYTË: ATM (BANKOMATI), Banka
PËRSHKRIM I SHKURTËR: Klienti ATMs tërheq fonde nga një makinë ATMs
PARAKUSHTI: Klienti ynë bankar duhet të ketë kartë bankare
TRIGGER: Përdoruesi fillon transaksionin duke futur një kartë bankare
SKENARIA KRYESORE:
1. Klienti fut kartën në ATM.
2. Klienti shton PIN.
3. Banka validon PIN (Autorizon).
4. Klienti shton/fut shumën e dëshiruar
5. Bank verivikon Bilancin e llogarisë
6. Klienti merr para nga hapsir/slot
7. Llogaria e debitimit përditësohet
8. ATM shfoq Bilancin e llogarisë
9. ATM nxjerr jasht Karta e kreditit
10. Klienti merr kartën
11. Rasti i përdorimit përfundon.
ZGJERIMI (EXTENSIONS): (Shënim: shpesh zgjerimet janë komplekse. )
3a. Nëse PIN i pavlefshëm “Nxjerr kartën" (shiqo UC_RejectCard)
5a. Nëse Klienti nuk ka fonde të mjaftueshme, ATM tregon Bilanci që klienti do të mund të
tërheqë dhe Skenari rifillohet në hapin 4.
5b. Nëse Klinto ka më pak para në llogarinë e tyre sesa shuma minimale që mund të
financojë makina, atëherë ATM shfaq një mesazh që tregon se karta është nxjerrë.

Përdorimi i Swimlanes
Activity diagram for:

withdraw money from a
bank account through an
ATM (use case)

Shembull 1: Konvertimi i diagramit të aktivitetit në Psudokod

Shembull 2: Kalkulimi i notes në Lëndën Inxhinieria Softuerike
UC_ID : UC_10
Titulli/UC EMIR : Kalkulimi i notes në Lëndën Inxhinieria
Softuerike
AKTORI PRIMAR: Profesori (RAMIZ HOXHA)
PËRSHKRIM I SHKURTËR: Profesori kalkulon noten
për lëndën Ixh.Sof duke i shtuar të dhënat e
aktivitetev përkatëse
KUSHT PARAPRAK: Studenit duhet të ketë prezencen
në ligjerata dhe ushtrime valide (>=75%)
TRIGGER/SHKAKU: Profesori follon kalkulimi e notës
SKENARIA KRYESORE ( I SUKSESIT):
Profesori shton pikët e kollekviumit_1, nëse pikët e
kollokviumit_1 të studentit ka arritur kushtin e
kualfikimit (kaluse, d.m.th K1>=15 pikë). Ather
profesori shton pikët e kollekviumit_2 po ashtu edhe
në këte K2 student duhët të i arri min 15 pikë
(K2>=15 pikë). Profesori shton pikët e projektit ku
nëse janë arritur min 20 pikë (P>=20 pikë) atëher
student kulifikohet për kalkulim të totalit të pikëve
duke vlersuar në notën perkatës. Po ashtu student
nëse nuk ka pasur sukses në K1 dhe K2 studenti
hynë direct në test final. Po ashtu në tesitn final
student duhët të i arrij min 30 pikë (TF>=30 pikë)
pastaj këto pikë i shtohen edhe pikët e projekti të
studntit pastaj kalkulohet nota.
Totali duhet të jetë min 50 pikë. Përndryshen hyn në
afatin e ardhshëm të provimit.

Shembulli: Life Insurance System Use Case Diagram

❑Actors
▪ Client
▪ Sales Agent
▪ Claims Adjuster
▪ Claims Clerk
▪ Insurance Underwriter
Register New Client for
❑Use Cases
Insurance ▪ Ask for insurance
(UML Activity Diagram) ▪ Offer insurance
▪ Evaluate client risk level
▪ Accept a client
▪ Reject a client
▪ Fill in claim details
▪ List in a new case
▪ Accept compensation
▪ Refuse compensation
▪ Determine the amount of
compensation
▪ Cancel the insurance
▪ Register client

Mangësitë e diagramit të Aktivitetit
❑Një disavantazh i diagrameve të aktivitetit është se ata nuk paraqesin në
mënyrë eksplicite cilat objekte ekzekutojnë cilat aktivitete, dhe mënyra se
mesazhi funksionon mes tyre.
▪ Etiketimi i çdo aktiviteti me objektin përgjegjës mund të bëhet.
▪ Është e dobishme të vizatoni një diagram aktiviteti në fillim të modelimit të një procesi, për të
kuptuar procesin e përgjithshëm.
❑Pastaj diagramet e ndërveprimit mund të përdoren për t'ju ndihmuar të

shpërndani aktivitetet në klasa.

Përmbjedhje
❑UML Diagramet e aktivitetit modelim i kontrollit të rrjedhjës
▪ Diagramet e Aktivitetit përfshijnë:
o Degëzimi (vendimmarrja)
o Piruni (fork) dhe Bashkim (Join) (aktivitete paralele)
o Swimlanes (ndarje logjike)
o Kur analizohet një rast përdorimi
o Cilat veprime ekzistojnë dhe kur ndodhin?
o Ky diagram nganjëherë quhet i kontrolli i rrjedhjës

Pyetje
Faleminderit…!

Referencat
❑Kapitulli 10: Systems analysis and design 8 Ed. By Kenneth E. Kendall
❑ Kapitulli 5: Software Engineering. 9th ed. By Ian Sommerville
Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 36

Konceptet në Testim të Softuerit
FAKULTETI: SHKENCA KOMPJUTERIKE DHE INXHINIERI

Kontenti
▪Konceptet e testimt të softuerit
▪Nivelet e testimit të softuerit
▪Llojet e testimit të softuerit

konceptet e Testimit të Softuerit
PJESA E PARË

Kujtojm: Faza e testimi në modelt e ndryshem
Modeli Linear-Sekuencial
Modeli Përsëritës (Iterative)

QA - Quality
Assurance
Sigurimi i Cilësisë
Modeli Rritës (Incremental)

Kujtojm: Faza e testimi në modelt e ndryshem…
Modeli RAD Modeli Spiral
Modeli RUP
Modeli
Prototipit

Kujtojm: Faza e testimi në modelt e ndryshem…
Modeli

Softueri është gjithëandej

Dështime të Softuerit
▪ 2017: 606 dështime të regjistruara të programeve kompjuterike, duke prekur 3.7 miliardë njerëz, 314
kompani, humbje financiare 1.7 trilion dollarë
▪ 2016: Nissan tërhoqi 4 milion makina nga tregu për shkak të dështimit të softuerit në detektorët ndijor të
kutisë së ajrit.
▪ 2016: Informacioni i humbur për shkak të butonit të mbrapa të shfletuesit gjatë
përdorimit të softuerit në internet TurboTax
▪ 2015: Dështimet e terminalit tregtar të Bloomberg detyruan qeverinë britanike të shtyjë
shitjen e borxhit prej 4,4 miliardë dollarësh
▪ 2014: Ndërprerja e Dropbox ishte për shkak të një faji në një skenar mirëmbajtjeje
▪ 2012: Fajet në një softuer të ri tregtar të Knight Capital shkaktojnë 440 milion dollarë
▪ 2003: Ndërprerja verilindore për shkak të sistemit të alarmit në dështimin e sistemit të
menaxhimit të energjisë, duke prekur 40 milion njerëz në 8 shtete të SH.B.A.-së, 10
milion njerëz në Ontario, Kanada
1999:
▪Ramiz HOXHA Toka Mars në NASA u rrëzua për shkak© 2021 UBT të një faji të integrimit në njësi 8
Pse duhët të Testojmë
water
car test
test
spicy
food
Buss crashes

Testimi në shekullin e 21-të
✓Softuer kritik i sigurisë, në kohë reale
✓Softueri i ngulitur (embedded)
✓Aplikacionet e ndërmarrjeve
✓ Aplikacion platforma për Siguri
✓Ueb aplikacione
✓Aplikacione mobile
Testimi i softuerit po bëhet më i rëndësishëm
Çfarë po përpiqemi të bëjmë kur testojm..?

Cilat janë qëllimet tuaja…?

Shembull i gabimeve të thjeshtë
public static int numZero (int[] arr)
{ // Efektet: Nëse arr is null throw NullPointerException
// else return the number of occurrences of 0 in arr
int count = 0;
for (int i = 1; i < arr.length; i++)
if (arr[i] == 0)
count++;
return count;
}
❑Ekziston një gabim i thjeshtë në numZero
❑Ku është vendndodhja e gabimit në kodin burimor??
❑Si do të rregullohet?
❑A mund të arrihet vendndodhja e gabimit? Si sillet programi i korruptuar? A e korrupton gjithmonë
gjendjen e programit?
❑Nëse gjendja e programit është e korruptuar, dështon numZero? Si?

Shembull i gabimeve të thjeshtë…
{ // Effects: If arr is null throw NullPointerException
int count = 0;
if (arr[i] == 0)
count++;
return count;
}
❑Fault: një defekt në kodin burimor
i = 1 [duhet të fillojnë kërkimin në 0, jo në 1]
❑Error: gjendje e gabimi në program është shkaktuar nga ekzekutimi i defektit
Bëhet 1 [hyrja në varg 0 nuk lexohet kurrë]
❑Failure: Përhapja e gjendjës së gabuar rezulton në dështim (failure) të programit
(aplikacionit)
Ndodh përderisa arr.length > 0 dhe arr[0] = 0

Shembull i gabimeve të thjeshtë…
{ // Effects: If arr is null throw NullPointerException
int count = 0;
if (arr[i] == 0)
count++;
return count; Fault: i = 1 [duhet të fillojnë
} kërkimin në 0, jo në 1]
❑Test 1: [4, 6, 0], pritet 1
Error: i është 1, jo 0, në iteracioni e parë
Failure: asnjë
❑Test 2: [0, 4, 6], pritet 1

Error: i është 1, jo 0, gabimi përhapet në ndryshore count
Failure: count është 0 në gjendjen e kthimit

Motivi për të testuar softuerin:
Si shpërndahet kostoja për Projktin?
Kostoja e zhvillimit të softuerit
❑Është interesante të dimë cilat faza të një projekti Analiza dhe

dizajni 33%
(zhvillimit të softuerit) kushtojnë më shumë para? Testimi 50,%
Figura 1.1 paraqet shifra tipike.
❑Është e qartë se kostoja e testimit është e madhe,

ndërsa kodimi përbën vetëm një pjesë të vogël të Kodimi, 17%,
zhvillimit të softuerit.
Analiza dhe dizajni Kodimi Testimi
Fig. 1.1 Shpenzimet relative të fazave të zhvillimit të softuerit

ku ndodhin gabimet në Projkt?
Gabimet të bëra sipas fazave
❑Nëse gabimet janë një problem i madh, kur bëhen Sintaksa
17%
ato? Figura 1.2 tregon shifrat duke treguar numrin e
gabimeve të bëra në fazat e ndryshme të një projekti:
Kodimi dhe
❑Megjithatë, këto të dhëna janë mjaft relative logjika
33%
Dizajnimi
50%
Dizajnimi Kodimi dhe logjika Sintaksa
Fig. 1.2 Numri relativ i gabimeve të bëra gjatë fazave të zhvillimit të softuerit

shpenzimet e rregullimit të softuerit?
❑Ajo që ka rëndësi është se sa kushton për të rregulluar një gabim.
❑Dhe sa më gjatë që gabimi të mbetet i pazbuluar, aq më shumë shpenzimet
do të kemi për të i rregulluar këto gabimet.
Kostoja relative për të rregulluar,
bazuar në kohën e zbulimit
35
30
25
20
15
10
5
0
Kodimi
Komponenteve
kërkesave dhe
Testimi i Sistemit
Pas-Implementimit
ose Integrimit
Arkitektura
ose Pranimit
Analiza e
Testimi i
Mirmbajtja
Fig. 1.3 source: national institute of Standarts and Technology (USA)

Kostoja e Testimit të Vonëshem
Assume $1000 unit cost, per fault, 100 faults
50
40
Fault origin (%)
30
20 Fault detection (%)
10 Unit cost (X)

Motivi për të testuar softuerin: rasti në microsoft
❑Testimi konsumon në mënyrë tipike një proporcion të madh (ndonjëherë deri në ≈50%) të
punës për zhvillimin e një sistemi.
❑Microsoft-i punsonë ekipet e programuesve (të cilët programojn aplikacione) dhe

ekipet plotësisht të ndara të testuesve (të cilët i testojnë ato).
❑Në Microsoft ekzistojnë sa ka puntorë që programojn ka edhe po aqë puntorë të përfshirë

në testim.

Testimi I Softuerit (Software Testing)
Testing is the process of
exercising a program with the
specific intent of finding
errors prior to delivery to the
end user.
❑Don’t view testing as a “safety

net” that will catch all errors that
occurred because of weak
software engineering practice.

Validimi dhe Verefikimi (IEEE) V&V
❑Testimi modern përqendrohet kryesisht në dy gjëra:
▪ verifikimi dhe validimi (V&V)
❑Verifikimi përpiqet t'i përgjigjet pyetjes: "A e ndërtuam produktin
siç duhet?"
▪ Procesi i derteminimit nëse produkti në fazen e caktuar të procesit të
zhvillimit të softuerit përmbushin kërkesat e përcaktuara gjatë një faze.
❑Validimi përpiqet t'i përgjigjet pyetjes : "A kemi ndërtuar
produktin e duhur?"
▪ Validimi (Vlefshmëria): Procesi i vlerësimit të softuerit në fund të zhvillimit
të softuerit për të siguruar pajtueshmërinë me përdorimin e synuar
V & V qëndron për "verifikim dhe validim të pavarur”

Qëllimi i testimit të Softuerit
❑Qëllimet e Testimit të Softuerit:
▪ Të demonstrojë se softueri i plotëson kërkesat e tij.
▪ Të identifikoj në cilat sjellja e softuerit është e pasaktë ose e padëshirueshme.
❑Testimi i defekteve ka të bëjë me eleminimin e gjendjëve të padëshiruara të sistemit
të tilla si:
o rrëzimet (crashes) e sistemit,
o ndërveprimet e padëshiruara me sistemet e tjera,
o llogaritjet e pasakta dhe
o korruptimin e të dhënave
❑Shtimi i vlerave përmes testimit nënkupton ngritjen e cilësisë ose besueshmërisë së programit.
❑Rritjea e besueshmërisë së programit do të thotë gjetja dhe eleminimin e gabimeve.

Elementet bazë e procesit të Testimi të Softuerit
❑Testimi i softueri është nje aktivitet që kontrollon nëse rezultati

aktual përputhet me rezultatin e pritur dhe për të siguruar që dhe
sistemi softuerikë është pa defekte!!.

Elementet bazë e procesit të Testimi të Softuerit...
❑Testimi = proces i definimit së vlerave hyrëse (inpueve) për të
testuar kundër një softueri
❑Debagimi = proces i gjetjes së defekti ose defektëve, që ka rezultuar
në dështimin e softuerit
Test Rasti përbëhet nga vlerat e testimit dhe rezultatet e pritshme
vlerat e testit Rezultati Rezultati i

Programi vs pritshëm
(inputet) aktual
1. Testimi është në thelb rreth zgjedhjes së grupeve të caktuar të vlerave nga domeni i inputeve
të softuerit që testohet
2. Duke ofruar vlerat hyrse testues, krahasoni rezultatet aktuale me rezultatet e pritshme

Terme: Testimi, Test rasti dhe Plani i Testimit
❑Termat e testim dhe testit të rast përdoren në mënyrë të ndërsjellë.
Në praktikë, të dyja janë të njëjta dhe trajtohen si sinonime.
❑Rasti i testimit (Test Case) një grup i inputeve për testim, kushtet e
ekzekutimit dhe rezultatet e pritshme të zhvilluara për një funksion të
caktuar.
▪ p.sh; Të testohoet një path i caktuar i programit ose të verifikojnë pajtueshmërinë
me një kërkesë specifike.
❑Plani i Testimit - është pjesë e dokumentacionit të përgjithshëm të

projektit që përshkruan se çfarë, kur, si dhe kush do të përfshihet në
procesin e testimit.

Terment e referencimit të elementeve të aplikacionit
❑Unit (Njësia): testimi i njësive më të vogla mund të referencohemi (p.sh., funksioni, procedura,
moduli, klasa e objektit, etj.)
❑Komponenti: testimi i një koleksioni të njësive që përbëjnë një komponent (p.sh.,
programi, paketa, detyra, klasat e objekteve ndërvepruese, etj.)
❑Produkti: testimi i një koleksioni të komponenteve që përbëjnë një produkt (p.sh., nënsistemi,
aplikacioni, etj.)
❑Sistemi: testimi i një koleksioni të produkteve që përbëjnë një sistem të dorëzueshëm.

Kush duhet të bëjë Testimin?
❑Testimi kërkon që zhvilluesit të gjejnë gabime

nga softueri i tyre.
❑Është e vështirë për zhvilluesi i softuerit të
tregojë gabime nga krijimet (programet) e veta.
❑Shumë organizata kanë bërë një dallim në mes
të fazës së zhvillimit dhe testimit, duke i bërë
grupe/departamente të ndryshëm përgjegjës për
secilën faze/pjesë.

Nivelet e bazë te testimi të softuerit
❑Bazuar në komponenten e ndertimi të aplikacionit, ekziston nivelet e testimit të softuerit:
▪ Testimi i Njësis (Unit Testing)
▪ Testimi i Integrimit (Integration Testing)
▪ Testimi i Sistemit (System Testing)
▪ Testimi i Pranimit (Acceptence Testing)
nivelet e Testimi të Softuerit

Teknikat per ralizimin e testimit
❑Black-box testing and White-box testing
▪ Black-box testing > Behavioral testing.
▪ White-box testing > Structural testing.

Teknikat per ralizimin e testimit…
❑Çfarë është Testimi i Kutisë së Zezë (Black Box)?
❑Testimi i Kutisë së Zezë referohet si Testim i Sjelljes (Behavioral).
▪ Është një metodë e testimit të softuerit ku struktura / dizajni / implementimi i
brendshëm i elementi të testuar nuk është i njohur për testuesin.
▪ Është një metodë e cila përpiqet të gjejë një gabim në kategoritë e mëposhtme:
o Funksione të pasakta ose që mungojnë.
o Gabimet e interfases/ndërfaqes.
o Gabime në integrimin me një strukturë të dhënash ose qasjes të dhënash të jashtme.
o Gabimet e sjelljes ose performances
o .Gabimet e inicializimit dhe përfundimit.

Teknikat per ralizimin e testimit…
❑Çfarë është Testimi i Kuti të Bardhë (white box testing)?
▪ Testimi i Kutisë së Bardhë është një lloj teknike testimi që kryesisht shqyrton
strukturën e programit dhe nxjerr të dhëna të testit në bazë të logjikës ose kodit të
programit.
▪ Ai u referohej gjithashtu emrave si testimi i clear box testing, open box testing, logic-
driven testing dhe path driven testing ose structural testing.
❑Si funksionon Testimi i Kuti të Bardhë? Hapat për të kryer këtë Testim përmenden
si më poshtë në një renditje specifike -
o Së pari, të gjitha funksionet, komponentet dhe programet që do të testohen, identifikohen
së pari.
o Krijoni një grafik rrjedhës dhe identifikoni / vizatoni të gjitha shtigjet e mundshme në
grafikun e rrjedhës.
o Identifikimi i të gjitha shtigjeve të mundshme nga grafiku i rrjedhës.
o Shkruaj test rastet (test cases) për secilën rrugë të vetme të shtegut të rrjedhës.
o Ekzekutoni dhe përsëritni test rastet.

Testim Manual vs Automatizuar
❑Testim Manual vs Testim Automatizuar
❑Testimi mund të bëhet manualisht ose duke përdorur një mjet të
automatizuar të testimit:
▪ Manual - Ky test kryhet pa marrë
ndihmën e mjeteve të automatizuar të
testimit.
▪ Automated - Ky test është një
procedurë testimi e bërë me ndihmën
e mjeteve të automatizuar të testimit.
Ramiz HOXHA © 2019 KOLEGJI UBT 31

Testimi Statik dhe Dinamik
❑Testimi Statik : Testimi programi i pa-
ekzekutuar:
▪ Inspektimi i softuerit dhe disa forma
të analizës
▪ Efektive në gjetjen e llojeve të
caktuara të problemeve të tilla si
problemet që mund të çojnë në
gabime kur programi modifikohet
❑Testimi Dinamik: Testimi duke
ekzekutuar programin me vlera hyrse
(inpute) reale

Inspektimet dhe Testimet (testimi static)
❑Inspektimet softuerit- Ka të bëjë me analizën e aspektit statike të
sistemit për të identifikuar problemet (verifikim statikë ose testimi statik).
❑Testimi i Softuerit – Ka të bëje me ekzekutimin dhe obzervimin e
sjelljeve të produktit/programit (verifikimi dinamik ose testimi dinamik)
▪ Sistemi ekzekutohet me të dhënat për testim dhe obzervimin e operimit të sjelljeve

Testimi në zhvillim(Testimi Dinamik)
❑Testimi në zhvillim përfshin të gjitha aktivitetet testuese që kryhen
parimisht nga ekipi i zhvillimit të sistemit.
▪ Testimi i njësisë (Unit Testing), ku testohen njësitë individuale të programit ose klasat
e objekteve. Testimi i njësisë duhet të fokusohet në testimin e funksionalitetit të
objekteve ose metodave.
▪ Testimi i komponentëve (Component or Integration Testing), ku janë integruar disa
njësi individuale për të krijuar komponente. Testimi i komponentëve duhet të
fokusohet në testimin e interfaceve të komponentëve.
▪ Testimi i sistemit (System Testing), ku disa ose të gjithë komponentët në një sistem
janë të integruar dhe sistemi testohet në tërësi. Testimi i sistemit duhet të fokusohet
në testimin e ndërveprimeve të komponentëve.

Shembull: Testimit Static dhe Testimit Dinamik
❑Rasti: Shporta e blerjeve Online
❑Teknikat e testit statik:
▪ Rishikoni dokumentet e kërkesë, dokumentet e dizajnit konceptual
▪ Kontrollimi i GUI të aplikacionit
▪ Kontrollimi i strukturës së të bazës së të dhënave të aplikacionit.
❑Teknika të Testimit Dinamik:

▪ Testimi i funksionalitetit të faqes së ndryshme.
▪ Kontrollimi i procesit të checkout dhe mënyrat e pagesës.
▪ Testimi i ndërfaqeve midis faqeve të ndryshme.

Testimi i njësisë (Unit Testing)
❑Teston çdo modul individualisht.
❑Zbaton një testimi i teknikës së kutisë së bardh (logjikën e programit).
❑E implementuar ose ralizuar nga zhvilluesit.

Testimi i komponentëve
(Component ore Integration testing)
❑Sapo të gjitha modulet të jenë testuar sipas tëstimit të njësia, pastaj kryhet
testimi i integrimit/komponenteve.
▪ Është testimi sistematik.
❑Prodhoni teste për të identifikuar gabimet që lidhen me nderfaqet
(interfacing).
❑Llojet:
▪ Testimi i Integrimit; Big-Bang
▪ Testimi i Integrimit: Lartë-poshtë
▪ Testimi i integrimit; Poshtë-lartë
▪ Testimi i integruar: mix (hybrid)

Testimi i sistemit (Sistem testing)
❑Sistemi në tërësi është testuar për të zbuluar/identifikuar gabimet e
kërkesave.
❑Verifikon që të gjitha elementet e sistemit funksionojnë si duhet dhe se
funksionimi dhe performanca e përgjithshme e sistemit është arritur.
▪ Zbaton një testimi të teknikës së kutisë së Zezë (testimi funksional).
❑Llojet testimit të sistemit:

▪ Testimi i Alpha
▪ Testimi i Beta
▪ Testimi i Pranimit (acceptance)
▪ Testimi i Performancës

Teknikat/metodat e testimit Dinamik

Përmbledhje e Niveleve, Metotave dhe Llojeve të Testimi të Softuerit

Një model i procesit të Testimit të Softuerit

Terme: Mostra/Templata e rastit të Testimit
Emri i Dritares
Kalkulimi i Kredis
Screen Name
Përgatitur nga
Ramiz HOXHA Logo e Kompanis
Prepared By
Designation Test Analyst
Data
ID e Përshkrim i Skenarit
3.1 Verifikoni funksionalitetin e funksionit Kalkulimit te Kredis
Skenarit Scenario Description
ID Rastit Hapat e ID e
Përshkrim Rastit Testues Vlerat hyrëse Rezultati e Pritshme Rezultati Aktual Statusi
3.No Testues Testimit Defekti
Test Case Description Input Values Expected Result Actual Result Status
Test Case ID Test Steps Defect ID
Testimi për të kontrolluar
Name: John Term: 3 years
funksionalitetin e funksionit Shto: Emrin Term: 3 years
Smith Repayment: 79.86
të Kalkulimit te Kredis Shto: Acc No Repayment: 79.86
1 3.1.1 Acc No: 123456 Interest rate: 10% Kaloi/Pass
duke futur e të dhënave të Shto :Loan Interest rate: 10%
Loan: 2500 Total paid:
vlefshme në fusha të Shto :Term Total paid: 2874.96
Term: 3 years 2874.96
obligueshme
Testimi për të kontrolluar
Term: 3 years
funksionalitetin e funksionit Shto: Emrin Name: J Duhet të shfaqet në
Repayment: 79.86
të Kalkulimit te Kredis Shto: Acc No Acc No: 023456 error mesazh 'Ju lutem Nuk
1 3.1.2 Interest rate: 10%
duke futur e të dhënave të Shto :Loan Loan: 2500 shtoni te dhenat e Kalon/Fail
Total paid:
pa vlefshme në fusha të Shto :Term Term: 3 years rregulla'
2874.96
obligueshme

Përmbledhje: Pse e testojmë softuerin ?
❑Qëllimi i një testuesi është të eliminojë defektet sa më

shpejt të jetë e mundur.
❑Përmirësoni cilësinë
❑Ulja e kostos
❑Ruani kënaqësinë e klientit

Metodat e Testimit të Softuerit
(sipas kutisë së zezë dhe kutisë së bardhë)
PJESA DYTË

Metodat e Testimit të Softuerit
❑Të dy teknika themelore të testimit software, testimi sipas kutis së zezë
dhe testimi sipas kutis së bardhë
Metoda e testimit sipas kutis të bardhë Metoda e testimit sipas kutis të zezë

Testimi i sipas metodës së kutis së Zezë

Testimi i sipas metodës kutia e Zezë
(Black-box Testing) (1)
❑Testimi i kutisë së zezë. Testimi i softuerit bazuar në kërkesat funksionale
dhe të biznesit në funksionimin e tij pa njohuri të strukturës së brendshme ose
kodit burimor të programit.
❑Për shkak se testimi bëhet sipas kutis e zezë qëllimisht injoron strukturën e
kontrollit të programit, vëmendja është përqendruar kryesisht në sferën e
informacionit (p.sh., të dhënat hyrse- inputs dhe në të dhënat që dalin-
outputs)

❑Ekzistojnë katër teknika të bazuara në specifikacione ose teknika sipas kutisë
së zezë:
▪ Ndarjes së Klasës ekuivalente (Equivalence Class Partitioning)
▪ Analiza e Vlerës së kufirit (Boundary Value Analysis) Fokusuar në logjikën e biznesit
▪ Testimi i gjendjës/kalimit të Tranzacionit (State Transition Testing ) ose rregullat e biznesit
▪ Tabelat e vendimeve (Decision tables)
❑ Zgjidhja e mundshme do të ishte duke ndarë në

3 klasë të ndryshme:
▪ Klasa e vlerave pozitive
▪ Klasa e vlerave negative
▪ Klasa e vlerave të pavlefshme/invalide

❑Ndarjes së Klasës ekuivalente (Equivalence Class PartitioningAnalysis):
▪ Në këtë teknikë, ne ndajmë 'Sistemin nën Test' në numrin e klasave të ekuivalencës dhe
vetëm i testojm disa/min vlera nga secili klasë.
▪ Grupi i vlerave i të dhënave që japin një rezultat/dalje të vetme quhet 'ndarje' ose 'klasa', dhe
▪ Nëse softueri sillet në mënyrë të barabartë me inputet nga ajo klasë atëherë quhet
'Ekuivalencë'. Prandaj, termi Klasa Ekuivalente

❑Ndarjes së Klasës ekuivalente/Equivalence Class Partitioning(ECP):
▪ Zakonisht nuk është e mundur që të preformoj testimin e plotë për shkak të kohës ose
kufizimeve në buxhetin e projektit.
▪ Ndarjes së Klasës ekuivalente është teknikë shumë efektive e përdorur në testim, kjo form
zëvoglon numrin e të dhënave për të testuar në aplikacionin
Për të qenë më efikas në kohë dhe buxhet dhe për të mos testuar të gjithë numrat ndërmjet 1 dhe
12, numrat <1 dhe> 12, ne ndajini të dhënat e testimit në 3 grupe, së pari për ndarje të vlefshme
(klasa: 1 deri në 12, sekondë për ndarje të pavlefshme (<1) ndarje e pavlefshme (> 12)

❑Aplikimi ndarjës së klaseve ekujvalente (ECP):
▪ Sipas shembullit tonë të dhënat e testimit mund të ndahen në klasa të mëposhtme
…, -3, -2, -1, 0 1, 2, 3……., 12 13, 14, 15…..
Ndarja invalide 1 Ndarja valide Ndarja invalide 2

▪ Tani për të testuar aplikacionin testuesi mund të përdorin vetëm një numër nga secilen ndarje
▪ Pra, ne mund ta testojm aplikacionin me vetëm tre numra (nga një numër i përzgjedhur nga
secila ndarje)
Çdo numër i një ndarje të veçantë të klasës do të gjenerojë të njëjtin rezultat. Kjo është
arsyeja pse kjo teknikë quhet ndarja e klasës së ekuivalencës.

❑Vlerave kufitare (Boundary Values):
▪ Ndarja e Ekuivalencës e Klasave nuk garanton testimin e aplikacionit në vlerat kufitare. Ajo ju
jep të njëjtën peshë për të dy vlerat në ndarje ekujvalente dhe vlerave e kufirit
…, -3, -2, -1, 0 1, 2, 3……., 12 13, 14, 15…..
Ndarja invalide Ndarja valide Ndarja invalide
▪ Analiza e vlerave kufitare është një teknikë e rëndësishme pasi dihet gjerësisht se vlerat në
kufijtë shkaktojnë më shumë gabime në system.
▪ Prandaj një testues duhet gjithmonë të kontrollojë kufijtë sikur sistemi të dështojë, ka të ngjarë
të dështojë në këto kufij vendimesh.

❑Applying analizen e Vlerave kufitare (Boundary Values BVA):
▪ Consider the previous example where we partition the test data into three classes
▪ In boundary values analysis a tester must also check on boundary values in addition to other
test data.
▪ Lets apply BVA
…, -3, -2, -1, 0 1, 2, 3……., 12 13, 14, 15…..
Ndarja invalide 2 Ndarja valide Ndarja invalide 2
▪ To apply BVA, we will take the minimum and maximum (boundary) values from the valid
partition (1 and 12 in this case) together with first or last value respectively in each of the
invalid partitions adjacent to the valid partition (0 and 13 in this case)

❑Aplikimi ECP dhe BVA së bashku
…, -3, -2, -1, 0 1, 2, 3……., 12 13, 14, 15….. …, -3, -2, -1, 0 1, 2, 3……., 12 13, 14, 15…..
+
Ndarja invalide 2 Ndarja valide Ndarja invalide 2 Ndarja invalide 2 Ndarja valide Ndarja invalide 2
❑Sipas shembullit ne do të kemi tri teste për ndarjen e ekuivalencës (një nga secila prej tri
ndarjeve) dhe katër teste të vlerave kufitare
❑Për të kryer testet ECP dhe BVA, një testues mund të përdorë një nga kombinimet e
mëposhtme të të dhënave të testimit:
[-3, 6, 20] (for ECP tests) and [0,1,12,13] (BVA tests]

Testimi i gjendjës/kalimit të Tranzacionit (State Transition Testing ) ose
Tabelat e vendimeve (Decision tables)
❑Shembull :
▪ Konsideroni automati ATM dhe ju doni të tërhiqni para duke përdorur kartën e debitit /
kreditit.
▪ Nëse përdoruesi fut fjalëkalim të gabuar-Aplikacioni do të kërkojë të futni fjalëkalimin përsëri.
▪ Nëse përdoruesi fut fjalëkalimin e gabuar për herë të dytë, aplikacioni do të kërkojë nga
përdoruesi që të fut përsëri.
▪ Herën e tretë nëse përdoruesi fut fjalëkalimin e gabuar - Kartela do të bllokohet.
▪ Kështu që do të ketë 3 faza të ndryshme të aplikimit e cila nuk është gjë tjetër veçse
tranzicioni i gjendjës.
Kombinimi më efikas, duke testuar

potencialisht të gjitha opcionet për vlera
valide dhe invalide

Testimi sipas metodës së kutis së bardhë

❑Llojet e testimi sipas kutis së bardhë (white box testing method)
▪ Testimi White-box ka të bëjë me teknikat për dizajnimin e testeve; kjo nuk është një
nivel i testimit..!!!.
▪ Testimi bazuar në analizën e logjikës së brendshme (dizajn, kodi, etj). (Po ashtu,
rezultatet e pritshme ende vijnë nga kërkesat.), njohur edhe si testim strukturore.

❑Trajtimi/mbulim i deklaratës (të gjitha-nyjet)-Statement coverage (allnodes)
▪ Sigurohuni që çdo rresht i kodit të testohet.
❑Trajtimi/mbulim i degëve (të gjitha-skajet)-Branch coverage (alledges)
▪ Sigurohet që çdo degë (p.sh. e true ose false) është testuar.
❑Trajtimi/mbulim i rruëgve (të gjitha-rrugët)-Path coverage (allpaths)
▪ Sigurohuni që të gjitha shtigjet e mundshme të testohen.
“nodes”
input(Y)
if (Y<=0) then
Y := −Y
end_if
while (Y>0) do “edges”
input(X)
Y := Y-1
end_while

Statement (deklarata) Branch (dega) Path coverage (rruga)
? ? ?
1 2 4 Test raste(Test cases)

Kriteret e Përfundimit të Testit dhe Vlera e SC (1)
❑Trajtimi/mbulim i deklaratës (të gjitha-nyjet)-Statement coverage (allnodes)
❑përqindja e deklaratave të ekzekutueshme të ushtruara nga një rethin
testuese
𝑛𝑟 𝑖 𝑑𝑒𝑘𝑙𝑎𝑟𝑎𝑡𝑎𝑣𝑒 𝑡𝑒 𝑡𝑒𝑠𝑡𝑢𝑎𝑟
❑𝑡𝑟𝑎𝑗𝑡𝑖𝑚𝑖 𝑖 𝑑𝑒𝑘𝑙𝑎𝑟𝑎𝑡𝑒𝑠; 𝑠𝑐 =
𝑛𝑟 𝑡𝑜𝑡𝑎𝑙 𝑖 𝑑𝑒𝑘𝑙𝑎𝑟𝑎𝑡𝑎𝑣𝑒
?
❑shembull:
▪ Programi ka 100 deklarata
▪ testet ushtrojnë për 87 deklarata
▪ D.m.th mbulimi i deklaratave = 87%

Shembull i mbulimit të deklaratave
1 read(a)
Test Input Rezultati i pritur
2 IF a > 6 THEN rasti
3 b=a
4 ENDIF
1 7 7
5 print b
Pasi të gjitha 5 deklaratat janë 'mbuluar' nga

ky rast testimit, ne kemi arritur
Numri i deklaratave 100% mbulim e deklarimit

Kriteret e Përfundimit të Testit dhe Vlera e BC
❑Trajtimi/mbulim i degëve (të gjitha-skajet)-Branch coverage
(alledges)
❑Hulumtimet në industri kanë treguar se përmes testimit funksional arrin
vetëm 40% deri në 60% të mbulimit të vendimeve/degëve. False
❑Vendimi/mbulimi i Degës është më i fortë se mbulimi i deklaratave dhe
?
kërkon më shumë raste testimi për të arritur mbulimin e vendimit 100%. True
▪ Le të marrim një shembull për të shpjeguar mbulimin e vendimit:

Rast i Testimit (Test Cases)
•Mbulimi i deklaratës – ekzekutimi i një rasti të
testimit, të mbulimi ishte i mjaftueshëm sipas
drejtimit në degën
– Tc1: a, b, f, g, h, d, e
•Deget c, i, the k nuk janë ekzekutuar ose mbuluar

në rastin e testimit më lartë
•Test raste shtesë janë të nevojshëm:

– Tc2: a, b, c, d, e
– Tc3: a, b, f, g, i, g, h, d, e
– Tc4: a, k, e

Rast i Testimit (Test Cases)...
❑Mbulimi i rrugëve
❑Të gjitha rrugët e mundshme përmes testimit testohen

❑P.sh. Cikli pa përseritje:
▪ a, b, f, g, h, d, e
▪ Cikli(Loop) me kthim të vetëm (i) dhe një përsëritje të vetme :
▪ a, b, f, g, i, g, h, d, e
▪ Zakonisht një cikel (loop) përsëritet më shumë se një herë. Sekuenca
të mëtejshme të mundshme të degëve përmes grafikut të programit
janë
▪ a, b, f, g, i, g, i, g, h, d, e
▪ a, b, f, g, i, g, i, g, i, g, h, d, e
▪ a, b, f, g, i, g, i, g, i, g, i, g, h, d, etj.
▪ Kjo tregon se ekziston një numër i pacaktuar i rrugeve në grafikun e
rrjedhës së kontrollit

Shembull: Testimi sipas metodës së kutis së bardhë
❑Trajtimi/mbulimi i deklarates

Shembull: Testimi sipas metodës së kutis së bardhë
❑Rrjedhën e kontrollit të mbulimit:
❑Statement coverage (Mbulimi i deklaratës)
▪ Test Case01 për 1-3-5
o P.sh: a = 2, b = 0, x = 3.
❑Branch coverage (Mbulimi i degës)

▪ Test Case01 për: 1-2-5
o P.sh: a = 2, b = 2, x = -1
▪ Test Case02 për: 1-3-4
o P.sh: a = 3, b = 0, x = 1
❑Path coverage (Mbulimi i pathit /rrugë:)

▪ Paths:
o 1->2->4,
o 1->2->5,
o 1->3->4,
o 1->3->5.

Shembull: Testimit
ne modeline XP
THE VALUE OF TESTING

IN MOBILE GAME
DEVELOPMENT
PROCESS

Ushtrime

Shembull: Aplikimi për kredi
Emri i Klientit 2-64 chars.
Numri illogaris 6 digits, 1st

non-zero
Shuma e kredisë
Vitet e kthimit £500 to
£9000
Pagesa mujore
1 to 30 years
Term:
Repayment: Minimum £10
Interest rate:
Total paid back:

Emri i Klientit
Number of
characters:
1 2 64 65
invalid valid invalid
Valid characters: A-Z

-’ a-z Any
space other
70

Numri i llogaris
valid: non-zero
first character:
invalid: zero
number of digits: 5 6 7
invalid invalid
valid

Shuma e kredis
499 500 9000 9001
invalid valid invalid

Mostra e vendimeve

Dizajnimi i rasteve të testimit

Referenca

Referencat
Kapitulli 8: Software Engineering. 9th ed. By Ian Sommerville
Kapitulli 19: Software Engineering for Students. A Programming Approach.

Fourth Edition. by DOUGLAS BELL

Inxhinieria Softuerike Procesi Dhe Korniza Softuerike: Ramiz HOXHA 2021/2022

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inxhinieria Softuerike Procesi Dhe Korniza Softuerike: Ramiz HOXHA 2021/2022

Uploaded by

Copyright:

Available Formats

Inxhinieria Softuerike

Procesi dhe Korniza Softuerike

Ramiz HOXHA © 2021 UBT 1

Ramiz HOXHA © 2022 UBT 3

ref: Software Engineering. Ian Sommerville. Addison-Wesley, 10th edition

Ramiz HOXHA © 2022 UBT 4

▪ Modelet e procesit nuk janë të përsosura, por ofrojnë

▪ për shumë projekte softuerike, aktivitetet e kornizës

Ramiz HOXHA © 2022 UBT 5

Ramiz HOXHA © 2022 UBT 6

❑Si fillon gjithçka:

Ramiz HOXHA © 2022 UBT 7

Ramiz HOXHA © 2022 UBT 8

Ramiz HOXHA © 2022 UBT 10

Ramiz HOXHA © 2022 UBT 11

❑Skopi është puna që duhet bërë

❑Përcakton kufijtë e një projekti,

Ramiz HOXHA © 2022 UBT 12

Ramiz HOXHA © 2022 UBT 15

Ramiz HOXHA © 2022 UBT 16

Ramiz HOXHA © 2020 UBT 17

Ramiz HOXHA © 2021 UBT 1

❑Për të menaxhuar një projekt është e nevojshme të:

Ramiz HOXHA © 2021 UBT 2

Ramiz HOXHA © 2021 UBT 3

Ramiz HOXHA © 2021 UBT 4

Implemtimi Kodi Burimor

nga fillimi e deri në përfundim.

Ramiz HOXHA © 2021 UBT 6

Ramiz HOXHA © 2021 UBT 7

Ramiz HOXHA © 2021 UBT 8

▪ Modeli linear-sekuencial referohet gjithashtu si

▪ Në këtë model (modeli ujëvarës) secila fazë duhet të

Ramiz HOXHA © 2021 UBT 9

Ramiz HOXHA © 2021 UBT 10

Ramiz HOXHA © 2021 UBT 11

Ramiz HOXHA © 2021 UBT 12

Ramiz HOXHA © 2021 UBT 13

Ramiz HOXHA © 2021 UBT 14

Ramiz HOXHA © 2021 UBT 15

❑Mangësi: Një problem i madh nëse:

Ramiz HOXHA © 2021 UBT 16

Ramiz HOXHA © 2021 UBT 17

Ramiz HOXHA © 2021 UBT 18

Ramiz HOXHA © 2021 UBT 19

Ramiz HOXHA © 2021 UBT 20

Ramiz HOXHA © 2021 UBT 21

Ramiz HOXHA © 2021 UBT 22

Ramiz HOXHA © 2021 UBT 23

Ramiz HOXHA © 2021 UBT 24

Ramiz HOXHA © 2021 UBT 25

Ramiz HOXHA © 2021 UBT 26

Ramiz HOXHA © 2021 UBT 27

Ramiz HOXHA © 2021 UBT 29

Ramiz HOXHA © 2021 UBT 30

Ramiz HOXHA © 2021 UBT 31

❑ DevOps është një metodë e zhvillimit të softuerit

Ramiz HOXHA © 2021 UBT 32

Ramiz HOXHA © 2021 UBT 33

Ramiz HOXHA © 2022 UBT 35

Ramiz HOXHA © 2022 UBT 36

Ramiz HOXHA © 2022 UBT 37

Ramiz HOXHA © 2021 UBT 1