Odrzavanje Sistema Aleksandar Stupar.docx

PANEVROPSKI UNIVERZITET APEIRON FAKULTET INFORMACIONIH TEHNOLOGIJA

O D R Z A V A NJ E S I S T E M A (Seminarski rad)

Predmet:

Softverski inzenjering sa objektnim programiranjem

MENTOR:

STUDENT:

Prof. dr Zoran Avramovic

Aleksandar Stupar Broj indeksa: 57-15 RPI-S

Banja Luka, decembar, 2018. godine

SADRZAJ

Sadrzaj UVOD ....................................................................................................................................................... 3 ODRZAVANJE SISTEMA I SOFTVERSKO INZENJERSTVO ........................................................................... 4 Klasifikacija i strategije mijenjanja sistema i aspekti softverskog inzenjerstva....................................... 4 Evolucija softvera ................................................................................................................................ 5 Izgradnja sistema ................................................................................................................................... 14 Zakoni evolucije ..................................................................................................................................... 14 Empirijske studije evolucije ............................................................................................................... 14 Studije zakona o evoluciji softvera .................................................................................................... 15 Primjene evolucije softvera ................................................................................................................... 17 Trendovi............................................................................................................................................. 17 Istrazivanja o evoluciji softvera ..................................................................................................... 17 Evolucija open source softvera ............................................................................................................. 18 Neocekivana evolucija softvera......................................................................................................... 18 Poboljsanje kvaliteta i ocuvanje softvera .......................................................................................... 18 Podrska na vise jezika ........................................................................................................................ 19 Velike kolicine analize podataka ....................................................................................................... 19 ZAKLJUCAK............................................................................................................................................. 23 LITERATURA ........................................................................................................................................... 25

2

UVOD

Iako je odrzavanje softvera dio klasicnog softverskog inzenjeringa, u ovaj proces su ukljucene i druge naucne discipline. Promjene, su cinjenica zivota, sto je neizbjezno cak i u softverskim sistemima. Softver je postao sveprisutaniji i vitalaniji u nasem informacionom drustvu, koje je u velikoj mjeri zavisilo od softvera i racunara. Softver treba redovno azurirati, kako bi se obezbijedilo cuvanje i odrzavanje njihovih vrijednosti. Zato postoji potreba za razvojem softvera, odnosno njegovom evolucijom, ali i odrzavanjem. U ovom radu objasnjeni su koncepti i vaznosti evolucije, a naglasak je stavljen na Lehmanove perspektive i zakone evolucije softvera. Rad se takodje odnosi i na razlike izmedju odrzavanja evolucije i razvoja softvera. Istice se da zivotni ciklus jednog softvera prolazi kroz nekoliko razlicitih faza. Postoje dvije perspektive promjena softvera:

revolucionarna i evolucionarna.,

revolucionarne promjene su fundamentalne i transformativne, sto rezultuje kompletnim remontom, obnavljanjem i rekonstrukcijom, a ponekad nepovratnim mehanizmom. Sa druge strane, obicno, evoluciona promjena dolazi postepeno, sto se odvija korak po korak.

3

ODRZAVANJE SISTEMA I SOFTVERSKO INZENJERSTVO Organizacije mogu biti podvrgnute evoluciji zbog eksternih pritisaka i to cine radi efikasnih potreba zainteresovanih strana, dok je evolucija proizvoda vezana sa „keep up(drzanjem koraka)“ sa novijim tehnologijama. Sto se tice promjena, sam softver nije izuzetak, jer je nemoguce proizvesti sisteme bilo koje velicine koji se ne moraju uopste mijenjati. Ova neizbjeznost promjena cini sustinsku karakteristiku razvoja softvera, jer softver mora odgovoriti na sve pritiske, na zivotnu sredinu i dr. zahto jesteeve koji se razvijaju s vremenom itd..

