You are on page 1of 15

Inxhinierimi i software

Leksion II

Procesi. Modelet e proceseve te zhvillimit te software


Inxhinieria e software nj teknologji me shtresa
Me shum sesa nj disipline apo nj bashkesi me njohuri, inxhinierimi sht nj fjale q tregon
veprim(folje), nj mnyr pr t arritur zgjidhjen e problemit. Scott Whitmire
Perkufizimi klasik pr SE: SE sht vendosja dhe perdorimi i principeve inxhinierike q t
realizoje n mnyr ekonomike software q sht i besueshm dhe q funksionon n mnyr
efikase n makina reale.
Ky prcaktim pr SE l hapesira pr diskutime dhe modifikime sepse ai:
- nuk jep informacion pr aspektet teknike t cilsis s software
- nuk adreson n mnyr direkte nevojen pr plotesimin e kerkesave t klientit dhe
leshimin n kohe t produktit
- nuk permend rendesine e matjeve dhe metrikave
- nuk permend nevojen e nj procesi t konsoliduar.
Megjithate percaktimi jep nj baze t ciles mund ti referohemi. Cilat jane principet inxhinierike
q mund t zbatohen pr zhvillimin e softwareve t kompjuterave? Si mund t ndertojme n
mnyr ekonomike software t besueshem? Cilat jane kushtet paraprake pr t ndertuar
programe q punojne n mnyr eficente n shum makina reale t ndryshme? Keto jane
pyetjet q vazhdojne t sfidojne inxhinieret e software.
Procesi, metodat dhe mjetet
Inxhinierimi i software sht i shtreszuar. Cdo zgjidhje inxhinierike duhet t kt n thelb t saj
arritjen e cilesise.
Themeli i SE sht shtresa e
proesit. Proesi sht ai q
mban bashk shtresat e
teknologjise dhe q
mundeson zhvillim n
perputhje me afatet kohore
t softwarit. Proesi formon
bazat pr kontrollin e
menaxhimit t projekteve t
softwareve,

mjete
metoda
proesi
fokus mbi cilesine

percakton kontekstin n t cilin do t zbatohen metodat teknike, do t prodhohen produktet e


punes(modele, dokumenta, t dhena, raporte, etj), do t vendosen objektivat q do t arrihen(
milestones), do t arrihet cilesia dhe do t menaxhohet ashtu si duhet ndryshimi.
Metodat e SE ofrojne zgjidhjet teknike pr pyetjet Si?(How to) pr zhvillimin e software. Ato
perfshijne nj game t gjer aktivitetesh si: analiza e kerkesave, modelimi, ndertimi i programit,
testimi dhe suporti. Metodat e SE bazohen mbi nj bashkesi principesh q udheheqin cdo fushe
t teknologjise dhe q perfshijne veprimtarite e modelimit dhe teknika t tjera pershkruese.

-1-

Inxhinierimi i software

Leksion II

Mjetet e SE(tools) ofrojne suport t automatizuar ose gjysem t automatizuar pr procesin dhe
pr metodat. Kur mjetet integrohen n mnyr q informacioni i krijuar nga njeri mjet t
perdoret nga nj tjeter, krijohet nj sistem q mbeshtet zhvillimin e software. Ky sistem njihet si
CASE (Computer Aided Software Engineering).
Pamje e prgjithshme e inxhinieris s software
Inxhinierimi sht analiza, modelimi, ndertimi verifikimi dhe menaxhimi i njesive teknike.
Pavaresisht se cila sht njesia n fjale, duhet t behen dhe t marrin pergjigje keto pyejte:
- cili sht problemi q duhet t zgjidhet?
- cilat jane karakteristikat e njesise q do t perdoret pr t zgjidhur problemin?
- si do t realizohen njesia (dhe zgjidhja)?
- si do t ndertohet njesia?
- cfare mnyr do t perdoret pr t zbuluar gabimet q jane br gjate modelimit dhe
ndertimit t njesise?
- si do t veprohet n periudha t gjata kohe kur do t kerkohen rregullime, pershtatje
dhe zgjerime nga prdoruesit e njesis?
Inxhinieria e software eshte nje aktivitet modelimi. Kompleksiteti i software menaxhohet
nepermjet modelimit, duke u fokusuar ne nje moment te caktuar vetem ne detajet e duhura
dhe duke lene menjane cdo gje tjeter qe lidhet me problemin.
Inxhinieria e software eshte nje aktivitet qe realizon zgjidhje problemesh. Modelet perdoren
per te kerkuar per nje zgjidhje te pranueshme. Deri sa te arrihet ne modelin qe jep zgjidhjen me
te mire, kryen eksperimente. Inxhinieret e software nuk kane burime te pafundme dhe kane
kufizime ne afate kohore apo buxhete. Shpesh ata duhet ti besojne metodave empirike per te
vleresuar perfitimet e alternativave te ndryshme.
Inxhinieria e software eshte nje aktivitet gjate te cilit mblidhen njohuri. Gjate modelimit te
hapesires se problemit apo zgjidhjes, inxhinieret e software mbledhin te dhena, organizojne te
dhenat ne informacion dhe e formalizojne ate ne njohuri.
Inxhinieria e software eshte nje aktivitet qe udhehiqet nga arsyetimi. Kur mbledhin
informacion dhe kur marrin vendime ne lidhlje me hapesiren e sistemit (fushen ku do te operoje
sistemi, specifikat e te dhenave qe do te trajtohen), inxhinieret e software duhet te vleresojne
dhe kontekstin ne te cilin merren vendimet dhe arsyet per keto vendime. Nqs duhet qe
inxhinieret ti rikthehen nje vendimi, eshte mire qe ata te mund te njihen / rifreskohen me
arsyet e tij, ne kete menyre dhe ndryshimet do te jene me te sigurta dhe me te lehta.
Pr t inxhinieruar sakte nj software duhet t percaktohet nje proes.
Puna q behet pr ndertimin e nj software kategorizohet n tre faza t pergjithshme,
pavaresisht nga fusha a aplikimit, nga madhesia dhe kompleksiteti i projektit. Secila faze adreson
nj ose me shum nga pyetjet e mesiperme.
Faza e prcaktimit (definition phase) fokusohet tek cfar. Gjate percaktimit, inxhinieret e
software duhet t identifikojne:
- cfare informacioni do t procesohet
- cfare funksionesh dhe performance deshirohet t arrihet
- cfare sjellje pritet nga sistemi
- cfare nderfaqesh do t nevojiten
- cfare kufizmesh ekzistojne n modelim
- cfare kriteresh duhen pr validim pr tu siguruar nj sistem i suksesshem.

