Modelet Evoluese Te Proceseve

Inxhinierimi i software Leksion III

- 1 -

3. Cikli jetesor i software. Modelet e proceseve te ciklit jetesor Proesi i zhvillimit t software kalon npr pes faza:

1. analiza dhe prcaktimi i krkesave (specifikimi) 2. modelimi (design) i sistemit dhe software 3. implementimi 4. integrimi i dhe testimi (validation) 5. mirmbajtja

Specifikimi i software sht proesi i prcaktimit t shrbimeve dhe funksioneve t sistemit si dhe i kufizimeve t veprimeve dhe gjat zhvillimit t sistemit. Proesi i inxhinierimit t krkesave prfshin:

studimin e aftsive praktike pr t realizuar at q krkohet (feasibility study). Pyetja q shtrohet: A mund ta bjm n koh dhe n mnyr efektive?

nxjerrja dhe analiza e krkesave (requirements elicitation and analysis) Pyetja q shtrohet: far duhet t bj sistemi.

specifikimi i krkesave (requirements specification) do gj shkruhet.

vlersimi i krkesave (requirements validation) a kan kuptim t tra kto q u nxorrn?

Modelimi i sistemit sht proesi i konvertimit t specifikimit t krkesave n nj sistem t ekzekutueshm. Modelohet struktura e software q realizon krkesat e specifikuara dhe perkthehet ky model n nj program t ekzekutueshm. Nnfaza t modelimit jan: modelimi i arkitekturs, specifikime abstrakte, modelimi i ndrfaqes, modelimi i komponenteve, modelimi i strukturs s t dhnave, modelimi i algoritmeve. Modelimi realizohet nprmjet rrugve t standartizuara. Ai dokumentohet si nj bashksi modelesh grafik si psh. modeli i rrjedhs s t dhnave (data-flow model), modeli i lidhjeve njesi-atribut (entity relation atribute model), modeli i strukturave, modelet e objekteve.


- 2 -

Implementimi dhe debugging sht proesi i prkthimit t modelit n nj program dhe heqja e gabimeve nga ai program. Programimi sht nj aktivitet personal, nuk ka nj proces t pergjithsuar pr t. Programuesit gjat ksaj faze bjn testime pr t gjetur gabime dhe i rregullojn ato. Testimi bhet pr t krijuar nj ide pr cilsin dhe pranueshmrin e software dhe pr t zbuluar problemet. Testohet sepse jemi t ndrgjegjshm q gabojm.

Gjat testimit bhet: testimi i moduleve/ njsive: sht proesi i ekzektutimit t do moduli pr t konfirmuar q secili kryen funksionin q i ishte caktuar. testimi i integrimit: testohet integrimi i moduleve. Gjat ksaj faze t testimit, sistemi ndrtohet gradualisht duke shtuar nj ose dy module do her. Testohet funksionimi i grupeve t moduleve. testimi i sistemit: pas testimit t integrimit, sistemi testohet si nj i tr pr funksionalitetet dhe prshtatshmrin e tij me ato cka jan krkuar n fillim. Ai verifikon nese funksionet jan plotsuar sic duhet, gjithashtu verifikon nse jan t pranishme dhe karakteristika jofunksionale (testimi i performances, i dokumentimit, etj). Sistemet testohen plotesisht n mjedise q operojn me kompjutera, prpara se t behet pranimi i sistemit.


- 3 -

testimi pranues: vrteton q software plotson tr krkesat fillestare. N kt lloj testimi, sht perdoruesi fundor i programit (q nuk ka njohuri teknike) ai q teston programin dhe kontrollon nse jan realizuar ato q jan krkuar Evoluimi i software (mirembajtja) Software sht fleksibl dhe ndryshon. Krkesat ndryshojn si pasoj e ndryshimit t rrethanave t biznesit, pra dhe software duhet ti nnshtrohet ndryshimit t vazhdueshm. Zhvillimi dhe mirembajtja jan pare si faza t veanta, por kjo ndarje po bhet gjithmon e m e paprshtatshme duke qen se gjithmon e m pak sisteme jan trsisht t rinj.