Klasifikacija i strategije mijenjanja sistema i aspekti softverskog inzenjerstva Softver je postao univerzalan vitalan. Obicno se softver razvrstavaju u dvije frupe: a to su: sistemski i aplikativni softver. A postoji jos jedan sistem klasifikacije. Poznata je kao sema klasifikacije (SPE) programa koju navode autori Beladi i Lehman. S predstavlja specificni, a P predstavlja rjesenje problema ili tzv. prakticni tip i E predstavlja ugradjeni softver. Ovde se programi (S-tipa) odnose na one koji se mogu formalno navesti u setu specifikacija i cije je rjesenje jednako dobroshvaceno i prihvaceno. Ucesnici ovih sistema razumiju problem i time znaju sta je potrebno za rjesavanje problema. (P-tipovi) su oni koji se ne mogu specificirati a samo rjesenje nije odmah poznato, tako da se koriste ireverzivni proces kako bi se pronasli rjesenje. Sve zainteresovane strane ove vrste znaju potreban krajnji rezultat, ali nemaju nacina opisivanja kako ga dobiti. Programi tipa E su samo za sisteme koji se aktivno koriste i ugradjuju u stvarni svjetski domen. Softver E-tipa predstavlja realan svijet u kome je kriterijum prihvatljivosti zadovoljstvena potreba zainteresovanih strana. Sistemi tipa E imaju svojstvenu imovinu zbog koje se moraju stalno mijenjati, ako zele ostati zadovoljavajuci u svijetu koji se takodje stalno mijenja. Postoje sljedece tri strategije, koje posmatramo sa aspekta evolucije i odrzavanja softvera, a koje se medjusobno dopunjuju: 4

 Odrzavanje softvera - promjene se vrse zato da bi se drzao korak sa zahto jesteevima, mijenja se funkcionalnost, ali sama struktura softvera uglavnom ostaje ista;  Arhitekturna transformacija - Na sistemu se iz centralizovane mainframe arhitekture prebacuje u distribuiranu arhitekturu sa klijentima , funkcionalnost se moze a i ne mora promijeniti;  Softversko re-inzenjerstvo - Ne dodaje se nikakva nova funkcionalnost, nema velike promjene u arhitekturi, a sistem se transformise u oblik koji se lakse moze razumijeti i dokumentovati, te obradjivati sa raspolozivim alatima. Odrzavanje softvera je dugotrajni rutinski proces koji se svodi na niz uzastopnih promjena. Kao rezultat odrzavanja nastaje velik broj razlicitih verzija softvera, od kojih svaka predstavlja nesto drugaciju konfiguraciju sastavnih dijelova. Cijeli proces treba pazljivo planirati i kontrolisati. Takodje je neophodno imati tacnu evidenciju svih verzija i njihovih konfiguracija. Arhitekturna transformacija i softversko re-inzenjerstvo su jednokratni i radikalni zahvati kojima se kada odrzavanje vise ne daje rezultata ili postane preskupo. Ti zahvati se obicno primjenjuju na stari legacy softver, a zbog toga da bi se takav softver unapredio te ucinio pogodnijim za dalje koristenje. Nakon arhitekturne transformacije ili re-inzenjerstva, transformisani softver se daje na odrzavanje.

Evolucija softvera

Krajem 60-ih godina prvi put je identifikovan fenomen evolucije softvera.ALi, u to vrijeme izraz evolucija nije koristena, pa je u upotrebu dosao tek 70-tih godina. Proces kojim se program modifikuje i prilagodjava u promjenljivom okruzenju naziva se „evolucija softvera“. Sama evolucija softvera ima za cilj implementiranje mogucih velikih promjena u sistemu i osiguranje njegove fleksibilnosti i pouzdanosti. Razvoj softvera je dobio malo paznje i kolicina informacija koje su dostupne istrazivacima su ogranicene. Cak je i profesor Meir Lehman izvrsio empirijsku studiju evolucije softvera u IBM-u sa idejom da poboljsa efikasnost kompanije.

5

Lehman je ukazao na niz zapazanja tokom svoje studije o tome kako se softver razvija tokom vremena i to je dovelo do formulacije zakona o evoluciji softvera. Ali, ovi zakoni su prvobitno bili zasnovani na zapazanjima koja se ticu softvera kao sto su IBM-ovi OS / 360 i OS / 370 evolucije.

Vaznost evolucije softvera Uspjesna evolucija softvera postaje sve kriticnija s obzirom na sve vecu zavisnost racunara i softvera na svim nivoima drustva. Zbog toga je redovno azuriranje softvera, zajedno sa njegovom modernizacijom, jos vaznije kada nekoliko organizacija znacajno investira u svoje softverske sisteme, jer smatraju da su oni kljucni resursi za svoj biznis. Oni obezbjedjuju ocuvanje i odrzavanje vrijednosti ovih poslovnih sredstava. Za sve kompanije koje proizvode i koriste softver, postoji velika potreba za razvojem softvera. Odrzavanje softvera i evolucija softvera su povezani i ponekad se koriste medjusobno. Medjutim, oni nisu isti. Dok se odrzavanje softvera fokusira na fiksiranje virusa i donosenje manjih poboljsanja, evolucija softvera naglasava modifikaciju i „presjeljenje“. U procesu evolucije softvera programi transformisu svoje oblike i prilagodjavaju se situacijama na trzistu. Dok se odrzavanje bavi ocuvanjem i rjesavanjem problema, evolucija centrira sta se s vremenom desava sa sistemom i nove modele koji se razvijaju od starih. Odrzavanje se moze opisati u smislu konstitutivnih aktivnosti kao sto su perfektne, adaptivne, korektivne i preventivne. Evolucija softvera se smatra jednim od teskih i izazovnih oblasti u oblasti softverskog inzenjeringa koji ima oko 60-80% troskova zivotnog ciklusa posvecenog njemu. Ona igra vaznu ulogu u upravljanju sistemom. Ova vrsta evolucije je sada siroko prepoznata kao tema koja zasluzuje ozbiljne studije. Obrazovanje softvera treba da ukljuci razvoj softvera. Fenomen evolucije softvera je tema koja je neophodna za istragu. Posto su istrazivanja u evoluciji softvera veoma mlada, ona podrazumijevaju kontinuirane promjene u svom fokusu i osnovnim konceptima. Ciljevi studije su naglasiti neizbjeznost evolucije softvera, diferenciranje od odrzavanja softvera, uvazavanje njegove centralnosti u softverskom inzenjeringu i podsticanje vise istrazivanja u ovom vaznom polju.

6

Pregled razvoja, odrzavanja i evolucije softvera

U toku zivotnog ciklusa softver, prolazi kroz nekoliko faza:  evolucija,  faza izlaska  servisiranje,  inicijalno razvijanje

Razvoj softvera