-2-

Inxhinierimi i software

Leksion II

Identifikohen kerkesat kryesore t sistemit dhe software. Megjithese metodat q mund t


ndiqen gjate fazes se percaktimit mund t ndryshojne n varesi t paradigmit t inxhinierimit t
perdorur, n nj fare mnyr do t realizohen tre veprime kryesore: inxhinierimi i sistemit ose i
informacionit, planifikimi i projektit t zhvillimit t software dhe analiza e kerkesave.
Faza e zhvillimit(development phase) fokusohet tek si. Kjo do t thote q gjate zhvillimit, nj
inxhinier duhet t perpiqet t percaktoje se si do t strukturohen t dhenat, si do t
implementohet funksioni, si do t implementohen detaje proceduriale, si do t jen nderfaqet,
si do t perkthehet modeli n nj gjuhe programimi, si do t behet testimi. Metodat q mund t
zbatohen gjate zhvillimit mund t jen t ndryshme, por gjithmone do t kryen tre aktivitete
teknike: modelimi i software, gjenerimi i kodit, testimi i software.
Faza e suportit (mirembajtja) fokusohet tek ndryshimi qe lidhet me rregullimin e gabimeve,
pershtatjet e ndryshme q mund t kerkohen si pasoje e evolimit t mjedisit n t cilin perdoret
software dhe, ndryshime q vin nga ndryshimet e kerkesave t perdoruesve. Gjate kesaj faze
mund t hasen kater lloj ndryshimesh:
Rregullimi. Edhe pse mund t jen perdorur metodat me t mira pr t siguruar cilesi,
ka shum mundesi q prdoruesit t zbulojne gabime t software, gjate perdorimit t
tij.
Pershtatja(adaptation). Me kalimin e kohes, ka shume mundesi q mjedisi pr t cilin
ishte zhvilluar software t ndryshoj (psh CPU, sistemi i shfrytesimit, rregullat e biznesit,
karakteristika t jashtme t produktit). Mirembajtja pershtatese rezulton n modifikimin
e softit n mnyr q ai t jet n harmoni me mjedisin e jashtem.
Zgjerimi(enhancement). Gjate perdorimit t software, prdoruesit do arrijne t
kuptojne q ekzistojne edhe funksione t tjera q mund t lehtesojne punen e tyre.
Mirembajtja permiresuese zgjeron software pertej kerkesave fillestare funksionale.
Parandalimi(prevention). Ndryshimet e perkeqesojne nj software, dhe pr kt shkak,
n mnyr q software t vazhdoje ti sherbeje nevojave t perdoruesve, duhet t
zbatohet mirembajtja parandaluese q shpesh njihet dhe si riinxhinierim i software. Ne
thelb, mirembajtja parandaluese i ndryshon programet e kompjuterave n mnyr q
ata t mund t rregullohen, pershtaten dhe zgjerohen me lehte.
Pervec aktiviteteve t mesiperme, si pjese e fazes se suportit implementohen/pergatiten shpesh
edhe asistente teknik, asistente nepermjete telefonave (telephone help-desks), faqet e
internetit specifike pr aplikimet.
Fazat dhe dhe hapat q lidhen me to, t pershkruara me lart si pjese e nj pamje t
pergjithshme pr SE, plotsohen dhe me nj numer tjeter veprimesh t quajtura veprimet
adr. Aktivitete tipike t kesaj kategorie jane:
- gjurmimi dhe kontrolli i projektit t zhvillimit t software.
- rishikimet teknike
- sigurimi i cilesise se software (sw quality assurance)
- menaxhimi i konfigurimit t software
- pergatitja dhe prodhimi i dokumentimit
- menaxhimi i riperdorshmeris
- matjet
- menaxhimi i rrezikut (risk management).
Keto aktivitete realizohen pergjate proesit t software.

-3-

Inxhinierimi i software

Leksion II

