l2- Procesi

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,


- 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.


- 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.


- 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


- 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


- 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


- 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


- 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


- 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.


- 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.


- 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


- 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.


- 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.


- 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.


- 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

Documents

l2- Procesi