Modelet evoluese (iterative) t proeseve t zhvillimit t software

Gjithmon e m shum po pranohet q software, ashtu si shum sisteme t tjer kompleks, evolon n koh. Ndrkoh q po ndrtohet software, mund t ndodh q t ndryshojn rregullat e biznesit. Zhvillimi i software si nj i tr nga fillimi n fund, do t onte n nj produkt jo realist. Afatet e shkurtra kohore e bjn t pamundur zhvillimin e nj produkti cilsor dhe t plot. Megjithat mund t lshohet nj version i kufizuar, q prmbush deri diku krkesat e nj biznesi q ushtron presion dhe q prballon konkurrencn. sht kuptuar nj bashksi baz krkesash t produktit, por nuk jan prcaktuar akoma detaje dhe specifika t sistemit. N kto raste dhe, n raste t ngjashme me to, inxhiniert e software kan nevoj pr nj model q sht krijuar enkas pr produkte q do t evolojn me kohn.

Modeli linear sht ideuar pr nj zhvillim q finalizohet me nj produkt t plot (straight-line development). Modeli me prototipe sht modeluar q ti vij n ndihm klientit (ose zhvilluesit) pr t kuptuar krkesat m mir. N prgjithsi ai nuk sht menduar pr t ndrtuar nj sistem t plot. N asnjrn prej ktyre paradigmave klasike t inxhinierimit nuk sht parashikuar natyra evoluese e software.

Pr zgjidhjen e problemeve, n prgjithsi kryen shum aktivitete. sht logjike dhe parimisht korrekte q duhet t kuptohet problemi, t mblidhen krkesat, t perkthehen kto krkesa n nj model, t ndrtohet dhe t testohet zgjidhja. Vshtirsit hasen kur mblidhen t gjitha krkesat, kur bhet i gjith modelimi, kur behet gjith zhvillimi dhe gjith testimi n nj mnyr lineare (sekuenciale).

N t vrtet sht mir q t ndiqet nj praktik pune si n shkencn moderne, e bazuar n parimin e vezhgimeve direkte: propozohen teori, pastaj mendohen dhe bhen eksperimente pr t testuar kto teori. Bazuar n rezultatet e matshme, teorit pranohen ose hidhen posht. Edhe n projektet e zhvillimit t software, shum pjes t tyre, sjan gj tjetr vese pohime q kan nevoj t vlersohen dhe t testohen. Vet plani prbhet nga shum pohime t cilat prcaktojn sesa do t zgjas do veprim prgjat projektit. Krkesat jan pohime n lidhje me karakteristikat e nj zgjidhje t mundshme, t prshtatshme. Edhe ato duhet t vlersohen pr t pare nse vrtet do t onin n nj zgjidhje t prshtatshme t problemit q duhet zgjidhur.

T tra kto arsyetime ojn n prshtatjen e nj modeli proesi q t bj nj vlersim t vazhdueshm t pohimeve q jan prfshir n planifikim, nprmjet modelimit dhe zhvillimit t versioneve t demostrueshm t sistemit. Secili prej ktyre versioneve vlersohet q t arrihet nj ulje e rrezikut (pr deshtimin e projektit) dhe secili ndrtohet mbi versionet e mparshme derisa arrihet nj version prfundimtar q jep zgjidhjen e plot t problemit. Kjo mnyre zhvillimi njihet si zhvillimi iterativ dhe inkrementues (iterative and incremental development). Karakteristikat kryesore jan:


- 4 -

prfshin zbatimin e nj bashksie veprimesh iterative (t prsritura) pr t vlersuar prcaktimet e bra n lidhje me planifikimin dhe mnyrn e zgjidhjes s problemit, shmang nj bashksi rreziqesh, prmbush nj sr aktivitetesh q lidhen me zhvillimin e software dhe prodhon e prmirson n mnyr inkrementuese zgjidhjen e problemit.

sht iterativ sepse ai mundson nj kuptim m t mir t problemit, prcaktimit zgjidhjes s problemit, implementit t saj duke prsritur aktivitete themelore t zhvillimit t software (analize, modelim, kodim, testim)

