T-6 Evolucija i Odrzavanje Softvera

Evolucija i održavanje softvera

dr Zoran Jeremić[email protected]

1

Sadržaj• Osnovni pojmovi• Vrste održavanja softvera• Cena održavanja softvera• Tehnike održavanja softvera

2

Proces razvoja sistema

Faza Aktivnost Izlaz

Započinjanje Utvrđivanje poslovnih potreba Biznis dokumenta

Analiza Intervjuisanje stejkholdera, istraživanje sistemskog okruženja

Organizovana dokumentacija

Specifikacija Analiza inženjerskih aspekata sistema, definisanje koncepata sistema

Logički model sistema

Implementacija Programiranje, testiranje jedinica, integrisanje, dokumentovanje

Proverljiv sistem

Testiranje & Integracija

Integrisanje svih komponenti, verifikacija, validacija, instalacija, obuka

Resultati testiranja, funkcionalan sistem

Održavanje Popravljanje bagova, modifikacije, adaptacija Verzije sistema

Uvod | Klase | Relacije | Generalizacija | Uputstva 3

Održavanje softvera

• Održavanje softvera je– Proces modifikovanja softverskog sistema ili

komponente nakon isporuke radi otklanjanjagrešaka, poboljšanja performansi ili drugihatributa, ili prilagođavanja promenljivomokruženju.

– Softverski proizvod se podvrgava modifikacijikoda ili dokumentacije usled problema ili potrebeza unapređenjem. Cilj je modifikovanjepostojećeg softverskog proizvoda dok seistovremeno očuvava njegov integritet

Održavanje softvera

• Održavanje programa nakon što je stavljen uupotrebu

• Održavanje obično ne obuhvata značajneizmene na arhitekturi sistema– Izmene se implementiraju modifikovanjem

postojećih komponenti i dodavanjem novihkomponenti sistemu

Evolucija softvera

• Evolucija softvera je– Skup aktivnosti, tehničkih i upravnih, koje obezbeđuju da

softver nastavi da ispunjava organizacione i poslovneciljeve na isplativ način

– Sve programerske aktivnosti čiji je cilj generisanje noveverzije softvera na osnovu starije operacione verzije

– Primena aktivnosti i procesa održavanja softvera kojima segeneriše nova operativna verzija softvera sa novimfunkcionalnostima ili karakteristikama u odnosu naprethodnu operativnu verziju pri čemu su obuhvaćene iaktivnosti obezbeđivanja kvaliteta

Presenter

Presentation Notes

As we examine definitions, we can conclude that software evolution relates to the life of the software after its initial development cycle (or after the first delivery of the software system): - Any subsequent change to the software, such as bug fixes, adding new functionality, even modifying existing functionality, is considered to be software evolution - From the proces perspective, this is a staged model of software life-cycle; we will examine it later in more details

Vrste održavanja softvera

• Prema ISO/IEC 14674 standardu zasoftversko inženjerstvo:– Adaptivno održavanje

• “Modifikacija softverskog proizvoda izvršena nakonisporuke da bi se očuvala upotrebljivost softverskogproizvoda u promenjenom ili promenljivom okruženju."

– Korektivno održavanje• “Ispravljaju se uočene greške. Može se raditi o

greškama u kodiranju, u oblikovanju, odnosno uspecifikaciji."


• Prema ISO/IEC 14674 standardu zasoftversko inženjerstvo:– Perfekcijsko održavanje

• “Modifikacija softverskog proizvoda nakon isporuke radiunapređenja performansi ili dodavanja novihkarakteristika.«

– Preventivno održavanje• “Modifikacija softverskog proizvoda nakon isporuke radi

utvrđivanja i korigovanja latentnih grešaka usoftverskom proizvodu pre nego što one nanesu štetu."


• Prema ISO/IEC 14674 standardu zasoftversko inženjerstvo

Zašto?Kada?

Korekcija Unapređenje

Proaktivno Preventivno Perfektivno

Reaktivno Korektivno Adaptivno

Značaj evolucije

• Najveći deo budžeta za razvoj softvera uvelikim kompanijama je u mnogo većoj merinamenjen adaptaciji (evoluciji) postojećegsoftvera a u manjoj razvoju novog softvera.