Razvoj softvera je proces razvoja softvera koji ukljucuje koncept zeljenog softvera do finalnog izdanja softvera. Od nekoliko ciljeva za razvoj softvera, tri najcesca su:  zadovoljavanje sagledanih potreba potencijalnih korisnika  licna upotreba.  zadovoljavanje specificnih potreba specificnog biznisa ili klijenta, U razvoju softvera moze da se usvojiti inzenjerski pristup ili inkrementalni.A bez obzira na pristup, faze u razvoju softvera su prakticno iste, iako redoslijed u kojem se oni odvijaju moze varirati.

Proces razvoja softvera

U ovom procesu se kreiraju ili mijenjaju informacioni sistemi, metodologije i modeli koje se koriste za razvoj ovih sistema. Dok se razvija softver, on ce proci kroz takve aktivnosti kao sto su planiranje, testiranje, dokumentacija ,implementacija,, rasporedjivanje i odrzavanje.

7

Modeli za evoluaciju i razvijanje sistema

Neki od uobicajenih modela ukljucuju: izgradnju i popravku, brzo prototipovanje, inkrementalni, model vodopada , spirala, i iterativni razvoj. Model za izgradnju i popravku - Ovaj model koji najbolje funkcionise u polumonopolistickom ili monopolistickom okruzenju uzimajuci u obzir raniji i jednostavniji razvoj proizvoda hardvijera.. Model vodopada - Ovde je niz faza u kojima izlaz svake faze postaje ulaz za sljedecu fazu. Predstavljen je od strane Vin Roicea sedamdesetih godina proslog vijeka i svoje ime dobija iz cinjenice da se moze predstaviti u kaskadi od definisanja zahto jesteeva, dizajniranja i kreiranja, implementacije programa, do testiranja sistema i pustanja na raspolaganje kupcima. Model prvobitnog vodopada nije imao povratne informacije; povratne informacije su uvedene u kasnijim verzijama. Zbog problema slozenosti, ovaj model je bio nezadovoljavajuci za softverske proizvode, jer je prakticno nemoguce savrseno adresirati svaku fazu prije nego sto predjemo na sljedecu. Spiralni model - Ovaj model se moze izvuci u spiralni oblik i vizualizuje se kao proces koji prolazi kroz cetiri faze u iteracijama. Faze su: planiranje, analiza rizika, inzenjering i evaluacija, a ovaj model se posmatra kao poboljsanje modela vodopada. Ne zavisi od sposobnosti da precizno procjeni rizike tokom razvoja. Ovde se povratne informacije dodaju ranijim fazama bas kao i druga poboljsanja modela vodopada. Dobro je za velike i kriticne projekte i moze biti skup model i stoga neprikladan za manje projekte. Model brzog prototipovanja - Aktivnost proizvodnje prototipova softverskih aplikacija poznata je kao prototip softvera. Postoje dvije glavne vrste prototipova: prototipovanje i evoluciona prototipizacija. Prototipovanje na bazi lopatica, takodje poznato kao brza prototipizacija, je stvaranje modela koji ce se eventualno odbaciti umjesto da postane dio finalnog isporucenog softvera. U brzoj izradi prototipa, radni model razlicitih dijelova sistema stvoren je u ranoj fazi nakon relativno kratke istrage. Medju prednostima brzog prototipovanja jeste sto dizajner i implementator mogu dobiti korisne povratne informacije od korisnika pocetkom projekta. Zbog toga je vrlo vazan faktor brzina, kojom se model obezbjedjuje. Jednostavno receno, glavni razlog za koristenje Rapid prototipa je sto se to moze uciniti brzo.

8

Brzina i iteracija ukljucena u proces stvaraju povratne informacije veoma rano i dovode do poboljsanja u finalnom dizajnu. Inkrementalni model - Ovde, postoji nekoliko razvojnih ciklusa sa svakim ciklusom podijeljenim na manje lako upravljive module. Svaka gradnja ide kroz faze zahto jesteeva, dizajna, implementacije i testiranja. Stoga, svako naknadno izdanje modula dodaje funkciju prethodnom izdanju i proces se nastavlja sve dok se ne postigne kompletan sistem. Obicno je unaprijedjena prva izgradnja ili radna verzija i dodaje se funkcionalnost sve dok ne postane druga izgradnja; treca gradnja se generise od druge gradje i tako dalje. Prednost ovog modela je ta sto je dovoljno fleksibilna da odgovori na kriticne i specificne promjene dok razvoj napreduje. Model iterativnog razvoja – Ovaj model odrzava kontinuiranu povratnu informaciju izmedju svake faze i njene prethodne a ponekad postoji povratna informacija u nekoliko faza. To se razlikuje od izgradnje i popravke i originalnog vodopada koji funkcionise na otvorenom krugu.

Odrzavanje sistema

Radovi na odrzavanju se odnose na bilo koji rad koji se radi na promjeni softvera koji je u funkciji. To je siroka aktivnost koja ukljucuje sljedece;  ispravke gresaka,  brisanje zastarjelih mogucnosti  poboljsanja mogucnosti,  optimizacija. Sustina modifikacije softvera nakon isporuke je samo ispravljanje gresaka i poboljsvanje performansi ili drugih atributa. Postoje tri vrste softvera za odrzavanje: odrzavanje za popravku softvera ,odrzavanje za popravku gresaka u softveru u drugom radnom okruzenju i odrzavanje radi dodavanja ili izmjene funkcije sistema.

9