sht inkrementues sepse do cikl npr t cilin kalohet rrit kuptimin e problemit dhe cilsit e zgjidhjes s ofruar.

prsritje t shumta t cikleve iterative (ciklet perseriten n mnyr sekuenciale) formojn projektin.

Proesi i zhvillimit t software duhet t jet iterative dhe inkrementues. Nqs proesi do t ishte vetm iterative dhe jo inkrementues, atehere do t kishte nj perseritje t vazhdueshme t aktiviteteve pa arritur t permbushen qllimet prfundimtare t projektit, dmth pa ulur rrezikun dhe pa ndertuar zgjidhjen n mnyr inkrementuese. Kur thuhet proes iterative (pr arsye shprehjeje) nnkuptohet proes iterative dhe inkrementues. Nj iteracion mund t prcaktohet si nj mini-projekt m vete, me nj rezultat t prcaktuar qart: nj version t qndrueshm, t integruar dhe t testuar t sistemit (version i ekzekutueshm). Perkufizimi ka tre aspekte:

iteracioni sht nj mini-projekt me vete: projekti i zhvillimit t software (q kthen nj bashksi krkesash n nj produkt t ri apo t ndryshuar) realizohet duke e ndar at n mini projekte dhe secili sht (quhet) nj iteracion. Iteracioni permban do gj q prmban nj projekt i plot: planifikim si dhe hapat baz t zhvillimit t software (mbledhje kerkesash, analize, modelim, implementim, testim). Megjithat, nj iteracion nuk sht nj njsi trsisht e pavarur, por esht nj pjes e vogl e nj projekti m t madh dhe varet shum nga ky fakt. Thuhet q sht mini projekt sepse nuk sht ajo ka duan prdoruesit n fund t projektit.

iteracioni ka nj bashksi t mire prcaktuar aktivitetesh. do iteracion sht unik. Ai nnkupton ndrmarrjen e nj sr aktivitetesh unike pr t prodhuar nj version unik t produktit i cili demostron n mnyr objektive q jan arritur apo jo qllimet e iteracionit n fjal. Duke qen se do iteracion sht unik, ai ka nevoj pr nj plan t vetin i cili duhet t permbaj detajet lidhur me veprimet q duhet t bj grupi i puns pr t plotesuar objektivat e iteracionit. Niveli i planifikimit varet nga: rreziku i projektit (rrezik pr dshtim), madhsia e ekipit, nivelet e prvojs t ekipit si dhe stili i preferuar pr t menaxhuar i menaxhuesit. Planifikimi i iteracionit duhet: t vendos objektivat q do t arrihen n fund t iteracionit dhe t vendos kritere vlersimi; t vlersoj burimet n dispozicion dhe t planifikoj n koh veprimtarit. N nj moment t caktuar nuk punohet m shum sesa me planet e dy iteracioneve: njri pr t menaxhuar iteracionin korent dhe tjetri q sht nj skic q rritet vazhdimisht, pr iteracionin tjetr. Kjo shmang ndertimin e planeve m t detajuar nga duhet dhe inkurajon zhvilluesit t prqndrohen n arritjen e rezultateve t menjhershme.

do iteracion rezulton n nj version t ekzekutueshm t software. Pr tu siguruar q projekti po bn progres, sht e detyrueshme q do iteracion t prodhoj dika t prekshme, nj lshim (release). Ai mund t jet:

o nj prototip q perdoret pr t demostruar disa aftsi specifike.


- 5 -

o nj version i brendshm, q mund t prdoret pr t marr feedback dhe si baz pr zhvillim dhe testim t mtejshm.

