1. Evolucija softvera Uvod
Topic 1. Rationales (for software evolution) and Taxonomies (of maintenance and reenginering activities)
Authors: Dragan Bojic (Belgrade)
Author of the lecture notes: Dragan Bojic (Belgrade)
About the subject of this topic:
This course will consider what software evolution is, why it is inevitable, and how one might reasonably and reliably go about performing it. All essential technical and managerial aspects of software maintenance and evolution will be covered. In this first lesson we shall define the term, examine the reasons why software evolves and problems connected with its inability to change. We shall also give an overview of techniques to reengineer such a software, making it more able to keep pace with changing environment.
Remarks:
To do:
Slides that could be improved and replaced (the list of particular slides that can be improved/replaced):
Duration of the lecture:
History of changes:

2. Sadržaj Definicija održavanja i evolucije softvera
Tipovi održavanja i evolucije
Zašto softver evoluira
Otpornost na promene
Klasifikacija aktivnosti reinženjeringa softvera

3. Održavanje softvera Održavanje softvera je
Proces modifikacije softverskog sistema ili komponente nakon isporuke radi ispravljanja grešaka, poboljšanja performansi ili drugih atrubuta ili prilagodjenja novoj sredini [IEEE Std ]
Softverski proizvod podleže modifikaciji koda i odgovarajuće dokumentacije usled nekog problema ili potrebe za poboljšanjem. Cilj toga je da se modifikuje postojeći softverski proizvod a da se u isto vreme sačuva njegov integritet. [ISO Std 12207]

4. Održavanje softvera
Modifikacija programa nakon što je već stavljen u upotrebu
Održavanje obično ne obuhvata promenu osnovne konstrukcije sistema.
Promene se implementiraju modifikacijom postojećih i dodavanjem novih komponenti u sistem

5. Evolucija softvera Evolucija softvera je
niz aktivnosti, tehničkih i rukovodstvenih, koje obezbeđuju da softver nastavlja da ispunjava organizacione i poslovne ciljeve pritom iskorišćavajući poverena sredstva na najbolji način (Institut za istraživanja na polju evolucije softvera)[Research Inst. On Sw. Evolution]
svaka programerska delatnost koja je namenjena stvaranju nove verzije softvera od neke ranije verzije (Lehman i Ramil 2000)
primena mera(aktivnosti) i procesa održavanja softvera koji stvaraju novu radnu verziju softvera sa promenjenom funkcionalnošću (prema iskustvima korisnika) ili sa svojstvima prethodne radne verzije, zajedno sa odgovarajućim merama i procesima koje osiguravaju kvalitet, i rukovođenjem tim merama i procesima (Ned Chappin 1999)
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

6. Sadržaj Definicija održavanja i evolucije softvera
Tipovi održavanja i evolucije
Zašto softveri evoluiraju
Otpornost na promene
Klasifikacija aktivnosti reinženjeringa softvera

7. Tipovi održavanja softvera
Prema standardu ISO/IEC za softverski inženjering - održavanje softvera
Adaptivno održavanje
“Modifikacija softverskog proizvoda koja se izvodi nakon isporuke, a sa ciljem da se tom softverskom proizvodu sačuva upotrebna vrednost u promenjenoj sredini ili sredini koja se upravo menja."
Korektivno održavanje
"Reaktivna modifikacija softverskog proizvoda koja se vrši nakon isporuke, radi popravke otkrivenih grešaka."

8. Tipovi održavanja softvera
Prema standardu ISO/IEC 14674(…)
Perfektivno održavanje
"Modifikacija softverskog proizvoda nakon isporuke radi unapređenja performansi ili održivosti."(takođe uključuje i dodavanje novih karakteristika)
Preventivno održavanje
"Modifikacija softverskog proizvoda nakon isporuke, sa ciljem da se detektuju i isprave skrivene greške u tom softverskom proizvodu pre nego da postanu delotvorne."

9. Tipovi održavanja softvera
Prema standardu ISO/IEC za softverski inženjering - održavanje softvera
Zašto?
Kada?
Ispravka
Unapređenje
Proaktivna
Preventivna
Perfektivna
Reaktivna
Korektivna
Adaptivna

10. Tipovi održavanja softvera
Klasifikacija zasnovna na objektivnom dokazu [Chapin i drugi 2001]
Klasifikuje evoluciju softvera i mere i procese održavanja unutar
softvera (uključujući dokumentaciju)
koda
funkcionalnosti za korisnika
poredeći softver pre i posle evolucije
12 identifikovanih tipova održavanja softvera.