Osnovni razlozi za evoluciju softvera• Promene korisničkih zahteva

– Proširenja ili modifikacije koje je zahtevao korisnik• Otklanjanja bagova

– Planirane aktivnosti otklanjanja– Nužno otklanjanje (uglavnom skupo zbog velikog pritiska)

• Promene formata podataka– Y2K, Euro, poreske rate, poštanski kodovi,

telefonski brojevi, ...– Novi standardi: UML, XML, COM,

DCOM, CORBA, ActiveX, WAP• Hardverske promene• Povećanje efikasnosti

Promene formata

podataka (18%)

Otklanjanje bagova (21%)

Hardverske promene (6%)

Povećanje efikasnosti (4%)

Promenjeni korisnički zahtevi

(42%)

Presenter

Presentation Notes

There are numerous causes why the components of a software system tend to evolve: because of the new user requirements for the system (A typical situation: by using the software the user gets new insights in how the system could support his activities, and, as a result, new requirements for the system arise.) because technology itself evolves. It is possible both for hardware and software to go: e.g. by the ontstaan of Internet want a lot companies cost what costs their software and the components from which software is opgeboud internet-aware can lead make e.g. software must be adapted new types terminal equipment to be able support new insights in the field (that both can arise by doing field analysis and by iterative development of components) that components already existing must be adapted to become to be brought with these new insights in agreement. Evolution is inherent to iterative development: components are not developed entirely in one time, but are bit by bit built and are increasingly further refined and are adapted.

Starenje softvera

• Neophodno je da naučimo kako sprečimoefekte starenja– “Programi, kao i ljudi stare. Starenje ne možemo

sprečiti, ali možemo razumeti njegove uzroke,preuzeti korake da ograničimo njegove efekte,privremeno otklonimo neke od šteta koje jeizazvalo i pripremimo se za dan kada softver višeneće biti upotrebljiv.”

Starenje softvera

• Razlozi za starenje softvera– Održavanje– Nefleksibilnost od početka projekta– Nedovoljna ili nekonzistentna dokumentacija– Pritisak krajnjih rokova– Dupliranje funkcionalnosti (dupliranje koda)– Nedostatak modularnosti– ...

• Moguće rešenje: reinženjerstvo

Presenter

Presentation Notes

There its different underlying causes as a result of which software "parent" becomes. A first obvious cause is being lacking aware initiatives software "up to keep date". A second reason is that at the maintenance of software patches and fixes are frequently made which the begrijpbaarheid and maintenance-ingot-driven of software do not help. As a consequence and of other "ignorant interventions" in software which original software architecture more and more helps soap onstaat a so-called erosion of architecture which less and less and less become "clean". If the system moreover of in the beginning already little was adaptable and onderhoudbaar, it is not at all obvious software up to keep date. Lack of sound documentation reinforces the above problems only. How you can know without documentation which things must modify you, how you must modify them, which onderstellingen can make you and which not, etc.... Under deadline pressure one has not been tended think generally of the future software of loving software clean, adaptably and understandable. Etc....

Legacy (zastareli) sistemi - definicija

• Bilo kakvi informacioni sistem koji se opirepromenama

• Postojeći kompjuterski sistem ili aplikacioniprogram koji se nastavlja koristiti jer korisnik(najčešće organizacija) ne želi da ga zameniili redizajnira. Mnogi ljudi koriste ovaj pojamda ukažu na “zastarele” sisteme.

Legacy (zastareli) sistemi - definicija

• Sa tehnološkog aspekta – čak i kompletnofunkcionalan i održiv sistem se može smatratizastarelim ukoliko koristi prevaziđenutehnologiju.

• Sa ekonomskog aspekta – sistem se možesmatrati zastarelim ukoliko ne može da pratitempo promena u poslovnom domenu.

Problemi sa legacy sistemima

• Često se izvršavaju na zastarelom hardveru• Teško se održava, unapređuje i proširuje• Opšti nedostatak razumevanja sistema:

– Nema osoba koje mogu objasniti kakofunkcioniše

