Evolucija softvera

1. Evolucija softvera Uvod

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

3. Održavanje softvera • Održavanje softveraje • Proces modifikacije softverskog sistema ili komponente nakon isporuke radi ispravljanja grešaka, poboljšanjaperformansi ili drugih atrubuta ili prilagodjenja novoj sredini[IEEE Std 610.12-1999] • 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 istovreme 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 softveraje • 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)

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

7. Tipovi održavanja softvera • Prema standardu ISO/IEC 14674 za softverski inženjering - održavanje softvera • Adaptivnoodrž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." • Korektivnoodrž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(…) • Perfektivnoodržavanje • "Modifikacija softverskog proizvoda nakon isporuke radi unapređenja performansi ili održivosti."(takođe uključuje i dodavanje novih karakteristika) • Preventivnoodržavanje • "Modifikacijasoftverskog proizvoda nakonisporuke, 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 14674 za softverski inženjering - održavanje softvera

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 delatnostireinž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

18. Sadržaj • Definicija održavanja i evolucije softvera • Tipovi održavanja i evolucije • Zašto softver evoluira • Otpornost na promene • Klasifikacijaaktivnostireinženjeringa softvera

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 korakeda 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 • Neukanadogradnja i razgradnja njegove konstrukcije • nefleksibilnost od samog početka • nedovoljna ili nesaglasna dokumentacija • pritisak rokova • dvostruka funkcionalnost (duplikacijakoda) • odsustvo modularnosti • ... • Moguće rešenje: reinženjering

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 uputstvaza upotrebu se s vremenom izgube • Teško ih je integrisati sa mlađim sistemima

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.

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.

26. Sadržaj • Definicija održavanja i evolucije softvera • Tipovi održavanja i evolucije • Zašto softver evoluira • Otpornost na promene • Klasifikacijaaktivnostireinž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 proceskoji teče od funkcionalne specifikacijei 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, analizai 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žese 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.