11. Tipovi održavanja softvera
6. Pospremanje
7. Preventiva
8. Performanse
9. Adaptacija
10. Redukcija
11. Popravka
12. Unapređenje
Obuka
Konsultacija
Vrednovanje
4. Reforma
5. Osavremenjivanje Ne
Da li je funkcija promenjena? Ne Da
Da li je
izvorni kod promenjen? Ne Da
Da li je softver promenjen ? Da

12. Tipovi održavanja softvera
Da li su ove mere izmenile softver ? Ne.
(1. Obuka) Da li su ove aktivnosti upotrebile softver kao predmet obuke korisnika?
(2. Konsultacija) Da li su ove aktivnosti upotrebile softver kao osnovu konsultacija?
(3. Vrednovanje) Da li su ove aktivnosti obuhvatile i vrednovanje softvera?
Da li su ove aktivnosti izmenile kod? Ne.
(4. Reforma) Da li su ove aktivnosti učinile da se nekodska dokumentacija bolje prilagođava korisnicima?
(5. Ažuriranje) Da li su ove aktivnosti učinile da je nekodska dokumentacija bolje prilagođena implementaciji?

13. Tipovi održavanja softvera
Da li su ove aktivnosti promenile stepen funkcionalnosti za korisnika? Ne.
(6. Pospremanje) Da li su ove aktivnosti promenile ergonomske aspekte ili bezbednost?
(7. Preventiva) Da li su ove aktivnosti zaobišle ili smanjile posao održavanja u budućnosti?
(8. Performanse) Da li su ove aktivnosti promenile performanse softvera?
(9. Adaptacija) Jesu li ove aktivnosti promenile tehnologiju ili resurse koji se koriste? …

14. Tipovi održavanja softvera
Ako je odgovor na "C" DA.
(10. Redukcija) Da li su aktivnosti ograničile ili smanjile funkcionalnost za korisnika?
(11. Korekcija) Da li su ove aktivnosti ispravile funkcionalnost za korisnika?
(12. Unapređivanje) Da li su ove aktivnosti zamenile, dodale ili proširile funkcionalnost za korisnika?

15. Sadržaj Definicija održavanja i evolucije softvera
Tipovi održavanja i evolucije
Zašto softver evoluira
Otpornost na promene
Taksonomija delatnosti reinženjeringa softvera

16. Troškovi održavanja/evolucije

17. Glavni razlozi evolucije softvera
Promene u zahtevima korisnika(potrošača)
Modifikacije i proširanja na osnovu zahteva od strane korisnika
Otklanjanje grešaka
Redovne popravke
Vanredne popravke - koje više koštaju usled velikog pritiska
Promene u formatima podataka
Y2K, Euro, poreske stope, poštanski kodovi, telefonski brojevi...
Novi standardi: UML, XML, wsdl, json,...
promene hardvera
Unapređenja efikasnosti
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.

18. Sadržaj Definicija održavanja i evolucije softvera
Tipovi održavanja i evolucije
Zašto softver evoluira
Otpornost na promene
Klasifikacija aktivnosti reinženjeringa softvera
Now let’s see what are the obstacles to software evolution.
Two terms are mentioned in this context: software aging and legacy systems.

19. Starenje softvera
Moramo naučiti kako da poništimo efekte(posledice) starenja.
“Programi, kao i ljudi, stare. Ne možemo da sprečimo zastarevanje, ali možemo razumeti njegove razloge, preduzeti korake da ograničimo njegove posledice, s vremena na vreme poništiti neke od oštećenja koje je prouzrokovalo i pripremiti se za dan kada taj softver neće više biti održiv.” (Parnas, 1994.)

20. Starenje softvera (...) Razlozi starenja softvera
Održavanje
Neuka nadogradnja i razgradnja njegove konstrukcije
nefleksibilnost od samog početka
nedovoljna ili nesaglasna dokumentacija
pritisak rokova
dvostruka funkcionalnost (duplikacija koda)
odsustvo modularnosti
...
Moguće rešenje: reinženjering
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....

21. Nasleđeni sistemi - definicije
Svaki informacioni sistem koji odoleva promenama. [program-transformation.org]
Postojeći računarski sistem ili aplikacioni program koji nastavlja da se koristi i dalje, zbog toga što korisnik (obično neka organizacija) da ga zameni ili ga redizajnira. Mnogi ljudi koriste ovaj izraz da označe "zastarele" sisteme. (wikipedia)