Proesi i software
Nj projekt software (software project) sht nj ndermarrje konkrete, e planifikuar, qellimi i s
cils sht ndertimi i nj ose disa sisteme q kane permbajtje software. Aktivitetet e projektit
ndahen n dy grupe kryesore q sherbejne dhe si dimensione t tij: inxhinierimi dhe menaxhimi.
Inxhinierimi merret me ndertimin e sistemit dhe fokusohet n eshtje si modelimi, kodimi,
testimi, etj. Planifikimi merret me planifikimin dhe kontrollin e nevojshem t aktiviteteve
inxhinieruese me qellim q t arrihen qellimet e projektit n lidhje me koston, afatet dhe
cilesin e projektit.
Nqs projekti sht i vogel, pra nj ose dy persona punojne pr disa dite ose jave, ai mund t
realizohet n mnyr jo formale. Plani i projektit mund t jet nj e-mail q specifikon diten e
mbarimit dhe ndoshta disa objektiva t menjehershem. Kerkesat mund t komunikohen
nepermjet nj shenimi ose ndoshta dhe gojarisht, dhe produktet e menjehershme t punes si
dokumenti i modelimit, mund t jen disa dokumenta t thjeshte me pershkrime.
Keto teknika jo formale nuk mund t zbatohen pr projekte t medha, me shum njerez q
punojne pr shum muaj- situata me e zakonshme pr projektet komercial. N projekte t till,
do detyre apo veprimtari inxhinieruese duhet t behet me kujdes, duke perdorur metodologji
q jane t testuara mir dhe, produktet e punes duhet t dokumentohen mir, n mnyr q
ato t mund ti shohin dhe perdorin dhe t tjeret. Detyrat e percaktuara pr t realizuar
projektin, duhet t planifikohen mir, t jen t ndara ndermjet njerezve q jane pjese e
projektit dhe me pas t jen nen gjurmim/kontroll t vazhdueshem gjate periudhes q
zhvillohet projekti. Pra, q projekti t rezultoje i suksesshem, duhet q gjate inxhinierimit dhe
planifikimit t rritet formaliteti dhe rigoroziteti. Formaliteti kerkon q gjate realizimit t
detyrave apo veprimeve t ndryshme t ndiqet nj proes i percaktuar mir. N kt mnyr,
rezultati sht i varur nga cilsia e proesit.
Cfare sht nj proes? Teknikisht, pr nj pun t caktuar, proesi sht nj rradhe/sekuenc
hapash q duhen ndjekur pr t realizuar kt pun. Megjithate, pr nj organizate, proeset q
ajo u rekomandon inxhinierve dhe menaxherve t projekteve, jane me shum sesa nj rradhe
e thjeshte veprimesh, ato prmbledhin at q inxhiniert dhe menaxhert e projekteve kan
msuar nga projektet e suksesshme.
Gjate inxhinierimit:
Proesi sht nj bashkesi e strukturuar e hapave/veprimeve t krkuara pr t zhvilluar nj
software. Keto veprime perfshijne specifikimin (njohja me problemin, analiza),
modelimin(design), validimin( e modelit) dhe evolimin(zhvillim, implementim,testim, instalim,
mirembajtje).
Cdo faze e proesit duhet t dokumentohet mir perpara se t filloje faza tjeter. Esht e
rendesishme q dokumentimi t bhet n koh sepse:
- dokumentimi i shtyr mund t mos plotsohet kurr.
- personi prgjegjs pr t mund t largohet
- produkti ndryshon vazhdimisht, dhe pr t realizuar kto ndryshime na duhet
dokumentimi. Psh gjat zhvillimit mund t kerkohen ndryshime q do t ishte shum e
leht t realizoheshin n rast se ekziston nj dokument q prshkruan modelin
(modeluesit mund t mos jen aty pr tu pyetur).
Figura paraqet nj karakterizim t proesit t software. Fillimisht percaktohet nj kornize
(framework) e procesit duke percaktuar nj numer veprimesh q jane t aplikueshme pr cdo
proces, pavaresisht nga permasat apo kompleksiteti. Me pas percaktohet nj bashkesi

-4-

Inxhinierimi i software

Leksion II

veprimesh- secila nj bashkesi detyrash inxhinierike, objektiva t projektit (milestones),


produkte t punes, pika t sigurimit t cilesise- q lejojne pershtatjen e aktiviteteve te kornizes
sipas karakteristikave t projektit t
software dhe kerkesave t ekipit t
projektit. N fund, proesi mbulohet
nga aktivitete ader si sigurimi i
cilsis, menaxhimi i konfigurimit t
software, matjet, etj. Aktivitetet cader
jane t pavarura nga aktivitetet e
kornizes dhe zhvillohen pergjate
proesit.

Korniza e proesit
Aktivitete t kornizes
- Detyra/Veprime
- Objektiva, produkte
- Sigurimi cilesise

Aktivitete t adres
Proesi sht i rndsishm pr nj sr arsyesh:
1. Lejon ndarje te punes.
2. Promovon pune/komunikim ekipi/individuale. Nepermjet procesit(veprimeve dhe
produkteve t tij, njerezit kuptojne se me cfare merren t tjeret).
3. Lehteson menaxhimin e projektit (supervisoret/manaxheret mund te kuptojne cfare po
ndodh).
4. Lejon riperdorim t njohurive fituar nga pervojat. Perfitimet nga pervoja e projekteve t
suksesshme ndahen me t gjithe, dhe me t sapo ardhurit n grupet e punes.
5. Inxhiniert dhe menaxhert imitojn sukseset e mparshme dhe arrijn t shmangin
situatat q ojn n dshtim.
Pasi pranohet dhe bindemi q ndjekja e nj proesi sht rruga drejt suksesit t projektit, pyetja
q lind sht cfare karakteristikash duhet t kt proesi q do t ndiqet?
Instituti i Inxhinierimise t Software (Software Engineering Institute SEI) ka zhvilluar nj skelet
duke vezhguar zhvillimin e software n shum organizata. Ky standart njihet si CMM (Capability
Maturity Model). Ai permbledh pervojat dhe ato q presin shum kompani. CMM specifikon
karakteristikat e proceseve pa pershkruar nj proces konkret. N kt mnyr, kerkesat e CMM
mund ti permbushin procese t ndryshme. Ai mund t perdoret pr t vleresuar procesin e
zgjedhur nga organizata dhe pr t vn n pah mungesat apo t metat e tij.
Nj nga objektivat e CMM sht t dalloj proeset e konsoliduara (matured) nga ato t
pakonsoliduara, q jan prshtatur pr rastin konkret (ad-hoc, immature). Duke ndjekur nj
proes t pakonsoliduar, projekti zhvillohet jo sipas nj bashkesie rregullash, pothuajse n
mnyr kaotike dhe prfundimi i projektit varet kryesisht nga aftesia e ekipit dhe e udhheqsit
t projektit. N anen tjetr, duke ndjekur nj proes t konsoliduar, projekti do t ec npr
hapa q jan t prcaktuara dhe testuara me pare dhe, rezultati i projektit sht me pak i varur
nga njerezit e perfshir n projekt. Pra sa m i konsoliduar proesi, aq m t parashikueshme
jan rezultatet dhe aq m t kontrollueshme jan projektet.
Hapsira e rezultateve q mund t priten n nj projekt kur ai zhvillohet duke ndjekur nj proes
prbn aftsit/kapacitetin e proesit. Rezultati aktual q u arrit n projekt duke perdorur
proesin prbn performancen e proesit. Duket q performance e proesit varet nga aftesia e
proesit. Pr t rritut n mnyr konsistente performancen e procesit (pra pr t marr
rezultate t larta n fund t projektit), duhet rritur kapaciteti i proesit; proesi duhet t
konsolidohet.

-5-

Inxhinierimi i software

Leksion II

