-
Inxhinierimi i software Leksion II
- 1 -
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. 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.
mjete
metoda
proesi
fokus mbi cilesine
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,
-
Inxhinierimi i software Leksion II
- 2 -
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.
-
Inxhinierimi i software Leksion II
- 3 -
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.
-
Inxhinierimi i software Leksion II
- 4 -
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
-
Inxhinierimi i software Leksion II
- 5 -
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 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.
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 adres
Aktivitete t kornizes
- Detyra/Veprime
- Objektiva, produkte
- Sigurimi cilesise
-
Inxhinierimi i software Leksion II
- 6 -
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
Proceset
Modelimi i ciklit jetesor Zgjedhja e modelit te ciklit
jetesor
Menaxhimi i projektit Inicimi i projektit Monitorimi i projektit
dhe kontrolle Menaxhimi i cilesise se software
-
Inxhinierimi i software Leksion II
- 7 -
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
-
Inxhinierimi i software Leksion II
- 8 -
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
-
Inxhinierimi i software Leksion II
- 9 -
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.
-
Inxhinierimi i software Leksion II
- 10 -
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.
-
Inxhinierimi i software Leksion II
- 11 -
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
Design/
Modelim
Kodim
Testim
Mirembajtje
Gjenerohet dokument i specifikimit t kerkesave
Prodhohet dokument me specifikime t design
Module t implementuar
Module t testuara
Produkt i modifikuar
-
Inxhinierimi i software Leksion II
- 12 -
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.
-
Inxhinierimi i software Leksion II
- 13 -
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.
-
Inxhinierimi i software Leksion II
- 14 -
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.
-
Inxhinierimi i software Leksion II
- 15 -
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