o nj version i jashtm, q i jepet n nj far mnyre klientit. Kur prmendet termi lshim i nj versioni t produktit, nuk duhet nnkuptuar gjithmon dika q i jepet klientve, njerzve q sjan pjes e ekipit zhvillues. Duhet nnkuptuar dika q mund t ekzekutohet dhe vlersohet duke prfshir elemente q mund t vlersohen vetm n mjedisin zhvillues (prototipe) si dhe element q mund t lshohen n mjedisin e jashtm. Lshimet e para jan versione jo t plota t sistemit q demostrojn karakteristikat m t rndsishme q duhet t ket sistemi si dhe t adresojn rreziqet kryesore teknike me t cilat prballet ose mund t prballet projekti. Me kalimin e kohs, ktyre versioneve u shtohen karakteristika q e plotsojn gjithmon e m shum software si nj t tr dhe q mund ti jepet klientit. Shembuj t rezultateve t nj iteracioni mund t jen:

o prova e konceptimit perdoret nga grupi zhvillues dhe demostron ose sherben pr t percaktuar aftesite praktike pr t ndertuar sistemin (feasibility)

o prototipi, audience sht ekipi zhvillues dhe sherben pr t demostruar disa nga aftesite dhe karakteristikat q duhet t kt sistemi

o leshim (version) i ndermjetem, audience sht ekipi dhe sherben pr t marre feedback nga perfaqesuesit e klientit dhe pr t demostruar progresin

o version test i produktit q perdoret nga klientet dhe q shrben pr t marr feedback nga prdoruesit.

o version i produktit q ploteson krkesa t pergjithshme, perdoret nga prdoruesit dhe ofron perfitime biznesi dhe ploteson standarte cilesie

o version i plote i produktit, q perdoret nga klientet dhe q shrben pr t rregulluar gabimet, si dhe pr t ofruar sipas rastit zgjerime t software.

Rezultati i nj iteracioni shnderrohet n nj version t plote t produktit kur ai leshohet n nj mjedis operacional pa kufizime.

Kombinimi i tre elementve t msiprm t zhvillimit iterativ e bn at t fuqishm.

Funksionimi i nj iteracioni si nj projekt m vete, bn q nj iteracion t mund t menaxhohet leht dhe bn q ekipi t ket nj focus t menjhershm mbi t. Strukturimi i projektit n nnprojekte lejon q t zvoglohet kompleksiteti i projektit duke adresuar probleme dhe rreziqe specifike n iteracione specifike.

Mqs do iteracion ka nj bashksi t pcaktuar aktivitetesh dhe do iteracion merret me nj bashkesi t percaktuar dhe unike rreziqesh, ather cdo iteracion zgjidh keto probleme dhe e con perpara projektin. Iteracione t suksesshme q ndertohen mbi bazen e t mparshmeve, rrisin n mnyr inkrementuese performancen e projektit dhe zgjidhjen e tij. Modele proesesh q zbatojn filozofin e nj zhvillimi iterative dhe inkrementues, t prshkruar m lart jan:


- 6 -

Modeli inkrementues (incremental model) Ky model kombinon elemente t modelit linear me filozofin iterative.

Si kuptohet n figur, ky model aplikon fazat e modelit linear n mnyr t alternuar n koh. Cdo sekuenc lineare prodhon nj inkrement t software (version t tij). Psh. software t proesimit t fjalve q mund t zhvillohen duke perdorur paradigmen iterative, mund t leshohen n fillim me funksione si psh menaxhimi i skedarve, funksione edituese, prodhim i dokumentave. N inkrementet pasardhse mund t leshohen funksione m t sofistikuara t editimit dhe prodhimit t dokumentave, funksione t kotrollit t gramatikes, etj. Kur perdoret modeli inkrementues, inkrementi i par quhet n pergjithesi produkti baze (core product). Kjo do t thote q jane adresuar disa nga kerkesat themelore por t tjera, shtes (disa t njohura e disa t panjohura) nuk jane plotesuar akoma. Produkti baz perdoret nga klienti. Per iteracionin tjeter hartohet nj plan tjeter. Ky plan perfshin modifikimin e produktit baze pr t plotesuar m mir nevojat e prdoruesit si dhe pr t realizuar fuksionet e kerkuara q nuk ishin perfshire n t. Ky proces perseritet vazhdimisht derisa arrihet produkti perfundimtar.