Rruga pr t arritur n shkall t lart konsolidimi, kalon npr disa nivele konsolidimi t
percaktuara qart.Cdo nivel specifikon karakteristika t caktuara t procesit dhe, nivelet me t
larta kane vecori m t avancuara dhe aplikohen n procese m t konsoliduara. Standarti CMM
prshkruan elementt kryesor pr cdo nivel konsolidimi. Rrjedhimisht, prshkruan dhe rrugn
q mund t ndiqet pr t kaluar nga procese jo t konsoliduara n ato t konsoliduara mir.
Jan prcaktuar pes nivele:
1. Niveli 1- niveli fillestar (Initial). Proesi karakterizohet si i pershtatur pr situaten
konkrete (ad-hoc) dhe ndonjehere dhe kaotik. Ka pak procese t percaktuar q
klasifikohen n kt nivel dhe rezultati final varet shum nga aftesite e njerezve t
perfshire n projekt.
2. Niveli 2 procesi i perseritshem (repeatable). Vendosen procese baze t menaxhimit t
projektit pr t gjurmuar koston, afatet, funksionalitet. Edhe pse mund t mos
ekzistojne procese specifike t organizates, sht e mundur t perseritet suksesi i
projekteve t meparshme pr aplikime t ngjashme.
3. Niveli 3 procesi i percaktuar (defined). Procesi i software pr inxhinierimin dhe
menaxhimin sht i dokumentuar, i standartizuar, dhe i integurar n aktivitetin e
organizates. T gjith projektet perdorin nj version t dokumentuar dhe aprovuar t
procesit t zhvillimit dhe suportit t softwarit. Ky nivel perfshin t tera karakteristikat e
percaktuara n nivelin e dyte.
4. Niveli 4 procesi i menaxhuar (managed). N kt nivel jan mbledhur matje t cilesis
s procesit dhe produktit. T dy (procesi dhe produkti) jane kuptuar nga pikepamja
cilsore dhe kontrollohen duke prdorur matje t detajuara. Niveli perfshin t tra
karakteristikat e nivelit t tret.
5. Niveli 5 procesi i optimizuar (optimized). Procesi permiresohet n mnyr t
vazhdueshme duke prdorur feedback n lidhje me cilesine nga procesi dhe duke
testuar idete inovative dhe teknologjit. Ky nivel pershin t gjitha karakteristikat e
nivelit t katrt.
Cdo nivel duke filluar nga i treti, permban nivelin e meparshem, psh nj zhvillues software n
nivelin e trete, duhet t kt arritur statusin e nivelit t dyte n mnyr q t arrije
karakteristikat e nivelit t trete.
Cdo nivel karakterizohet nga disa hapesira kyce t procesit (key process areas KPAs) t cilat
specifikojne fushat n t cilat duhet t fokusohet organizata pr ta ngritur procesin e saj n
nivelin e deshiruar t konsolidimit. Q nj organizate t arrij nj nivel t caktuar konsolidimi,
ajo duhet t permbushe t tra KPAs t atij niveli si dhe t niveleve me poshte.
Nga vleresimet e bera, gjate viteve 1996- 2000 vetem 5% e organizateve kishin arritur nivelin e
peste, 5% nivelin e katert, 18% nivelin e dyte dhe 38% n nivelin e trete.
Kategorizimi i aktiviteteve te procesit
Proceset (sekuence veprimtarish qe kryen per nje qellim te caktuar) mund te grupohen
ne grupe procesesh. Standarti i IEEE liston 17 procese, te grupura si me poshte:
Grupi i proceseve
Modelimi i ciklit jetesor

Proceset
Zgjedhja e modelit te ciklit jetesor

Menaxhimi i projektit

Inicimi i projektit
Monitorimi i projektit dhe kontrolle
Menaxhimi i cilesise se software

-6-

Inxhinierimi i software

Leksion II

Para zhvillimi

Eksplorimi i konceptit
Alokimi i sistemit

Zhvillimi

Kerkesat
Modelimi
Implementimi

Pas zhvillimi

Instalimi
Operimi dhe suporti
Mirembajtja
Terheqja e software

Integrale

Verifikim dhe Validim


Menaxhimi i konfigurimit te software
Dokumentimi i zhvillimit
Trajnime

Vete proceset perbehen nga aktivitete. Nje aktivitet eshte nje detyre ose nje grup nen
aktivitetesh te cilat i caktohen nje ekipi ose nje pjesemarresi te projektit, per te arritur nje qellim
specifik. Psh. ne rastin e procesit Kerkesa, aktivitetet do te ishin:
o percaktimi dhe zhvillimi i kerkesave te software , aktivitet gjate te cilit percaktohen
saktesisht funksionalitet e sistemit
o percaktimi i kerkesave per nderfaqe, aktivitet gjate te cilit percaktohen qarte
nderveprimet ndermjet sistemit dhe perdoruesit
o caktimi i prioriteteve dhe integremi i kerkesave te software, aktivitet gjate te cilit te
gjitha kerkesat integrohen, duke ruajtur konsistence dhe rradhiten sipas preferences se
klientit.
Aktivitetet e percaktuara nga standartet e IEEE nuk eshte e thene te ndiqen ne te njejten
menyre ne te gjithe projektet. Ato pershtaten sipas natyres se projektit gjate menaxhimit te
projektit nga menaxheri. Psh. sistemet qe nuk kane nevoje te ruajne sasi te medha te dhenash,
nuk kane nevoje per fazen e modelimit te bazes se te dhenave.
Menaxhimi i projektit
Menaxheri fillon, monitoron dhe kontrollon projektin nepermjet ciklit jetesor. Menaxhimi i
projektit perbehet nga tre procese kryesore:
Procesi i inicimit te projektit gjate te cilit krijohet infrastruktura per projektin. Gjate ketij
procesi percaktohen plani i puneve, orari, buxheti, organizimi dhe mjedisi i projektit (standarte
te projektit, infrastrukture komunikimi, procedurat e takimeve dhe raportimit, metodologjia e
zhvillimit, mjetet qe do te perdoren per zhvillim). Aktivitete te hasura shpesh gjate ketij procesi
jane: vendosja e nje korrespondence mes aktiviteteve qe duhen perfunduar dhe modelit te ciklit
jetesor te software, shperndarja e burimeve te projektit, percaktimi i mjedisit te projektit,
manaxhimi i planit te projektit.
Procesi i monitorimit dhe kontrollimi siguron qe projekti te vazhdoje sipas planit te
puneve dhe buxhetit. Nqs menaxheri i projektit veren devijime nga planifikimi dhe oraret
atehere ai/ajo duhet te ndermarre plane korrektuese si riplanifikimi dhe rishperndarja e

