1. Procena troškova Predikcija izmena Analiza uticaja
Evolucija softvera
Procena troškova
Predikcija izmena
Analiza uticaja

2. Sadržaj
Uvod
Procena troškova
Predikcija izmena
Analiza uticaja

3. Održavanje softvera
Održavanje softvera se definiše kao: “Promene koje treba izvršiti na računarskom programu nakon što je on isporučen korisniku.”
Održavanje softvera obuhvata:
Održavanje ispravnosti (engl. Corrective maintenance)
Adaptivno održavanje (engl. Adaptive maintenance)
Održavanje savršenosti (engl. Perfective maintenance)
Povećanja (engl.Enhancements)
Svaka nova promena utiče na ukupne troškove projekta

4. Sadržaj
Uvod
Procena troškova
Predikcija izmena
Analiza uticaja

5. Procena troškova (1)
Procene troškova se bazirana na jednostavnoj pretpostavci da što više posla mora da se uradi, veći će biti troškovi
Troškovi održavanja predstavljaju značajan deo ukupnih troškova tokom celokupnog životnog veka projekta
Obično su veći od troškova razvoja projekta:
Sa faktorom 2 do 100 zavisno od aplikacije
Uvećavaju se tokom održavanja softvera:
Održavanje kvari strukturu softvera čineći dalje održavanje još težim
Ovo se potvrđuje Lemanovim zakonima evolucije softvera:
Uvećanje kompleksnosti
Nastavak rasta
Smanjenje kvaliteta

6. Procena troškova (2)
Spoljni faktori koji utiču na troškove održavanja:
Stabilnost tima
Troškovi održavanja su smanjeni ako isti tim programera održava softver duže vreme
Ugovorena odgovornost
Ako programeri koji razvijaju softver nemaju ugovorenu odgovornost za održavanje, tada ne postoji podsticaj za dizajniranje koje se odnosi na buduće promene. Ovo rezultira loše struktuiranim softverom
Iskustvo tima
Tim za održavanje obično čine neiskusni programeri koji imaju ograničen domen znanja, uopšteno i u vezi sa samim softverom koji se održava
Starost i struktura programa
Kako programi stare, njihova struktura degradira i postaje sve teža za razumevanje i modifikaciju

7. Procena troškova (3)
U g., više od 50 posto softverske populacije bilo je zaduženo u modifikovanju postojećih aplikacija, nego na pisanju novih
Procene troškova održavanja i uloženog napora pomažu da se adekvatno isplanira i tim za održavanje softvera

8. Troškovi razvoja i održavanja softvera u velikim organizacijama

9. Distribucija uloženog napora za održavanje softvera

10. Modeli procene troškova održavanja (1)
COCOMO model održavanja (procena uloženog napora)
(MM)AM = (ACT)(MM)DEV
(MM)AM : godišnji napor održavanja
(MM)DEV : napor razvoja
ACT : (engl. annual change traffic) deo softvera koji je podložan promenama tokom jedne godina
Koeficijent troškova održavanja/razvoja
(MM)M = (M/D)(MM)DEV
(MM)M : napor održavanja tokom celog životnog veka
M/D : koeficijent troškova održavanja/razvoja

11. Modeli procene troškova održavanja (2)
Koeficijen produktivnosti održavanja
(DSI)MOD/YR = (ACT)(DSI)DEV
(DSI)MOD/YR
(MM)AM =
(DSI/MM)MOD
(DSI)MOD/YR : broj izvornih instrukcija modifikovanih tokom jedne godine
(DSI)DEV : veličina softvera u izvornim instrukcijama
(MM)AM : godišnji napor održavanja
ACT : annual change traffic
(DSI/MM)MOD : koeficijen produktivnosti održavanja (broj izvornih instrukcija modifikovanih po uloženom naporu jednog programera za jedan mesec)

12. Sadržaj
Uvod
Procena troškova
Predikcija izmena
Analiza uticaja

13. Predikcija izmena (1) Zadaci predikcije izmena su da predvidi:
Koje sistemske izmene će se sa najvećom verovatnoćom ostvariti
Koji delovi sistema će najpre da izazovu najveće poteškoće za tim koji održava softver
Ukupne troškove održavanja sistema u datom vremenskom periodu