Ideja je da treba postojati novi sistem koji je bi se bolje prilagodio njegovom okruzenju. Na primjer:., krajem dvadesetog vijeka doslo je do brzog rasta odrzavanja softvera zbog dva masivna azuriranja softvera:  skup promjena koje su potrebne za podrsku novoj jedinstvenoj evropskoj valuti; Evro (€), blizu 10% ukupne kolicine svjetskog softvera potrebno je azurirati u cilju podrske evru(€);  Problem 2000godina. Prouzrokovan je upotrebom samo dvije cifre za cuvanje kalendarskih datuma, na na primjer:., 1997. godina je sacuvana kao 97, a upotreba 00 za 2000. godinu krsila bi normalna pravila sortiranja, efekat je bio neuspjeh mnogih softverskih aplikacija, a u nekim slucajevima i pogresnih rezultata, na globalnom nivou, a oko 75% instaliranih softverskih aplikacija bilo je negativno pogodjeno problemom I2K. Dvostruki uticaj evra konverzijskog rada i popravke I2K rezulovani su angazovanjem vise od 65% populacije profesionalnih softverskih inzenjera u raznim aktivnostima odrzavanja u toku perioda 1999 i 2000. godine.

Upravljanje konfiguracijom

Veci softverski sistem moze se posmatrati kao konfiguracija svojih sastavnih dijelova. Za vrijeme svog zivota, sistem se mijenja. Stvaraju se razlicite verzije, od kojih svaka predstavlja drugu konfiguraciju dijelova. Upravljanje konfiguracijom je organizovan proces koji kontrolise mijenjanje softvera i evidentira njihove razlicite verzije. Proces ukljucuje sljedece aktivnosti:  upravljanje promjenama sistema;  izrada plana upravljanja konfiguracijom;  izgradnja sistema  upravljanje verzijama sistema;

10

Izrada plana upravljanja konfiguracijom

Plan upravljanja konfiguracijom opisuje standarde i postupke koji se trebaju koristiti za upravljanje konfiguracijom. A rijec je o dokumentu koji sadrzi sljedeca poglavlja.  Popis entiteta koji ce biti obuhvaceni upravljanjem. Sema za identifikaciju tih entiteta.  Opis postupaka koji ce se koristiti za upravljanje promjenama i upravljanje verzijama.  Opis baze podataka za pohranjivanje informacija o konfiguracijama.  Opis dokumenata koji ce se generirati i pohranjivati u toku upravljanja.  Odluka o tome ko je odgovoran za pojedine procese unutar upravljanja.  Opis alata koji ce se koristiti za upravljanje. Sema za identifikaciju entiteta daje unikatno ime svakom modulu, dokumentu, itd. koji je obuhvacen upravljanjem konfiguracijom. Obicno se koriste hijerarhijske seme. A problem sa ovakvom semom je da isti entitet dobija sasvim drugo ime ako se iskoristi u sistemu. Takodje, otezano je pretrazivanje po kriterijumima koji su drugaciji od onih primijenjenih za klasifikaciju. Baza podataka pohranjuje informacije o konfiguracijama koje su potrebne da bi se odredile konfiguracije pojedinih vezija softvera, te takodje i druge relevantne informacije. Baza mora biti u stanju dati odgovore na primjer:. na sljedeca pitanja:  Od kojih verzija kojih dijelova se sastoji zadana vezija sistema?  Koji kupci su instalirali zadanu verziju sistema?  Koliko verzija sistema postoji i koji su datumi njihovog nastanka?  Koji su nerijeseni zahto jesteevi za promjenom zadane verzije sistema?  Koji hardvijer, biblioteke i operacijski sistem su potrebni za pokretanje zadane verzije sistema?  Koje su greske prijavljene za odredjenu verziju sistema?

11

Baza sluzi kao podrska za upravljanje promjenama, gradnju sistema i upravljanje verzijama,.

Upravljanje promjenama sistema

Upravljanje promjenama treba osigurati kako bi se se proces mijenjanja/odrzavanja softvera drzao pod kontrolom i da se promjene odvijaju na racionalan nacin, takodje da se sve promjene evidentiraju/dokumentuju. Zahto jesteev za promjenom se upisuje

u propisani obrazac. Analizu posljedica

promjene obavlja imenovani analiticar. Odluku o tome koje promjene ce da se usvoje ili ukljuce u novu verziju sistema donose „change control board”. Implementiranje skupa odobrenih promjena te ponovno testiranje sistema obavlja odredjeni programerski tim za odrzavanje. A za svaki modul ili funkciju evidentira se promjena. Obicno preko uvodnog komentara.

Slika 1. Proces mijenjanja (odrzavanja) softvera

12

Upravljanje verzijama sistema

Upravljanje verzijama omogucava identifikaciju i evidentiranje raznih verzija i izdanja istog sistema. Verzija je primjerak sistema koji se po necemu razlikuje od drugih primjera. Izdanje je verzija koja se isporucuje kupcima. Osim samih izvrsivih programa, izdanje takodje sadrzi datoteke s podacima, konfiguracijske datoteke, elektronski ,program za instalaciju, ili papirnati prirucnik za korisnike, itd. Izdanje se distribuira na odredjenim medijima (DVD,CD, download s Interneta). Uobicajeni nacin identifikacije je pomocu brojeva, na primjer:: verzija 1.0, 1.1, 1.2, 2:0,... Druga mogucnost je pomocu atributa, na primjer: program AC3D (jezik=Java, platforma=WinXP, datum=Decembar2003). Brojcani nacin identifikovanja je cesci, ali on u sebi krije probleme, jer implicira na linearni redosljed stvaranja verzija. Pravi redoslijed moze biti komplikovaniji. Atributni nacin identifikacije je laksi za pretragu i on se obicno implementuje „iznad” brojcane identifikacije, to jeste. baza podataka o konfiguracijama cuva veze izmedu atributa koji opisuju verzije i brojeva odgovarajucih verzija sistema.