-7-

Inxhinierimi i software

Leksion II

burimeve, ndryshimi i procedurave, riplanifikimi i orareve. Aktivitet e hasura gjate ketij procesi
jane analiza e rreziqeve, menaxhimi i projektit, ruajtja e historise se ecurise se projektit,
implementimi i modelit te raportimit te problemeve.
Procesi i menaxhimit te sigurise se software siguron qe sistemi te ndertohet sipas
standarteve te cilese (te paracaktuara). Ky proces ndermerret nga nje ekipi vecante i sigurimit te
cilesise, i cili eshte jashte ekipit menaxhues (ne menyre qe te shmangen konfliktet e interesit).
Qellimi i zhvilluesve eshte qe te perfundohet projekti ne kohe, ndersa i ekipit te sigurimit te
cilesise eshte te mos e quaje projektin te perfunduar derisa produkti te jete sipas standarteve te
kerkuara te cilesise. Aktivitet e ketij procesi jane planifikimi i menaxhimit te cilesise se software,
percaktimi i metrikave, menaxhimi i cilesise se software, identifikimi i nevojave per permiresim
cilesie.
Para zhvillimi
Gjate ketij procesi, menaxhimi (ose marketingu) dhe nje klient indentifikojne nje ide ose nje
nevoje. Kjo mund te realizohet nepermjet nje sistemi ekzistues ose nepermjet zevendesimit te
software apo proces biznesi, ose nepermjet ndryshimit te komunikimit (nderfaqes) se sistemeve
ekzistues. Gjate eksplorimit te konceptit identifikohen idete apo nevojat, formulohen menyrat e
mundshme te zgjidhjeve, realizohen studime te aftesive praktike per te konkretizuar zgjidhjet,
planfikohet tranzicioni i sistemit (ne rast se ka vend per dicka te tille), perpunon dhe finalizon
idete ose nevojat. Gjate alokimit te sistemit analizohen funksionet, zhvillohet arkitektura e
sistemit dhe dekompozohen kerkesat e sistemit.
Zhvillimi
Zhvillimi ka te beje me proceset qe cojne drejt ndertimit konkret te sistemit. Procesi qe merret
me kerkesat percakton dhe zhvillon kerkesat e software, percakton kerkesat e nderfaqeve,
percakton prioritetet dhe integron kerkesat. Gjate modelimit percaktohet modelimi arktikturor,
modelohet baza e te dhenave (nese sistemi do te kete nje baze te dhenash), zgjidhen dhe
zhvillohen algoritme, realizohet modelim i detajuar. Procesi i modelimit merr si input
arkitekturen e krijuar gajte Alokimit te Sistemit dhe specifikimet e procesit te Kerkesave dhe
prodhon nje paraqitje koherente dhe te organizuar mire te sistemit. Implementimi merr si input
modelin dhe prodhon nje paraqitje te ekzekutueshme te sistemit. Implementimi perfshin shume
planifikim integrimi dhe integrim. Aktivitete te tjera te ketij procesi jane krijimi i te dhenave test,
krijimi i kodit burim, gjenerimi i objekteve ne kod, krijimi i dokumentimit.
Pas zhvillimi
Procesi i pas zhvillimit perbehet nga instalimet, mirembajtja, mbeshtetja operacionale, terheqja
e software. Gjate instalimit software instalohet tek klientet. Klienti duhet te beje testimin e
pranimit sipas kritereve te percaktuara ne kontraten e projektit. Pra, instalimi ka si aktivitete
planifikimin e instalimit, shperndarjen e software, instalimin e software, pranimin e software ne
mjedis operacional. Mbeshtetja operacionale lidhet me trajnimin e perdoruesve dhe operimin e
sistemit. Aktivitete qe perfshihen ne kete procces jane venia ne pune e sistemit, ofrimi i ndihmes
teknike dhe i keshillimeve dhe krijimi i logeve me kerkesat per suport.
Procese integrale (te pranishme vazhdimisht)
Verifikimi dhe validimi jane procese qe kane aktivitete qe fokusohen verifikimin qe modeli i
sistemit perputhet me kerkesat e specifikuara. Keto verifkime behen nepermjet rishikimeve,
inspektimeve, kontrolleve. Punet e validimit sigurojne qe sistemi adreson nevoja e klientit dhe

-8-

Inxhinierimi i software

Leksion II

perfshin testim. Verifikimi dhe validimi zhvillohen gjate gjithe ciklit jetesor te sistemit me qellim
qe te gjenden mangesira apo probleme sa me heret qe te jete e mundur.
Menaxhimi i konfigurimit perqendrohet ne gjurmimin dhe kontrollin e ndryshime te
produkteve te ndryshem te punes. Subjekte te ketij procesi jane kodi i sistmit, modelet e
zhvillimit, plani i menaxhimit te software, dokumentat, etj.
Procesi i dokumentimit merret me produketet e ndryshme, dokumentimi i te gjitha
rezultateve te te gjitha proceseve

Modelet e proeseve t software