– Dokumentacija ili uputstva su se izgubili tokomgodina

• Teška je integracija sa novim sistemima

Presenter

Presentation Notes

Legacy systems often run on obsolete (and usually slow) hardware, and sometimes spare parts for such computers become increasingly difficult to obtain. These systems are often hard to maintain, improve, and expand because there is a general lack of understanding of the system. The designers of the system may have left the organization, leaving no one left to explain how it works. Such a lack of understanding can be exacerbated by inadequate documentation or manuals getting lost over the years. Integration with newer systems may also be difficult because new software may use completely different technologies.

Razlozi za korišćenje legacy sistema (uprkos problemima)

• Troškovi redizajna sistema su preterano visoki jer jesistem veliki, monolitski i/ili kompleksan.

• Sistem zahteva 100% dostupnost, pa ne može bitistavljen van upotrebe.

• Način na koji sistem funkcioniše nije dobro shvaćen.• Korisnik očekuje da sistem može biti jednostavno

zamenjen kada to bude neophodno.• Sistem radi zadovoljavajuće, i vlasnik ne vidi razlog

za njegovu promenu.

Presenter

Presentation Notes

Despite these problems, organizations can have compelling reasons for keeping a legacy system, such as: The costs of redesigning the system are prohibitive because it is large, monolithic, and/or complex. The system requires close to 100% availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. The way the system works is not well understood. Such a situation can occur when the designers of the system have left the organization, and the system has either not been fully documented or such documentation has been lost. The user expects that the system can easily be replaced when this becomes necessary. The system works satisfactorily, and the owner sees no reason for changing it – or in other words, re-learning a new system would have a prohibitive attendant cost in lost time and money.

Legacy sistemi – moguće rešenje

• Reinženjerstvo je sistematična transformacijapostojeće sistema u novu formu da bi se– Realizovala kvalitativna unapređenja u

operativnosti, mogućnostima sistema,funkcionalnosti i performansama,

– ili evoluiralo ka manjim troškovima, uštedivremena ili smanjenju rizika korisnika.

Presenter

Presentation Notes

Other possible solutions include: Maintaining and running the system as it is Disposing the old system and building a new one from the scratch Emulating the old hardware on a new one, or having a software with a backward compatibility Using software wrapping techniques to interface newly developed software components to the core of the legacy system

Dinamika održavanja softvera

• Lehman-ovi zakoni:– Nužnost menjanja – softver koji se zaista koristi u

stvarnom svetu nužno se mora menjati jer uprotivnom ubrzo postaje neupotrebljiv.

– Povećanje složenosti – dok se softver menja, njegovastruktura teži tome da postane sve složenija. Da bi seočuvala jednostavnost strukture, potrebno je uložitidodatni trud i resurse.

– Ograničena brzina unapređivanja – količina “novosti”koju pojedino izdanje softvera može doneti otprilike jekonstantna i karakteristična za taj softver.

20

Presenter

Presentation Notes

Prvi i drugi Lehman-ov zakon dovoljno su razumljivi bez dodatnih komentara. Treći zakon znači da ako u jednom izdanju unesemo previše novosti, unijet ćemo i mnogo novih grešaka, pa će iduće izdanje morati biti posvećeno ispravljanju tih grešaka, a prosječna količina novosti po izdanju vratit će se na normalnu vrijednost. Konstanta iz trećeg zakona odredena je originalnim procesom razvoja softvera i ne može se naknadno popraviti. Znači, ako je proces razvoja bio kvalitetniji, stvorit će se softver koji je pogodniji za održavanje, te će konstanta biti veća, to jest dopuštat će veću brzinu kasnijeg unapredivanja softvera.

Cena održavanja softvera

• Osnovni faktori koji utiču na cenu održavanja:1. Celovitost polazne specifikacije – ukoliko odmah

uključimo sve zahteve, kasnije će biti manjeperfekcijskog održavanja.

2. Kvalitet dizajna – dobar dizajn je jeftiniji zaodržavanje. Smatra se da su sa stanovištaodržavanja najbolji objektno-orjentisani sistemi,koji se sastoje od malih modula sa jakomunutrašnjom kohezijom i labavim vezama premaspolja.