22. Nasleđeni sistemi - definicije
Iz perspektive "novih trendova u tehnologiji" čak i potpuno funkcionalan i dobro održavan sistem se samtra nasleđenim ako je zasnovan na zastareloj tehnologiji. (Pogledi na reizgradnju nasleđenih sistema, SEI CMU 1995)
Iz ekonomske perspektive sistem se smatra nasleđenim ako ne može da prati stopu promena u domenu biznisa. (Alderson, Cacm, 1999)

23. Problemi sa nasleđenim sistemima
Često rade na zastarelom hardveru
Teško ih je održavati, poboljšati i proširiti
Opšte odsustvo razumevanja sistema:
Nema nikoga da objasni kako sistem radi
Dokumentacija i uputstva za upotrebu se s vremenom izgube
Teško ih je integrisati sa mlađim sistemima
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.

24. Razlozi čuvanja nasleđenih sistema
Troškovi redizajniranja sistema su faktor koji ga (redizajniranje) sprečava upravo zato što je ono veliko, monolitno i/ili složeno.
Sistem mora biti dostupan skoro 100%, pa ne može tek tako da se isključi
Ljudi ne razumeju način na koji sistem radi
Korisnik očekuje da se sistem može lako zameniti novim kada to postane neophodno.
Sistem radi zadovoljavajuće, i vlasnik ne vidi razloga da ga menja.
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.

25. Nasleđeni sistemi - Moguće rešenje
Reinženjering jeste sistematsko transformisanje postojećeg sistema u nov oblik radi
a) ustanovljenja poboljšanja u kvalitetu rada, sposobnosti sistema, funkcionalnosti i svojstvima ili
b) mogućnosti sistema da se razvija (evolventnosti) uz manje troškove, manje planiranje ili manji rizik za korisnika.
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

26. Sadržaj Definicija održavanja i evolucije softvera
Tipovi održavanja i evolucije
Zašto softver evoluira
Otpornost na promene
Klasifikacija aktivnosti reinženjeringa softvera

27. Domen reinženjeringa softvera
Normalan razvoj softvera (forward engineering)
Reverzni inženjering
Redokumentacija
Obnova projekta
Razumevanje programa
Restrukturiranje
Reinženjering
Reverzna specifikacija
Rekodiranje (ponovno kodiranje)
Redizajn (otkrivanje projekta)
Respecifikacija (ponovna specifikacija)

28. Normalan razvoj
Uobičajeni softverski proces koji teče od funkcionalne specifikacije i dizajna ka fizičkoj implementaciji sistema

29. Softversko reverzno inženjerstvo
Def. Dvofazni proces
Izvlačenje informacija
Apstrakcija informacija
Def. Trofazni proces [Tilley95]
Prikupljanje informacija
Organizacija znanja
Upravljanje, analiza i prezentacija informacijama
Def. Sistem koji anlizira temu [CC90]
Da bi se identifikovale njegove trenutne komponente i njihova međuzavisnost
da bi se izvukle i stvorile sistemske apstrakcije i informacija za dizajn
Dotični sistem se ne menja: međutim, menja se dodatno znanje o sistemu koji se proizvodi

30. Reverzni inženjering u odnosu na druge delatnosti

31. Razumevanje programa
Razumevanje ili tumačenje programa je izraz koji je u vezi sa reverznim inženjeringom. Razumevanje programa uvek podrazumeva da se počinje sa izvornim kodom dok se reverzni inženjering može zasnivati na binarnoj i izvršnoj formi sistema ili na opisima konceptualnog dizajna. Cela doktrina razumevanja programa obuhvata znanja o ljudskim mentalnim procesima prilikom razumevanja programa (programerska psihologija). Razumevanje programa može se ostvariti na neki adhok način, bez da se napravi spoljni opis.
Dok je reverzni inženjering sistematski pristup razvoju spoljašnjeg opisa sistema, razumevanje programa se može uporediti sa obnovom dizajna zato što oboje polaze od nivoa izvornog koda.

32. Redokumentacija
Redokumentacija je stvaranje ili revizija semantički ekvivalentng prikaza unutar istog nivoa apstrakcije. Prikazuju se obično različiti aspekti sistema (npr. protok podataka, struktura podataka, kontrola protoka) namenjenih ljudima.
Redokumentacija je najjednostavniji i najstariji oblik reverznog inženjeringa i može se smatrati jednom od nenametljivih, mekših oblika restrukturiranja.