Cikli jetesor i software perfaqeson te gjitha veprimtarite dhe produktet e nevojshme per
te zhvilluar nje software. Procesi i ndertimit te nje software eshte mjaft kompleks, prandaj
duhen gjetur menyra per ta ulur kete kompleksitet. Duke injoruar detaje te panevojshme dhe
duke u fokusuar vetem ne ate qe eshte e rendesishme per nje ceshtje te caktuar, zhvilluesit e
nje software mund te zgjidhin problemet ne menyre me eficente dhe tu pergjigjen pyetjeve te
caktuara ne momente te caktuara te ciklit jetesor. Cikli jetesor i software mund te shikohet si nje
sistem kompleks me inpute, outpute, burime dhe aktivitete. I pare keshtu, konceptet e
modelimit te nje software mund te zbatohen dhe tek procesi i zhvillimit te tij, pra cikli jetesor i
software mund te modelohet. Modelimi i ciklit jetesor lejon qe menaxheret apo zhvilluesit te
perballen me kompleksitetin e procesit te zhvillimit te software ne te njejten menyre si ata
perballen me kompleksitetin e vete software gjate modelimit te ketij te fundit. Ekzistojne shume
modele te ciklit jetesor dhe qellimi i tyre i perbashket eshte te ofrojne nje kuptueshmeri me te
mire te procesit, te masin dhe kontrollojne procesin e zhvillimit. Nepermjet modeleve te ciklit
jetesor, aktivitetet e zhvillimit te software dhe varesite ndermjet tyre behen me te
kontrollueshme dhe te menaxhueshme.
Modeli i procesit t software sht nj prezantim abstrakt i proesit. Ai jep nj pershkrim t
procesit duke e par nga disa perspektiva t vecanta.
Modeli i referohet strategjise s zgjedhur pr t realizuar zhvillimin e software duke perdorur
shtresat e procesit, metodave dhe mjeteve teknike si dhe fazave t permendura. Modeli i nj
procesi zgjidhet duke u bazuar n natyren e projektit dhe t aplikimit, metodave dhe mjeteve q
do t perdoren, kontrollin q kerkohet dhe produktet q t do leshohen (deliverables).
Zhvillimi i nje software mund t karakterizohet si nj cikel i zgjidhjes se problemit n t cilin
dallohen kater faza.
Status quo- gjendja aktuale e biznesist
Percaktimi i problemit- identifikohet
problemi specifik q do t zgjidhet
Zhvillimi teknik- zgjidhet problemi
duke aplikuar teknologji
Integrimi i zgjidhjes- shperndarja e
rezultatit (dokumenta, programe, t
dhena, etj) tek ata q e kerkuan.

-9-

Inxhinierimi i software

Leksion II

Realisht, sht e veshtire q veprimtaria t jet e ndare n faza kaq t qarta dhe t ndara nga
njera tjetra, sepse ndermjet tyre ka nderthurrje.
Aktivitetet baze do t zbatohen n cdo projekt, por punet pr cdo aktivitet do t variojne bazuar
n tipin e projektit, karakteristikat e projektit, konkurrenca n ekipin e projektit.
Modeli linear
Ky model njihet shpesh dhe si cikli klasik jetsor (classic life cycle). Ky model sugjeron nj
mnyr sistematike, sekuenciale pr zhvillimin e software qe kalon nepermjet fazave t analizes,
modelimit, kodimit, testimit dhe suportit.

Fazat neper t cilat kalon ky model:


Inxhinierimi dhe modelimi i sistemit/informacionit: mqs software sht gjithmone pjese e nj
sistemi me t madh (ose biznesi), puna fillon me percaktimin e kerkesave pr t gjithe
elementet e sistemit dhe me pas caktimi i disa prej ketyre kerkesave tek software. Krijimi i
pamjes pr sistemin sht i rendesishem kur software do t kt nderfaqe me elemente t tjere
si psh hardware, njerezit dhe bazat e t dhenave. Inxhinierimi i sistemit dhe analiza perfshin
mbledhjen e kerkesave n nivel sistemi. Inxhinierimi i informacionit perfshin mbledhjen e
kerkesave n nivel strategjik biznesi.
Analiza e kerkesave t software. Mbledhja e kerkesave sht nj process q fokusohet kryesisht
tek software. Pr t kutpuar natyren e programeve q do t ndertohen, inxhinieri i software
(analisti) duhet t kuptoje hapesiren e informacionit t software, funksionin e kerkuar, sjelljen,
performancen dhe nderfaqet.
Modelimi (design). Modelimi i sistemit sht nj process me shum hapa, q fokusohet n kater
atribute t dalluara t software: strukturat e t dhenave, arkitektura e software, nderfaqet,
detajet proceduriale (algoritmike). Procesi i modelimin, perkthen kerkesat n paraqitje t
softwarit q mund t vleresohet pr cilesi perpara se t filloje kodimi.
Gjenerimi i kodit. Modeli duhet t perkthehet n nj forme t lexueshme nga makina dhe kjo
behet duke gjeneruar kod. Nqs modeli sht ndertuar n mnyr t detajuar, kodi mund t
gjenerohet automatikisht.
Testimi. Pasi sht gjeneruar kodi, fillon testimi i programit. Procesi i testimit fokusohet n
logjiken e brendshme t software, ne sigurimin q jane testuar t gjitha instruksionet, q
funksionet japin rezultatet e pritshme. Kjo do t thote q t behen teste pr t zbuluar gabime
dhe q sigurojne q t dhena t caktuara do t prodhojne rezultatet ashtu sic sht percaktuar
me pare.

- 10 -

Inxhinierimi i software

Leksion II

Suporti. Software do ti nenshtrohet ndryshimeve pasi ai i jepet klienteve pr prdorim


(perjashtim mund t bejne sistemet e nderfutura). Ndryshimet mund t vijn ngaq hasen
gabime, ndryshon mjedisi i jashtm, ose klientt krkojn zgjerime funksionale apo
performace..Suporti dhe mirmbajtja aplikojn t gjitha fazat e siprprmendura n nj
program ekzistues (jo n nj t ri).
Fazat e siprprmendura jan dhe fazat kryesore t proesit n prgjithsi. N kt model, ato
kryen n mnyr sekuenciale, ndrkoh q n modele t tjera mund t ken nj rradh tjetr.
Modeli linear sht modeli m i vjetr dhe m i prdorshmi n inxhinierimin e software. Ai
njihet edhe si modeli klasik. Megjithat, kritikat q ka pasur ky model kan shkaktuar dyshime
pr prdorimin e tij dhe tek mbshtetsit e tij. Disa nga problemet q hasen gjat prdorimit t
tij jan (q ojn dhe n dshtim t tij):
1. projektet reale rradh ndjekin rrjedhn sekuenciale q propozon proesi.
2. klientt e kan t vshtir t prcaktojn qart t gjitha k gjitha krkesat q n fillim.
Modeli linear krkon nj gj t till dhe e ka t vshtir t prshtas dhe t jap zgjidhje
pr pasigurit e natyrshme q ekzistojn fillimisht.
3. klienti duhet t ket durim. Ai nuk ka asnj version q punon t programit derisa arrin
prfundimi i projektit (koha mbaron). N rast se zbulohet nj e met e programit, e cila
ka kaluar e pazbuluar, ajo mund t ket pasoja shkatrruese.
4. zhvilluesit vonohen pa nevoj. Ata bllokohen duke pritur antar t tjer t ekipit
derisa t prfundojn punt e tyre.
T gjitha problemet e prmendura m lart jan reale. Megjithat ky model ka rndsi t
veant sepse ai ofron nj template n t ciln mund t vendosen metodat e analizs,
modelimit, kodimit, testimit dhe suportit. Pavarsisht nga t metat, sht me mir t
prdoret ai sesa t kemi nj zhvillim t rregullt t software.
Modeli ujvar (waterfall)
Ky model sht nj zgjerim i modelit linear. Ai lejon q fazat ti japin feedback njra tjetrs.
Psh problemet q identifikohen n fazat e mvonshme, mund t zgjidhen duke iu rikthyer
fazave t mparshme. do faz sht e prcaktuar qart dhe e dallueshme nga t tjerat.
do faz ushqehet me dokumentimin e gjeneruar nga faza paraardhse.
Analize