21

Cena održavanja softvera1. Način implementacije – Kod u “strožem”

programskom jeziku poput Jave lakše seodržava nego kod u jeziku poput C-a.Struktirirani kod (if, while) sa smislenoimenovanim varijablama razumljiviji je odkompaktnog koda s mnogo goto naredbi.

2. Stepen verificiranosti – dobro verificirani softverima manje grešaka pa će zahtevati manjekorekcijskog održavanja.

3. Stepen dokumentovanosti – uredna, dobrostruktuirana i celovita dokumentacija olakšavarazumevanje softvera, pa na taj načinpojeftinjuje održavanje.

22

Cena održavanja softvera1. Način upravljanja konfiguracijom – ukoliko se

primenjuju metode, alati i organizacijska pravilaupravljanja konfiguracijom, tada je održavanjena dugi rok jeftinije.

2. Starost softvera – što je softver stariji, to jeskuplji za održavanja, budući da mu se građadegradirala, zavistan je od zastarelih razvojnihalata, a dokumentacija mu je postala neažurna.

3. Svojstva aplikacijskog domena – ako je reš ostabilnom domenu gde se poslovna pravila retkomenjaju, tada će se retko pojavljivati potreba zaperfekcijskim održavanjem u svrhu usklađivanjas novim pravilima.

23

Cena održavanja softvera

1. Stabilnost razvojnog tima – održavanje jejeftinije ako se njime bave originalni razvijačisoftvera, jer oni ne moraju trošiti vreme naupoznavanje sa softverom.

2. Stabilnost platforme – ako smo softverimplementirali na platformi koja će još dugo bitisavremena, tada neće trebati adaptacijskoodržavanje.

24

Tehnike održavanja softvera

• Redokumentovanje• Restruktuiranje• Reverzni inženjering• Reinženjering

Tehnike održavanja softvera

26

Presenter

Presentation Notes

referenciranju koda. Analiza ne čini ništa da bi transformisala aktuelni kod. Ona samo izvodi informacije. Međutim, kada restrukturišemo, stvarno menjamo kod, transformišući loše strukturisani kod u dobro strukturisani. Obe ove tehnike bave se samo izvornim kodom. Da bismo izvršili reverzni inženjering sistema, vraćamo se od izvornog koda ka proizvodima koji su mu prethodili, ponovo stvarajući informacije o konstrukciji i specifikaciji iz koda. Reinženjering je još obuhvatniji jer se obavlja reverzni inženjering postojećeg sistema koji se zatim „projektuje unapred" radi izmena u specifikaciji i konstrukciji koje upotpunjuju logički model. Zatim se stvara novi sistem na osnovu revidirane specifikacije i konstrukcije. Na slici 1 ilustrovani su odnosi između četiri vrste podmlađivanja.

Redokumentovanje

• Obuhvata statičku analizu izvornog koda dabi se proizvela dokumentacija sistema.

• Možemo da ispitamo upotrebu promenljivih,pozive komponenti, putanje upravljanja,veličinu komponenti, pozivajuće parametre,putanje testiranja...

• Informacije koje proizvede statička analizamogu da budu grafičke ili tekstualne.

27

Reverzni inženjering

• Reverzni (obrnuti) inženjering je procesotkrivanja tehnoloških principa uređaja,objekata ili sistema kroz analizu njegovestrukture, funkcije I operacije.

• Često uključuje podršku (npr. mehaničkihuređaja, eletričnih komponenti ili programa)odvojeno i analiziranje njegovog rada udetalje kako bi se koristili u održavanju ilikako bi se pokušao napraviti novi uređaj iliprogram koji obavlja isti zadatak, bezkopiranja bilo čega od originala.

28

Reinženjering

• Softverski reinženjering je aktivnost koja:– Poboljšava razumevanje softvera, ili– Priprema i poboljšava sam softver, obišno za

povećanu sposobnost održavanja, ponovnokorišćenje, ili evoluciju.

29

T-6 Evolucija i Odrzavanje Softvera

Documents

Transcript of T-6 Evolucija i Odrzavanje Softvera