Nakon identifikacije, upravljanje verzijama treba osigurati da se razlicite verzije sistema mogu reprodukovati kada je to potrebno, te da se te verzije nece nepaznjom promijeniti. To ne da znaci da svaka verzija mora biti eksplicitno pohranjena, vec na primjer:. da postoji postupak kojim se izvorni kod trazene verzije moze proizvesti iz neke pohranjene verzije. Upravljanje verzijama takodje ukljucuje donosenje odluka o tome koju od verzija treba pretvoriti u izdanje. A rijec je o osjetljivoj poslovnoj odluci. Jer, ako su izdanja precesta, korisnici ih nece prihvatiti jer ce im instalacija iziskuje troskove.A ako su izdanja prerijetka, korisnici bi mogli odustati od softvera i prijeci na alternativna rjesenja.

13

Izgradnja sistema

Stvari na koje treba obratiti paznju kod izgradnje su sljedece.  Da li su u instrukcije za izgradnju ukljucene svi potrebni dijelovi softvera (moduli, biblioteke, headeri, , . . . )?  Da li su dostupne sve potrebne datoteke sa podacima?  Da li instrukcije za izgradnju ukljucuju pravu verziju softvera?  Da li je dostupna prava verzija compilera i ostalih alata?  Ukoliko modul referencira datoteku, da li je upotrebljeno ime datoteke ?

Zakoni evolucije

Zakon evolucije se odnosi na nekoliko zapazanja o tome kako se softver razvijao s vremenom, koje je Lehman identifikovao u toku studiranja evolucije softverskih sistema. Zakoni nisu predstavljeni kao zakoni prirode. Predstavljena su opsta opazanja koja se ocekuju za sve sisteme tipa E bez obzira na specificnu praksu upravljanja ili programiranja. Ovi zakoni se primjenjuju uglavnom na vlasnicki softver. Naravno, zakoni se primjenjuju u velikim i prilagodjenim sistemima koji razvijaju velike organizacije. Zapravo, zakoni predstavlja novu teoriju softverskog procesa i evoluciju softvera zasnovanu na mnogim ulazima koji se ukljucuju razvoj softvera.

Empirijske studije evolucije

Da bi se razumilo stanje tehnike u razvoju teorije evolucije softvera, i kako se to moze produziti. Neophodno je opisati i identifikovati koje su empirijske studije evolucije softvera prijavljene.

14

Studije zakona o evoluciji softvera

Najistaknutije su studije evolucije softvera koje je rezirao Lehman i saradnici u periodu od 30 godina koji se dogadjala sredinom 1970-ih. Ovi zakoni pokusavaju da dosljedno vode racuna o posmatranju fenomena, koji je u vezi sa razvojem izdanja softvera, sistema i aplikacija E-Tipe, kao sto su definisali Lehman i saradnici. . Studije su dovele do osam zakona o evoluciji softvera, koje su formulisali i poboljsali Lehman i kolege. Ovi zakoni su rezultat pazljivih i izazovnih empirijskih istrazivanja evolucije velikih softverskih sistema koji se nalaze u razlicitim korporativnim postavkama. Zakoni i teorija se mogu preformulisati na nacin koji odgovara nezavisnom testiranju i potvrdjivanju ili odbijanju, ali to zahto jesteeva izradu pretpostavki o detaljima koji nisu eksplicitno navedeni u samim zakonima. Tako da ima mnogo izazova kako bi se takvo empirijsko testiranje ovih zakona trebalo obaviti (na primjer: koliko ili kakve vrste softverskih sistema predstavlja adekvatan ili teoretski motivisan sample prostora za uporednu studiju), koje mogu biti posljedice za i da li i kako bi se zakoni i teorija mogli rafinisati i poboljsati, ako se pojave novi ili kontradiktorni fenomeni. Takodje je utvrdjeno da studije daju dosljedne modele rasta, ali da njihovi rezultati nisu siroko dostupni. Podaci su rezimirani kao skup krivulja rasta. U skiciranju ovih krivulja rasta kao grafikona, (Ks-osa) oznacava sekvencni broj releja softvera koji je analiziran, dok (I-os) oznacava velicinu sistema (na primjer: mjereno brojem modula) nakon prvog izdanja. Prema tome, ovi podaci ili krive objasnjavaju uskladjenost sa prvom (kontinuiranom promjenom), drugom (povecanjem slozenosti) i sestim zakonima (kontinuiranog rasta), zato sto predlazu kontinuiranu adaptaciju putem inkrementalnog rasta, slozenost samog sistema kontrolise stopu rasta u konstantnom ili ogranicenom (invertni ili linearni ) nacin. Kombinovani obrasci se mogu tumaciti kao krive „S“, sa fazama porasta velicine pracene manjim brzim rastom (cak i stagnacijom) i prelazima u drugu fazu rasta. Treci, cetvrti i peti zakoni su rafinisani kako bi objasnili sva nova zapazanja. Sedmi zakon o kvalitetu se ne moze se direktno posmatrati unutar podataka, ali moze biti uskladjen sa zapazanjima Lehmana i saradnika na ovim sistemima. Osmi zakon (povratni sistem) je sinteza drugih zakona. U najnovijim studijama Lehmana i saradnika, njihov skup podataka i raznolikost podataka potkrepljuju i podrzavaju originalne ili prefinjene verzije zakona.