Zhvillimi inkrementues i cakton krkesave t prdoruesit nj prioritet dhe ato me prioritet me t lart realizohen n inkrementet e para. Kur fillon zhvillimi i inkrementit, kerkesat q do t realizohen tek ai ngrijn, pavarsisht se krkesat pr inkrementet e tjera mund t vazhdojn t evolojn.


- 7 -

Modeli spiral

Modeli spiral i Boehm (fig marre nga A spiral model of software development and enhancement, Barry Boehm). Distanca nga origjina perfaqeson koston e akumuluar te projektit. Kendi nga boshti horizontal perfaqeson tipin e aktivitetit.

Modeli spiral sht zhvillluar rreth viteve 80. Ai sht perkufizuar pr her t par nga Barry Boehm n 1988. Ky model filloi t zhvillohej pr t prmirsuar t metat e modelit waterfall dhe vecanrisht pr t trajtuar ndryshimet jo frekuente gjat ciklit jetsor t zhvilimit t software. Ky model bazohet n aktivitetet e modelit waterfall, por shton dhe aktivitete shtes si menaxhimi i rrezikut, riprdorimi dhe krijimi i prototipeve. Keto aktivitete shtes prbjn t ashtuquajturat cikle te spirales. Modeli spiral prqendrohet tek trajtimi i rrezikut n mnyr inkrementale, sipas nj prioriteti. Cdo cikl prbhet nga katr faza. Gjat fazes se pare zhvilluesit gjejn alternativa, prcaktojn kufizime dhe identifikojne objektiva. Gjate fazes se dyte, zhvilluesit menaxhojn rreziqet e mundshme t zgjidhjeve t propozuara n fazn e par. Gjat fazes se trete zhvilluesit krijojn dhe vlersojn nj prototip t asaj pjes t sistemit q lidhet me rreziqet e trajtuara n kt cikl. Faza e katert e ciklit prqndrohet n planifikimin e ciklit tjetr duke u bazuar n rezultatet e ciklit te momentit. Faza e fundit e ciklit zakonisht sht rishikim nga pjesmarrsit e projektit i produkteve t prodhuara gjat ciklit. Produktet q rishikohen mund t jen prodhuar n ciklin e momentit apo n ciklet e mparshme. Planifikimet pr ciklin e ardhshm i nnshtrohen gjithashtu rishikimeve n ket faz. N modelin spiral pergjithsisht dallohen kto cikle kryesore:

1. konceptimi i operimit t software 2. krkesat e software 3. modelimi i produktit software


- 8 -

4. modelim i detajuar 5. kodimi 6. testimi njsi 7. integrimi dhe testimi 8. testimi i pranimit 9. implementimi/ instalimi n mjediset operuese

Cdo cikel ndjek modelin waterfall dhe perfshin keto aktivitete: 1. prcaktimi i objektivave 2. specifikimi i kufizimeve 3. gjenerimi i alternativave 4. identifikimi i rreziqeve 5. gjetja e zgjidhjeve per trajtimin e rreziqeve 6. zhvillimi dhe verifikimi i produktit te nivelit tjeter 7. planifikim

Dy aktivitetet e para prcaktojne problemin e trajtuar nga cikli i momentit. Gjenerimi i alternativave prcakton hapsirn e zgjidhjeve (t mundshme). Identifikimi i rreziqeve dhe trajtimi i rreziqeve identifkojn probleme t ardhshme q mund t rezultojn n kosto t larta dhe anullim t projektit. Realizimi konkret i ciklit realizohen tek aktivitetet zhvillim dhe verifikim i produktit te nivelit tjeter. Aktiviteti planifikim sht nj aktivitet menaxhimi dhe shrben si prgatitje pr ciklin tjetr. Planifikimi duhet t jet i till q t trajtoj n mnyr efektive rreziqet e identifikuara. Vihet re, q ky model mban nn kontroll t vazhdueshm rrezikun (problem potenciale) dhe sht mjaft fleksibl pr ta trajtuar at. N lidhje me modelin spiral lindin katr pyetje:

1. kur dhe si fillon spiralja 2. si mund t ndrpritet ajo nse projekti duhet t mbaroj m shpejt 3. pse mbaron spiralja n mnyr kaq t prer 4. cndodh me mirmbajtjen?