Gjenerohet dokument i specifikimit t kerkesave


Design/
Modelim

Prodhohet dokument me specifikime t design


Kodim

Module t implementuar

Testim

Module t
testuara

Mirembajtje

Produkt i modifikuar

- 11 -

Inxhinierimi i software

Leksion II

Ky model pershtat me veshtiresi ndryshimin prandaj sht i pershtatshem vetem kur


kerkesat jane t percaktuara mir q n fillim dhe nuk do t ndryshojne me kalimin e kohes. Nuk
ka nj ndarje t qarte n faza, por procedohet sepse lejon ndarje t punes n njerez t
ndryshem (analist, dizenjues, programues, testues)
Modeli Build and fix

sht nj model q synon t jap zgjidhje t momentit, pa parashikuar situata t s ardhmes. N


kt rast, modeli nuk ndjek ndonj struktur t caktuar. Produkti zhvillohet pa kaluar neper
fazat e specifikimit dhe modelimit. Ai funksionon me programe q nuk kan m shum sesa 100
rreshta kod. Rradha e veprimeve t proesit sht: shkruaj kod, rregullo gabime, thekso
funksionalitetin. Duke qene se kodi rishikohet vazhdimisht, programi shndrrohet n nj
produkt t ngatrruar, dhe t vshtir pr tu rregulluar.
Ky model nuk sht i pershtatshm pr projekte t mdhenj sepse n nj koh t gjat, mund t
ndryshoj prbrja e ekipit, mbetet vetm kodi q sht i veshtir pr tu rregulluar, krkesat e
prdoruesit nuk prshtaten lehtsisht n projekte t mdha.
Zhvillimi bhet i paparashikueshm, i pakontrollueshm, jasht afatit kohor dhe mbi buxhet.
Duket q mungon rigoroziteti q ishte i pranishm n modelin waterfall dhe q sht i
domosdoshm pr zhvillimin e nj projekti t suksesshm.

Modeli me prototipe (prototyping model)


Shpesh, nj klient cakton nj bashksi objektivash t prgjithshme pr software, por nuk
percakton dot formen e detajuar t informacionit hyrs, krkesa t proesimit ose informacionit
dales. N raste t tjera, nj zhvillues nuk sht gjithmon i bindur pr shkalln e optimizimit t
algoritmit t tij, pershtatshmrin e sistemit operativ, etj. N keto raste, si dhe n t tjer t
ngjashm, paradigmi i prototipeve sht efikas.
Paradigmi i prototipeve fillon me mbledhjen e
krkesave. Zhvilluesi dhe klienti takohen pr t
prcaktuar objektivat e pergjithshme t sistemit,
identifikojn krkesat e dukshme dhe
prcaktojn ato fushat ku duhet m tepr
prcaktim. M pas bhet nj modelim i shpejt.
Ky modelim i shpejt fokusohet tek ato aspekte
q
do
t
jen
t
dukshme
pr
klientin/prdoruesin.

- 12 -

Inxhinierimi i software

Leksion II

Ky modelim i shpjet on n krijimin e prototipit. Ai vlersohet nga klienti dhe perdoret pr t


prpunuar m tej krkesat e software q do t zhvillohet. Kur prototipi prshtatet q t
plotsoj nevojat e klientit dhe n t njjtn koh ndihmon zhvilluesin t kuptoj m mire at
q duhet t bhet, ndodh nj iteracion.
Prototipi shrben si nj mekanizm pr t identifikuar krkesat e software. Por far duhet br
me prototipin pasi ai ka kryer funksionet e prmendura? Nj pergjigje pr kt shtje jep Fred
Brooks ne librin e tij The Mythical Man Month: Essays on Software Engineering:
N pjesen me t madhe t projekteve, sistemi q ndertohet n fillim perdoret me
veshtiresi. Ai mund t jet shum i ngadalte, shum i madh, shum i nderlikuar ose t
treja bashke. Nuk ka alternative tjeter, pervec se t filloj nga e para ndertimi i sistemit,
me nj version t rimodeluar ku problemet jan zgjidhur Kur perdoret nj teknogji e re
ose mnyr e re konceptimi, duhet t ndertohet se pari nj sistem i cili do t hidhet tutje
(throw away) sepse edhe planifikimi me i mir nuk mund ti beje gjerat si duhet q heren
e par. Pyetja e menaxhimit ketu sht nese duhet planifikuar nj ndertimi i nj sistemi
pilot q nuk do t perdoret me vone. Kt do ta beni me siguri. Ceshtja e vetme sht
nese do t planifikohet q me par versioni q do t hidhet, apo do t vendoset q ky
version ti jepet klientit si version paraprak i sistemit
Prototipi mund t sherbeje si sistem fillestar. Perdorimi i prototipeve sht i pelqeyer si nga
prdoruesit ashtu dhe nga zhvilluesit. Prdoruesit kane mundesine t krijojne idene n lidhje me
sistemin q do t kene, zhvilluesit mund t fillojne t punojne me dika menjehere.
Modeli me prototipe mund t jet problematik pr disa arsye:
1. klienti prdor prototipin dhe krijon idene lidhur me versionin n pune t sistemit, duke
mos qene i ndergjegjshem q po punon me nj version n t cilin nuk eshte menduar
pr cilesine, pr mirembajtjen pr periudha t gjata. Kur ai informohet q duhet sistemi
duhet rindertuar n mnyr q t arrihen nivele me t larta cilesie dhe q sistemi t
mund t jet i mirembajtshem, klienti kerkon t behen pak ndryshime q prototipi t
funksionoje. Prototipet mund t cojne n pretendime jorealiste t prdoruesit.
2. zhvilluesit bejne shpesh kompromise implementimi n mnyr q t krijojne shpejt nj
prototip qe funksionon. Shembuj jane zgjedhja e nj gjuhe programimi apo nj sistemi
shfrytezimi t papershtatshem, pr q zgjidhen thjesht sepse disponohen dhe sepse ata
kane njohuri pr to, mund t implementohen algoritme t varfra. Me kalimin e kohes
zhvilluesi behet familiar me keto zgjedhje dhe harron q i ka zgjedhur si zgjidhje e
shpejte pr t ndertuar prototipin. Dhe, zgjidhja q ishte shum larg ideales, behet pjese
integrale e sistemit.
Megjithe problemet q paraqet, paradigmi i prototipeve mund t jet nj zgjedhje efektive n
rast se percaktohen q n fillim rregullat e lojes, dmth q klienti dhe zhvilluesi t bien dakort q
prototipi do t sherbeje si mekanizem pr t percatuar kerkesat.
Modeli me prototipe mund t perdoret n ato raste kur klienti ka nj nevoje t ligjshme por nuk
ka ide t qarta n lidhje me detajet. sht mir q zhvilluesit ti rezistojne idese pr t
transformuar prototipin n nj produkt, sepse sht cilesia ajo q demtohet.
Hedhja (throw away) e prototipit sht nj rast jo gjithmone realist. Mund t perdoret dhe
modeli me prototip evolues (evolutionary prototyping) ku prodhohet nj prototip fillestar dhe ai
riperpunohet nepermjet disa fazave deri sa arrihet sistemi final. Objektivi sht t krijohet nj
sistem pr prdoruesin q funksionon, n faza jo shum t vonshme. Zhvillimi fillon me ato
krkesa q jane kuptuar me mir, nderkohe tek throw away prototyping, zhvillimi fillon me ato
krkesa q jan ndrtuar m varfr.