15

ALi, nejasno je da li je takav skup podataka reprezentativan uzorak razlicitih vrsta ili tipova softverskih sistema i da li se zakoni mogu tumaciti kao pruzanje teorijskih uputstava za koje tipove softvera za studiranje iili vrste. Vecina sistema su srednjih ili velikih ili veoma velikih softverskih sistema razvijenih i odrzavanih u velikim korporativnim postavkama, tako da ce kupci ovakvih sistema vjerovatno biti i velika preduzeca (to jeste. nisu namijenjena kao softver za licni racunar). Pored toga, neki od softverskih sistema ili povezanih podataka koji su ispitivani u studijama Lehmana su povjerljivi i naravno nisu otvoreni za javni pregled ili nezavisni pregled i procjenu. Studenti i drugi naucnici ne mogu da lako pristupiti ovim sistemima ili podacima za dalju studiju.

Druge empirijske studije o evoluciji softvera

Mnoge druge empirijske studije su objavljene i sprovedene, a u vezi sa evolucijom softvera. Ovdee se paznja usmerava na uzorak ovih studija gdje su istrazivani sistemi sa otvorenim izvornim(souce) softverom. Naravno ovo je uglavnom namijenjeno da se vidi da li su druge studije o evoluciji softvera u skladu ili da li ponizavaju ili na drugi nacin prosiruju i usavrsavaju zakone i teorije evolucije softvera. Scacchi i Bendifallah predstavljaju kvalitativne podatke i analizu dvije komparativne studije slucaja, otkrivajuci da postoje slicne vrste softverskih sistema u slicnim vrstama organizacionih podesavanja i da

imaju razlicite

evolucione putanje. Oni izvjestavaju da se razlike mogu objasniti nacinom kako odrzavaci sistema i krajnji korisnici rade sa lokalnim nepredvidjenim situacijama i na njihovom radnom mjestu i mogucnostima za karijeru u toku odrzavanja svojih softverskih sistema. Tamai i Torimitsu prezentuju zapazanja i podatke iz studije ankete o aplikacijama softverskog sistema svih glavnih racunara u generacijama proizvoda. Izmedju ostalog, oni izvestavaju da je zivotni vijek softvera u prosjeku oko 10 godina, varijansa u zivotu aplikacije je 6,2 i da male softverske aplikacije imaju u prosjeku kracu zivotnu sredinu. Oni govore da neke kompanije prate politike koje postavljaju predvidjeni vijek trajanja aplikacijskog sistema u trenucima prvog pustanja u rad i koriste te informacije u planiranju migracije na sisteme novih generacija.

16

Primjene evolucije softvera

Prema trecem internacionalu Evropski istrazivacki konzorcijum za informatiku i matematiku (ERCIM), Simpozijum o evoluciji softvera je odrzan 5-og oktobra 2007. godine u Parizu. Softverska evolucija se primjenjuje u sledecim oblastima: sistemi u realnom vremenu, ugradjeni sistemi, softverske arhitekture, Web servere i mobilne i ambijentalne racunare.

Trendovi

Kada je Lehman napravio svoja zapazanja o evoluciji softvera, na pocetku nije obratio paznju na trendove. Ali sada, evolucija softvera je postepeeno dobila paznju u oblasti otvorenog softvera ,istrazivanja i neocekivane evolucije softvera.

Istrazivanja o evoluciji softvera

Cjelokupna ideja istrazivanja evolucije softvera je koristenje istorije softverskog sistema za analizu sadasnjih stanja i za predvidjanje njegovog buduceg razvoja. Da bi istrazivanje evolucije bilo smisleno, potrebno je postojanje tacnih podataka u vezi s proucavanjem sistema.

17

Evolucija open source softvera

Evolucija softvera dovela je do evolucije open source softvera, sto je rezultiralo otkrivanjem novih ideja koje ce dovesti do evolucije i poboljsanja sistema. Softver otvorenog koda(open source) je vrsta softvera u kojoj korisnici dobijaju licence koji ce im dozvoliti da koriste, modifikuju i redistribuiraju izvorni kod. Uz licencu korisnik moze da odluci da li zeli da pregleda softver ili da mu doda neke funkcije ili popravi gresku ili cak unaprijedi kao novu verziju. Primjeri open source softvera su Linux koji je UNIKS-like operativni sistem i Apache open source program koji je dizajniran za Web servere. Razvoj softvera otvorenog koda je razlicit od prvobitnog ili zatvorenog izvornog softvera.

Neocekivana evolucija softvera

Postoji nova tehnologija koja se naziva (USE) Unanticipated Softvare Evolution. Tehnologija (USE) prepoznaje da su neizbjezne promjene u softverskim sistemima.Zato, istrazuje mehanizme na nacin koji odgovara neocekivanim potrebama u softverskim sistemima. Ova tehnologija je veliko sredstvo za inzenjere softvera, jer radi dinamicki,automatski i ima vecu sigurnost uspjeha. A da bi se istrazila tehnologija USE, prva radionica o neocekivanim programima evolucije odrzana je 10-og i 14-tog juna 2002. god. u Malagi, (Spanija) i bila je posvecena boljoj podrsci neadekvatnim infrastrukturama za (runtime).