Vzhgimet kan treguar q spiralja mund t zbatohet njsoj si n zhvillim ashtu dhe n mirmbajtje. N t dy rastet, spiralja fillon kur hidhet hipoteza q nj problem real mund t zgjidhet me ndihmen e nj software. M pas procesi spiral bn nj test mbi hipotezen. Nqs, n cfardo momenti, ky test dshton (psh nqs vonesat do t shkaktonin humbje t tregut pr produktin, ose nqs del nj produkt tjeter, superior ndaj ktij q po zhvillohet), ateher spiralja ndrpritet. Prndryshe ajo perfundon me instalimin e nj software t ri ose t modifikuar dhe hipoteza testohet duke par efektin e software t ofruar n zgjidhjen e problemit. Zakonisht, duke par software n pune, lindin hipoteza t reja mbi permiresimin e tij dhe, nis nj spirale e re, pr mirembajtjen, pr t testuar kt hipoteze t re.


- 9 -

Modeli i njekohshem (Concurrent development model)

Gjendjet neper te cilat kalon Analiza e software

Ky model percakton nj bashkesi veprimesh q do t shkaktojne kalimin nga nj gjendje n nj tjeter, pr seciln nga aktivitet e inxhinierimit. Psh. gjat modelimit gjendet ndonj pasaktsi n analize. Kjo gjeneron ngjarjen e korrektimit t modelit t analizes q do shkaktoje kalimin e analizes nga gjendja perfunduar n gjendjen duke pritur pr ndryshime. Modeli i njkohshem sht zakonisht paradigmi i prdorur pr t ndertuar aplikime klient-server. Kto aplikime prbhen nga shum komponente q mund t modelohen dhe realizohen njekohesisht. Ky model mund t perdoret pr t gjitha tipet e zhvillimit t software dhe jep nj pamje t gjendjes aktuale t projektit. Ai prcakton m tepr nj rrjet t aktiviteteve sesa nj sekuenc t realizimit t tyre. Cdo aktivitet n rrjet ekziston njkohesisht me aktivitete t tjera. Ngjarje q gjenerohen brenda nj aktiviteti ose diku tjeter n rrjet shkaktojne kalim nga njra gjendje n tjetrn. Modeli i bazuar n komponente (Component based development) Ky model funksionon mbi kornizen/ bazen (framework) q ofrojne teknologjit e orientuara nga objektet. Paradigmi i orientuar nga objektet thekson krijimin e klasave q enkapsulojn t dhna dhe algoritme. Kto klasa mund t riprdoren n aplikime t tjera nqs ato jan modeluar mir. Modeli i bazuar n komponente prdor shum nga karakteristikat e modelit spiral. Ai ka natyr iterative. Por ai i krijon software nga paketa t gatshme komponentesh (klasa). Inxhinierimi n kt model fillon me identifikimin e klasave kandidate. Kjo realizohet duke ekzaminuar t dhnat q do t manipulohen nga aplikimi dhe algoritmet q do t perdoren pr t kryer kto manipulime. T dhnat dhe algoritmet korresponduese paketohen npr klasa.

Modeli i njekohshem mund t paraqitet skematikisht si nj seri aktivitetesh, detyrash teknike dhe gjendja e tyre. N figure paraqitet njera prej aktiviteteve t inxhinierimit, analiza. Aktivitete t tjera si psh modelimi mund t paraqiten n t njejten mnyr. T gjitha veprimtarite ekzistojn n t njjtn koh, por n gjendje t ndryshme. Psh, komunikimi me klientin ka perfunduar iteracionin e pare dhe sht n gjendjen duke pritur pr ndryshime. Analiza (q ishte n gjendjen asgj nderkohe q kryhej komunikimi me klientin) kalon n gjendjen n zhvillim. Por nqs klienti paraqet ndryshime n krkesa, analiza kalon nga gjendja n zhvillim n gjendjen duke pritur pr ndryshime.


- 10 -