- 13 -

Inxhinierimi i software

Leksion II

Modeli RAD (Rapid Application Development Model)


Ky model sht nj model inkrementues i proesit t zhvillimit dhe fokusohet tek nj cikel
shum i shkurtr zhvillimi. RAD sht nj pershtatje e modelit linear pr t marre nj proes
shum t shpejt. Ky zhvillim i shpejt arrihet duke ndrtuar nj software bazuar mbi
perdorimin e komponenteve. Nqs kerkesat jane t kuptuara mir dhe hapesira e software
sht e kufizuar, atehere modeli RAD mundeson q ekipi zhvillues t krijoje nj sistem
funksional brenda periudhave shum t shkurtra (60 90 dite). Fazat n t cilat kalon ky procesi
q ndjek kt model jane:
Modelimi i biznesit: Rrjedha e informacionit n funksionet e biznesit modelohet n mnyr q
tu jepet pergjigje pyetjeve t meposhtme: cili sht informacioni q udheheq procesin e
biznesit, cfare informacioni gjenerohet, kush e gjeneron ate, ku shkon informacioni, kush e
proceson ate?
Modelimi i t dhnave: Rrjedha e informacionit e percaktuar si pjese e fazes se modelimit t
biznesit, perpunohet dhe shnderrohet n nj bashkesi objektesh t t dhnave q nevojiten pr
t mbshtetur biznesin. Identifikohen karakteristikat (t quajtura atribute) e objekteve dhe
lidhjet ndrmjet tyre.
Modelimi i proesit: objektet e t dhenave t percaktuara n fazn e modelimit t t dhnave,
transformohen n mnyr q t arrihet nj rrjedhe informacioni q t permbushe kerkesat e
biznesit.
Gjenerimi i aplikimit. RAD prdor teknikat e brezit t katert. Ai nuk kufizohet n perdorimin e
gjuheve t programimit, por punon pr t riperdorur komponente ekzistuese t programeve
(kur sht e mundur) dhe pr t krijuar komponente t riperdorshme (kur sht e nevojshme).
N t gjitha rastet, perdoren mjete automatizuese pr t lehtesuar ndertimin e software.
Testimi. Duke qene se RAD thekson riperdorimin, shum komponente programesh jane t
testuara dhe kjo e ul ndjeshem kohen e nevojshme pr testim. Megjithate komponentet e reja
kane nevoje pr testim, ashtu sikurse dhe integrimi i tyre dhe nderfaqet q krijohen pr ti
integruar.

- 14 -

Inxhinierimi i software

Leksion II

Mqs modeli RAD imponon kufizime t medha n kohe, hapesira e softwareve n zhvillimin e t
cileve mund t perdoret duhet percaktuar me kujdes. Nqs nj aplikim biznesi mund t
modularizohet n mnyr q do funksion kryesor t realizohet n m pak se tre muaj, atehere
ai sht kandidat pr RAD. do funksion kryesor mund t realizohet nga nj ekip i veant dhe
me pas t integrohen pr t formuar t trn.
T metat:
1. pr projekte t medha q mund t coptohen, RAD kerkon burime t konsiderueshme
njerzore pr t krijuar numrin e nevojshem t ekipeve.
2. RAD krkon prkushtim t madh si nga zhvilluesit ashtu dhe nga klientt pr t arritur
zhvillimin n koh.
3. RAD perfshin zgjidhje modulare. Nqs sistemi nuk mund t modularizohet sic duhet,
atehere ndertimi i komponenteve mudn t jet problematik. RAD nuk sht i
prshtatshm pr ato sisteme n t cilat performance sht e rndsishme sepse
integrimi i komponenteve mund t sjell ulje t saj.
4. RAD nuk sht i prshtatshm kur rreziqet teknike jan t larta. Kjo ndodh kur nj
aplikim prdor shum (veprimtaria e tij varet shum) teknologji t reja ose kur sistemi
krkon shum ndrveprim me programe ekzistues.

Referenca:
[1] Software Engineering A Practitioners approach, Roger S. Pressman
[2] IT Projec Management in Practice
[3] Software Engineering Institute

- 15 -