14. Predikcija izmena (2) Ove različite predikcije su usko povezane sa:
Da li da bude ili ne prihvaćena izmena u sistemu zavisi, do određene mere, od stepena održavanja komponenti sistema koje su pogođene tom izmenom
Implementacija izmena sistema često degradira strukturu sistema i time smanjuje njegov stepene održavanja
Troškovi održavanja zavise od broja promena, a cene implementacija izmena zavise od stepena održavanja komponenti sistema

15. Sistem i njegova okolina
Predikcija izmena zahteva razumevanje odnosa između sistema i njegove okoline
Usko povezani sistemi imaju potrebe za promenama svaki put kada se i okolina menja
Faktori koji utiču na ovaj odnos su:
Broj i kompleksnost interfejsa sistema
Broj nerazdvojivo “halapljivih” sistemskih zahteva
Biznis procesi u kojima se sistem koristi

16. Tehnike predikcije izmena
Predikcija izmena zahteva tehnike:
Analiza uticaja
Da bi predvidela koje će sve komponente sistema biti pogođene izmenom
Procena uloženog napora
Da bi predvidela napor koji je potreban za modifikaciju ovih komponenti
Zavisi od kvaliteta ovih komponenti
Procena troškova
Da bi predvidela ukupne troškove implementacije izmena

17. Predikcija stepena održavanja
Istraživanja pokazuju da se najveći deo uloženog napora za održavanje odnosi na mali broj komponenti sistema, koje imaju veliki stepen kompleksnosti
Predikcija stepena održavanja se može bazirati na određivanju kompeksnosti
Metrike kompleksnosti:
Kompleksnost kontrolnih struktura
Kompleksnost struktura podataka
Veličina procedura i modula
Bilo bi korisno zameniti kompleksne komponete jednostavnijim

18. Predikcija stepena održavanja pomoću procesne metrike
Merenje procesa može se koristiti za procenu stepena održavanja
Broj zahteva vezanih za održavanje ispravnosti
Prosečno vreme neophodno za analizu uticaja
Prosečno vreme potrebno za implementaciju zahteva za promenom
Broj nerešenih zahteva za promenom
Ako bilo koji ili svi od ovih parametara počnu da se uvećavaju, to može značiti da dolazi do smanjenja stepena održavanja

19. Predikcija stepena održavanja određivanjem nivoa kohezije i sparivanja
Dobar dizajn treba da obezbedi lako:
Razumevanje, promene, ponovnu upotrebu, testiranje, integraciju i kodiranje
Da bi se sve ovo postiglo neophodno je razmotriti:
Koheziju jedinice, modula ili komponente koja se definiše kao “stepen povezanosti” unutar date jedinice, modula ili komponente
Sparivanje koje se definiše kao “stepen međuzavisnosti” između softverskih jedinica, modula ili komponenti

20. Kohezija Nivo kohezije Objašnjenje 1. 2. 3. 4. 5. 6. 7. Funkcionalni
Jedinica (modul) obavlja jednu glavnu aktivnost ili ostvaruje jedan cilj. 2.
Sekvencijalni
Jedinica (modul) obavlja jednu glavnu aktivnost ili ostvaruje jedan cilj. Može da sadrži elemente koji nisu sasvim orijentisani ka ostvarivanju jednog cilja. 3.
Komunikacioni
Jedinica (modul) sadrži akcije koje pripadaju nekoj kontrolnoj sekvenci, pri čemu su akcije usmerene ka istom podatku ili podacima. 4.
Proceduralni
Jedinica (modul) sadrži akcije koje pripadaju nekoj kontrolnoj sekvenci. 5.
Temporalni
Jedinica (modul) sadrži niz elemenata koji su vremenski povezani. 6.
Logički
Jedinica (modul) obavlja niz sličnih zadataka.
Ali su elementi jedinice poprilično nezavisni. 7.
Podudarni
Jedinica (modul) obavlja više nepovezanih zadataka.
Što viši to
bolji nivo

21. Sparivanje Nivo sparivanja Objašnjenje 1. 2. 3. 4. 5. 6. Sadržajni
Dve jedinice (modula) imaj pristup internim (unutrašnjim) ili proceduralnim podacima druge jedinice. 2.
Zajednički
Dve jedinice dele zajedničke globalne promenljive. 3.
Kontrolni
Jedna jedinica prosleđuje kontrolne podatke i eksplicitno utiče na logiku druge jedinice. 4.
Markirani
Jedna jedinica prosleđuje grupu (cele strukture ili zapise) podataka drugoj jedinici. 5.
Na nivou podataka
Jedna jedinica prosleđuje samo neophodne podataka drugoj jedinici. 6.
Nema sparivanja
Idealan slučaj, ali ne i realan u praksi.
Što niži to
bolji nivo