33. Restrukturiranje
Transformacija jednog nivoa prikaza u drugi na istom nivou relativne apstrakcije, dok se u isto vreme čuva spoljašnje ponašanje dotičnog sistema (tj. funkcionalnost i semantika)

34. Reinženjering
Reinženjering je ispitivanje i izmena datog sistema radi radi ponovnog konstituisanja u nekom novom obliku i kasnija implementacija tog novog oblika.
Proces reinženjeringa računarskih sistema obuhvata tri glavna koraka: reverzni inženjering, funkcionalno restrukturiranje i progresivni inženjering

35. Reinženjering softvera - model potkovice

36. Kategorije renženjeringa
Automatsko restrukturiranje
Automatska transformacija
Poluautomatska transformacija
Obnova i reimplementacija dizajna
Reverzni i progresivni inženjering koda
Reverzni inženjering podataka i migracija strukturnog opisa baze podataka
Migracija nasleđenih sistema ka modernim platformama

37. Kategorije reinženjeringa...
Automatsko restrukturiranje
Radi dobijanja čitljivijeg koda
Primena standarda u kodiranju
Automatska transformacija
Radi dobijanja boljeg koda
HTML-izacija izvornog koda
Pojednostavljenje kontrolnih naredbi (dead code, goto)
Refaktorisanje i remodularizacija
Popravka Y2K

38. Kategorije reinženjeringa...
Poluautomatska transformacija
Kako bi se dobio bolje građen sistem (npr, ponovo konstruisati kod i podatke)
Poluautomatska konstrukcija strukturnih i funkcionalnih apstakcija
Ponovno konstruisanje ili reimplementiranje dotičnog sistema iz tih apstrakcija

39. Obnova dizajna
Obnova dizajna ili reverzno projektovanje je podgrupa aktivnosti u sklopu reverznog inženjeringa u čijem se domenu znanje, spoljašnje informacije i dedukcija pridodaju opservacijama na dotičnom sistemu radi identifikacije apstrakcija višeg nivoa od onih koje se dobijaju direktno iz ispitivanja samog sistema.
Obnova dizajna nanovo stvara projektne apstrakcije iz kombinacije koda, postojeće projektne dokumentacije (ukoliko je dostupna), ličnog iskustva, i opšteg znanja o problemu i domenu aplikacije.

40. Nivoi apstrakcija u okviru obnove dizajna
Aplikacija
Koncept, poslovna pravila, politika
Funkcija
Logička i funkcionalna specifikacija, ne-funkcionalni zahtevi
Struktura
Protok kontrole i podataka, dijagram zavisnosti
Skica strukture i podsistema
Arhitektura softvera
Implementacija
Aps. Sint. stabla, tabela simbola, izvorni kod

41. Ostale RE- aktivnosti(mere)
Reverzna specifikacija je vrsta reverznog inženjeringa kod koje se specifikacija izvlači iz izvornog koda ili opisa dizajna. Termin specifikacija u ovom kontekstu znači bilo kakav apstraktni opis onoga što softver zapravo radi. U progresivnom inženjeringu, specifikacija nam govori šta bi softver TREBALO da radi. Međutim, izvorni kod ne sadrži ovakvu informaciju. Samo u retkim slučajevima, ona se može povratiti(rekonstruisati) iz komentara unutar izvornog koda i od ljudi koji su bili uključeni u proces originalnog progresivnog inženjeringa.
Rekodiranje(ponovno kodiranje) obuhvata promenu implementacionih karakteristika izvornog koda. Restrukturiranje jezičkog prevoda i protoka kontrole su izmene na nivou izvornog koda. Ostale moguće izmene obuhvataju prilagođavanje standardima kodiranja, poboljšanje čitkosti koda, i promena imena programskih stavki.
Redizajn obuhvata izmene karakteristika projekta. Moguće izmene obuhvataju restrukturiranje konstrukcije dizajna, izmenu modela sistemskih podataka onako kako su ugrađeni u strukturi podataka ili u bazi podataka, i poboljšanje algoritma.
Respecifikacija (ponovna specifikacija) obuhvata izmene karakteristika traženog kvaliteta. Ovaj tip izmena se može odnositi na izmenu same forme postojećih zahteva(tj. uzimanje neformalnih zahteva izraženih na engleskom i stvaranje formalne specifikacije na nekom formalnom jeziku Y). Ovaj tip izmena može se odnositi i na izmenu sistemskih zahteva, kao što je dodavanje nekih novih zahteva, ili brisanje nekih starih.