Pasi identifikohen klasat kanditate, kontrollohet nse ato ekzistojn npr librari. Nqs ekzistojn, ato riprdoren. Prndryshe, ndrtohet inkrementi i pare duke prdorur klasat ekzistuese dhe duke ndrtuar ato q nuk gjendeshin dhe q jan pr nevoja specifike t ktij aplikimi. M pas, rrjedha e proesit kthehet tek spiralja dhe i nnshtrohen m pas iteracionit t bashkimit t komponenteve. Ky model i drejton inxhiniert e software drejt riprdorimit, q ka nj sr prfitime pr ta. Bashkimi i komponenteve on n shkurtim t kohzgjatjes s ciklit jetsor rreth 70%, 84% ulje t kostos se projektit. Megjithat, kto avantazhe varen nga cilsia e paketimit t klasave.

Procesi i unifikuar (Unified Process - UP) Software qe kerkohen dhe krijohen sot jane gjithmone e me kompleks. Kjo eshte edhe rrjedhoje e faktit qe kompjuterat fuqizohen shpejt, gjithmone e me shume dhe perdoruesit kane pritshmeri gjithmone e me te medha prej tyre. Perdorimi gjithmone e me i madh i internetit ka ndikuar ne prirjen e njerezve per te shkembyer shpejt sasi te medha te dhenash, duke nxitur kerkesen e tyre per software gjithmone e me kompleks. Gjithashtu, njerezit kuptojne qe nga njeri version ne tjetrin, ne pergjithesi ka shume evolim te software dhe me shume perputhshmeri me kerkesat e tyre. Pra, njerezit kerkojne gjithmone e me shume nga software. Procesi i unifikuar eshte ne nje fare menyre, nje perpjekje per te kombinuar cilesite me te mira te modeleve tradicionale te proceseve me cilesite qe ka zhvillimi i software ne kontekstin e ndryshimeve te shpeshta te kushteve dhe kur grupi i punes se zhvillimit duhet te pershtatet vazhdimisht dhe me shpejtesi ndaj ketyre kushteve. Procesi i unifikuar konsideron shume te rendesishem komunikimin me klientin dhe metodat qe perdoren per te pershkruar pikepamjen e klientit per software qe do te ndertohet. Ky model thekson rolin e rendesishem te arkitektures se software dhe kerkon qe arkitekti te perqendrohet tek kuptueshmeria, lehtesia e pershtatjes ndaj ndryshimeve te ardhshme dhe tek riperdorimi. Modeli sugjeron nje rrjedhe iterative dhe inkrementuese te procesit, duke e bere evolues procesin e ndertimit te software.


- 11 -

Perpjekjet e studiueseve ne fillim te viteve 90 per te kombinuar praktikat me te mira te metodave te analizes dhe modelimit me objekte dhe per te pershtatur karakteristika te tjera te propozuara nga eksperte te tjere te fushes se zhvillimit te software cuan ne krijimin e gjuhes se unifikuar te modelimit (Unified Modelling Language UML). UML eshte nje gjuhe e pergjithshme (unifikuar) modelimi qe permban elemente te fuqishem dhe te qendrueshem per modelimin me objekte te sistemeve. Ajo u be standarti industrial i ndertimit te software me objekte ne vitin 1997. UML ofron teknologjine e nevojshme per te mbeshtetur zhvillimin me objekte, por nuk ofron nje kornize per procesin qe duhet te ndiqet nga ekipet e zhvillimit per te ndertuar keto sisteme. Me vone u krijua procesi i uifikuar me qellim qe te ofronte nje skelet mbi te cilen te bazohej puna per zhvillimin e sistemeve me objekte duke perdorur UML. Fazat neper te cilat kalon procesi i zhvillimit te software ne modelin UP jane:

1. Faza e fillimit (inception phase). Kjo faze permbledh komunikimin me klientin dhe planifikimin e puneve qe do te vijojne pergjate kohes qe do te zhvillohet software. Me konkretisht:

a. Identifikohen kerkesat e klientit per software qe duhet te ndertohet. Kerkesat thelbesore dokumentohen dhe paraqiten nepermjet rasteve te perdorimit qe zhvillohen (use cases). Ato pershkruajne karakteristika dhe funksionalitete te sisitemit qe kerkohen nga cdo grup i rendesishem i perdoruesve te sistemit.