22. Metrike kohezije i sparivanja
Visok nivo
Chidamber and Kemerer (C-K) OO metrike:
Weighted Methods per class (WMC)
Depth of Inheritance Tree (DIT)
Number of Children (NOC)
Coupling Between Object Classes (CBO)
Response for a Class (RFC)
Lack of Cohesion in Methods (LCOM)
Bieman and Ott metrika:
Using Program and Data Slices
Jaka
Tesno
Kohezija
Sparivanje
Slaba
Labavo
Nizak nivo

23. Sadržaj
Uvod
Procena troškova
Predikcija izmena
Analiza uticaja

24. Analiza uticaja (1)
Analiza uticaja je postupak koji predviđa i određuje delove softverskog sistema koji mogu biti pogođeni promenama tog sistema
Skup promena: Delovi softverskog sistema koji će biti promenjeni
Skup uticaja: Delovi softverskog sitema koji će biti pogođeni tim novim promenama
Dva tipa analize:
Statička
Dinamička

25. Analiza uticaja (2)
Analiza uticaja je sistematski pristup shvatanja uticaja izmena u softveru i bitan je za:
Identifikaciju delova nad kojima je neophodno ponovo pokrenuti testove
Poboljšanje procenjenog vremena, rada i novca za održavanje softvera
Smanjenje broja potencijalnih grešaka nastalih usled neodkrivenih uticaja izmena
Poboljšanje ukupne efikasnosti održavanja softvera

26. Statička analiza uticaja
Zasniva se na analizi izvornog koda
Bazirana na predpostavci o svim mogućim ponašanjima softvera u vreme izvršavanja
Može se desiti da rezultati neefikasno uključe veliki deo
softverskog sistema u skup uticaja
Ispitivanje izvornog koda
Analiziranje zavisnosti među programaskim entitetima
Zahtevi za promenama
Skup uticaja
Zapisivanje mogućih ponašanja sistema

27. Dinamička analiza uticaja
Bazirana na podacima iz vremena izvršavanja softvera i dinamičkim interaktivnim ponašanjima softverskog sistema
Zavisi od skupa izvršavanja datog sistema
Teži da proizvede preciznije rezultate nego statička analiza
Izvršavanje softverskog sistema
Analiziranje zavisnosti među programaskim entitetima iz vremenu izvršavanja
Zahtevi za promenama
Skupljanje podataka iz vremena izvršavanja sistema
Skup uticaja

28. Efekat talasa Efekat talasa (engl. Ripple effect)
Pojava gde promena u jednom delu softverskog sistema utiče na još bar jednu oblast istog softverskog sistema (direktno ili indirektno)
Promena
komponente
Propagacija
izmena

29. Propagacija izmene Propagacija izmene
Javlja se kada pravljenje izmene jednog dela softverskog sistema zahteva da ostali delovi sistema koji zavise od njega takođe budu izmenjeni
Ovi zavisni delovi sistema, posle izmene, takođe mogu zahtevati promene u drugim delovima softvera
Na taj način, jedna izmena u jednom delu sistema može dovesti do propagacije promena kroz čitav softverski sistem

30. Analiza uticaja i propagacija izmena
Obići komponentu po komponentu sistema
Ako je posećena komponenta promenjena, moguće je da više ne odgovara kao takva u sistemu:
Sekundarne izmene moraju biti načinjene u susednim komponentama, tj. komponentama sa kojima postoji interakcija
Sekundarne izmene mogu pokrenuti nove dodatne izmene:
“efekat talasa”
Softver nije konzistentan tokom propagacije
Skrivena propagacija
Sama klasa se ne menja, ali propagira promenu

31. Reference Seminar on Software Cost Estimation, WS 02/03, Arun Mukhija
Software Engineering, 6th Edition, Ian Sommerville
Essentials of Software Engineering, Frank F. Tsui, Orlando Karam
Object-oriented Software Change Dynamic Impact Analysis, Lulu Huang and Yeong-Tae Song