Poboljsanje kvaliteta i ocuvanje softvera

Kako se softverski sistem mijenja, njegov kvalitet i stabilno polako degradira kao rezultat usporenog pada kvaliteta. Negativni ekonomski i socijalni efekti starenja mogu da se prevazidju obezbjedjivanjem vise tehnika i alata koji ce na kraju osigurati razvoj kvalitetnih karakteristika sistema bez obzira na njegovu velicinu i slozenost.

18

Podrska na vise jezika

Postoji veliko povecanje broja jezika koji se koriste u softverskim sistemima. Da bi se rijesio ovaj kljucni izazov multiprogramskih jezika, obezbedjene su tehnike evolucije softvera koji podrzavaju mnogo jezika.

Velike kolicine analize podataka

Studija razvoja evolucije je izazovna zbog poteskoca u prikupljanju empirijskih podataka. Ovde, za pravilnu manipulaciju svih velikih kolicina podataka, razmatraju se razne nove tehnike i alati kao sto su tehnike rukovanja podacima koje koristi zajednica baza podataka.

Evolucioni obrasci u otvorenom softveru

Razvoj „F/OSS“ se distribuirao

i pojavio sirom svijeta softverske tehnologije,

uglavnom u prosjeku posljednjih desetak godina. Ova infrastruktura podrzava siroki pristup ranijim softverima i informacijama , kao i mogucnost decentralizovanih zajednica slicnih ljudi da pronadju i komuniciraju jedni sa drugima. Ovo se poklapa sa usvajanjem , sirenjem i rutinskom upotrebom Interneta i „World Wide Web“-a kao globalnog tehn. sistema. Ovo je svijet koji se na dosta nacina razlikuje od tradicionalnog pa do softverskog inzenjeringa, gdje je uobicajeno pretpostaviti centralizovane programe razvoja softvera, razvojni rad i administrativne ovlasti koji kontrolisu i upravljaju resursima i rasporedima za razvoj i odrzavanje softvera. Tako da bi se bolje razumjeli da li i kako su obrasci evolucije softvera u drustvenom i tehnickom rezimu (F/OSS) uskladjeni ili se razlikuju od prethodnih modela ili studija evolucije softvera.

19

Tipovi entiteta za proucavanje F/OSS evolucije

Sema tipova objekata koji su odgovarajuci za razmatranje u studijama evolucije softvera identifikovani su u studiju Lehmana. Primarni tipovi entiteta su releji softvera, razvojni procesi, sistemi, aplikacije i procesni modeli. Svako od ovih moze se postaviti u smislu “ F/OSS“ na sledeci nacin: Veliki „F/OSS“ sistemi nastavljaju da rastu tokom vremena i preko izdanja. Ovo ukazuje na dosljednost sa sesti zakon o evoluciji softvera. I stabilne i nestabilne verzije proizvoda za izdavanje „F/OSS“-a se globalno distribuiraju u praksi. Periodicni alfa, beta, gama i stabilna izdanja su dostupni korisnicima po sopstvenom nahodjenju, kao i nestabilne verzije „F/OSS“ verzije koje se izdaju za programere koji aktivno doprinose azuriranju softvera u datom izdanju. Izdanja „F/OSS“ za vise platformi se generalno distribuiraju i sinhronizuju istovremeno, iako se mogu razlikovati paralelno kada se dodaju nove platforme . Oslobadjanja „F/OSS“ se razvijaju unutar netradicionalnog ciklusa procesa izmedju punih stabilnih izdanja. Medjutim vecina „F/OSS“ sistema, prvenstveno onih za srednje i male „F/OSS“ sisteme, ne nastavljaju da rastu ili uspijevaju, jer se softver ne koristi mnogo.

Sistemi „F/OSS“ Sistemi „F/OSS“ mogu biti veoma veliki sistemi (>1MSLOC), veliki (100K-1000K SLOC), srednji (5K-100K SLOC),

mali (<5KSLOC2). Vecina vecih ili velikih „F/OSS“

sistema ili programa moze postojati u razlicitim verzijama, srodnim ali / izdanjima namenjenim razlicitim aplikacijama (na primjer: GNU/Linux, Mac OS Ks MS Windows, Solaris,).Tako da je vecina „F/OSS“-a strukturirana kao distributni sistem, sistemi konfigurisani koristeci skripte (na primjer:. Perl, Tcl, Pithon,), middlevare ili kao modul koji ukljucuje servere /hostove (na primjer:. Mozilla,Apache i Firefox sada nezavisno podrzavaju razvijeni plug-in modul). Pored toga takodje neki „F/OSS“ su dinamicki povezani sistemi konfigurisani u toku rada, kada se razvijaju u programskom jeziku kao sto je Java ili dr. koji omogucavaju daljinsku uslugu ili metodu.

20

Slika 2. Primjer softvera za odrzavanje sistema