b. Propozohet arkitektura e sistemit. Ne kete faze arkitektura identifikon komponentet/ nensistemet kryesore te sistemit dhe funksionet dhe karakteristikat e sistemit qe ato do te permbajne. Arkitektura detajohet dhe zgjerohet duke u pajisur me modelet qe do te paraqesin sistemin ne fazat e mevonshme te procesit.

c. Krijohet plani per mbarevajtjen e aktiviteteve te zhvillimit te software te cilat do te jene iterative dhe inkrementuese. Gjate planifikimit identifikohen burimet e nevojshme, rreziqet kryesore qe mund tI kanosen punes per zhvillimin e sistemit, pecaktohet nje vendosje ne kohe e aktiviteteve qe do te kryen. Te tera keto vendosin themelet per fazat qe do te ndermerren per zhvillimin e software ne menyre inkrementuese.

2. Faza e perpunimit (elaboration phase). Kjo faze permban aktivitetet e komunikimit dhe modelimit. Gjate fazes se perpunimit permiresohen dhe zgjerohen rastet e perdorimit te identifikuara gjate fillimit. Arkitektura zgjerohet per te paraqitur pese modele/pamje(perspektiva) te sistemit: modelin rasteve te perdorimit (si do te paraqitet nderveprimi i grupeve te perdoruesve me sistemin), modelin e kerkesave (si do te paraqiten kerkesat ne sistem), modelin e ideimit te sistemit (si do te ndertohet sistemi), modelin e implementimit (si do te modelohet sistemit), modelin e shperndarjes se sistemit (si do te shperndahet sistemi). Plani rishikohet me kujdes gjate kesaj faze per te siguruar qe percaktimi i puneve qe do te behen dhe qe sdo te behen, rreziqet dhe datat e dorezimit te jene realiste. Plani modifikohet shpesh gjate kesaj faze.

3. Faza e ndertimit (construction phase). Kjo faze perdor modelin arkitekturor si input dhe nderton ose siguron te gjithe komponentet software qe do te realizojne funksionet e kerkuara nga perdoruesit. Kerkesat dhe modelet e krijuara gjate fazes se perpunimit shtjellohen me shume, aq sa eshte e nevojshme per pasqyruar versionin final te inkrementit te software qe do te prodhohet. Te gjitha funksionalitet ndertohen ne kod. Gjate kesaj faze ideohen dhe ndertohen dhe ekzekutohen teste per secilin nga


- 12 -

komponentet. Komponentet integrohen me njera tjetren per te krijuar sistemin e plote. Nisur nga rastet e perdorimit, ndertohet nje bashkesi me menyrat e testimit te software, te cilat zbatohen tek software perpara se te kalohet tek faza pasardhese.

4. Faza e kalimit (transition phase). Gjate kesaj faze, software i jepet perdoruesve per testime dhe perdoruesit japin rezultatet e testimeve dhe gjetjet e tyre ne lidhje me software. Ekipi i zhvillimit krijon manualet e perdorimit, guidat per zgjidhjen e problemeve te mundshme, procedurat e instalimit, etj. Ne fund te kesaj faze, software eshte ne gjendje te perdorshme.

5. Faza e leshimit (production phase). Gjate kesaj faze kryen aktivitetet e leshimit te software tek mjediset ku ai do te perdoret realisht nga perdoruesit. Monitorohet perdorimi i software, ofrohet suport, raportohen defekte dhe trajtohen kerkesat e mundshme per ndryshime te software.

Mund te ndodhe qe nderkohe qe zhvillohen fazat e ndertimit, kalimit dhe leshimit te kete filluar puna per inkrementin tjeter te software. Kjo do te thote qe, fazat e UP nuk ndodhin rradhazi, por njekohesisht. Duhet kuptuar qe fazat qe zhvillohen njekohesisht u takojne iteracioneve te ndryshme te procesit per te ndertuar inkremente.

Documents

Modelet Evoluese Te Proceseve