Do sada su detaljno obuhvacene , Debian Linux i Linux Kernel distribucije, Mono, Apache Web pretrazivac, Berkelei Web server, Mozilla DB, desktop, desktop korisnicko okruzenje GNOME, PostgreSKL DBMS i oko desetak drugih. A pojavile su se studije populacije primjene „F/OSS“, taksonomije i demografije populacije za stotine i vise od 40hiljada „F/OSS“ sistema. Proces „F/OSS“ – Medjutim, nejasno je da li su procesi „F/OSS“, kako su prikazani u popularnoj literaturi, samo namijenjeni monolitnom procesu, da li je specificno softversko inzenjerstvo aktivnosti imaju razlicitih procesa koji se takodje mogu razvijati, bili oni nezavisni ili zajednicki. Stovise, mali broj nedavnih studija je poceo da posmatra, opisuje i uporedjuje „F/OSS“ razvojne procese sa tradicionalnim na softverski inzenjering . „F/OSS“ proces – Osim toga, aktivnosti „F/OSS“ koje se oslanjaju na izdavanje softvera, mogu da imaju svoj poseban proces kojim mozda ne odrazavaju aktivnosti ukljucene u pustanje sistema zatvorenih izvora(close source).

21

Modeli procesa „F/OSS“ - Postojeci modeli procesa razvoja softvera ne prikazuju eksplicitno „F/OSS“ razvojne aktivnosti ili radne prakse. Sve u svemu,razvojni softverski sistemi mogu biti upakovani i pusteni u oblike otvorenog ili zatvorenog tipa izvora(source-a). Proces pakovanja i oslobadjanja infrastruktura tehnickog sistema moze da se ponekad razlikuje ili biti ista, u zavisnosti od aplikacija softverskog sistema i hosta razvoja (na primjer: Web lokacija za otvoreni kod(open source) korporativnog portala za zatvoreni izvor(close source)). Ipak, cini se da se zakoni evolucije softvera primjenjuju na visokom nivou u obracunu evolucije „F/OSS“-a.

22

ZAKLJUCAK Karakteristika softverskog sistema, koja je vezana za lako prilagodjavanje promjenama tokom vremena, naziva se evolucija softvera. Zakoni evolucije softvera koji su predlozili Lehman i njegove kolege su sada glavni akteri u oblasti softverskog inzenjerstva i racunarstva. U evoluciji softvera, naglasak je na ocuvanju i poboljsanju kvaliteta softvera i smanjenju slozenosti. Vecu paznju treba posvetiti oblastima kao sto su evolucija softvera otvorenog koda i neadekvatna evolucija softvera.Postoji potreba da se poveca svijest o vaznosti evolucije softvera, posto je istrazivanje evolucije jos uvijek mlado polje. Zakoni i teorije evolucije softvera koje su predlozili Lehman i saradnici priznaju se kao veliki doprinos u oblasti softverskog inzenjerstva i discipline racunarskih nauka. Ovi zakoni su uopsteno ustanovljeni da pruzaju vjerodostojno objasnjenje o tome kako se softverski sistemi razvijaju tokom cijelog zivota. Empirijski su istrazeni tokom perioda od vise od 30 godina, pa je njihova upornost zapazena dostignuca. Medjutim, moze se pokazati kao pokusaj koji dovodi do novih nacina i sredstava za konceptualizaciju evolucionih procesa u drugim domenima studiranja. Razvijanje zakona i teorije evolucije softvera oslanjajuci se na empirijski utemeljene studije je dugorocni poduhvat koji podstice mnoge izazove u istrazivackom metodu, teorijski uzorkovanje sistema za proucavanje, teorijsku konstrukciju i tekuce teorijsko testiranje, opovrgavanje i prefinjenost. Kako se proces,tehnologijai praksa razvoja i odrzavanja softvera razvijala, pogotovo u proteklih desetak godina i sa pojavom velikog broja projekata za razvoj slobodnog ili otvorenog softvera. Modeli i prethodne studije se ne adresiraju i zbog toga ne pruzaju duboku ili bogatu karakterizaciju evolucije „F/OSS“ sistema. Prethodni modeli evolucije softvera su formulisani tako da procesa razvoja i odrzavanja softvera i radnih praksi koji su bili bazirani u centralizovanim, korporacijskim centrima za razvoj softvera koji su izgradili velike zatvorene sistemske (close source) aplikacije sa konkurentnim ponudama za koriscenje od strane velikih kompanija. Postoje sve vece baza podataka, dokaza i nalaza iz visestrukih studija „F/OSS“ sistema koji nam ukazuju na „F/OSS“ sisteme koji se razvijaju zajedno sa njihovim korisnickim zajednicama, tako da se sam rast i evolucija svake zavise od drugih. Ukratko, raniji modeli evolucije softvera su bili razvijeni i primijenjeni na sistemima koji se odrzavaju i koriste u tehnoloskom rezimu i korporativnom svijetu koji se razlikuje od drustveno-tehnickih zajednica,

23

globalne informacione infrastrukture i tehnoloskog rezima koji ugradjuje softver otvorenog koda (open source).

24

LITERATURA

1. http://www.gts.rs/usluge/odrzavanje 2. https://www.servisracunaranovisad.info/odrzavanje-sistema/ 3. http://www.prologic.rs/index.php/odrzavanje-sistema 4. https://arxiv.org/ftp/arxiv/papers/1405/1405.7135.pdf 5. https://hr.wikipedia.org/wiki/Odr%C5%BEavanje_uz_pomo%C4%87_ra%C4%8Dunalnih_sust ava

6. http://www.ss-strukovna-vvlatkovicazd.skole.hr/images/pages/Nastavni_materijali/Spahic/DIOU/diou-1-uvod.pdf

25