Evolucija softvera

1
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 racunarskom programu nakon
  što je on isporucen korisniku.
• Održavanje softvera obuhvata
• Održavanje ispravnosti (engl. Corrective
  maintenance)
• Adaptivno održavanje (engl. Adaptive maintenance)
• Održavanje savršenosti (engl. Perfective
  maintenance)
• Povecanja (engl.Enhancements)
• Svaka nova promena utice 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,
  veci ce biti troškovi
• Troškovi održavanja predstavljaju znacajan deo
  ukupnih troškova tokom celokupnog životnog veka
  projekta
• Obicno su veci od troškova razvoja projekta
• Sa faktorom 2 do 100 zavisno od aplikacije
• Uvecavaju se tokom održavanja softvera
• Održavanje kvari strukturu softvera cineci dalje
  održavanje još težim
• Ovo se potvrduje Lemanovim zakonima evolucije
  softvera
• Uvecanje kompleksnosti
• Nastavak rasta
• Smanjenje kvaliteta

6
Procena troškova (2)

• Spoljni faktori koji uticu 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 buduce promene. Ovo rezultira loše
  struktuiranim softverom
• Iskustvo tima
• Tim za održavanje obicno cine neiskusni
  programeri koji imaju ogranicen 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 2001. g., više od 50 posto softverske
  populacije bilo je zaduženo u modifikovanju
  postojecih 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
• (MM)DEV napor razvoja
• 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 velicina 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 ce se sa najvecom
  verovatnocom ostvariti
• Koji delovi sistema ce najpre da izazovu najvece
  poteškoce za tim koji održava softver
• Ukupne troškove održavanja sistema u datom
  vremenskom periodu

14
Predikcija izmena (2)

• Ove razlicite predikcije su usko povezane sa
• Da li da bude ili ne prihvacena izmena u sistemu
  zavisi, do odredene mere, od stepena održavanja
  komponenti sistema koje su pogodene tom izmenom
• Implementacija izmena sistema cesto 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
  izmedu sistema i njegove okoline
• Usko povezani sistemi imaju potrebe za promenama
  svaki put kada se i okolina menja
• Faktori koji uticu 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 ce sve komponente sistema
  biti pogodene 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 najveci 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
  odredivanju kompeksnosti
• Metrike kompleksnosti
• Kompleksnost kontrolnih struktura
• Kompleksnost struktura podataka
• Velicina procedura i modula
• Bilo bi korisno zameniti kompleksne komponete
  jednostavnijim

18
Predikcija stepena održavanja pomocu procesne
metrike

• Merenje procesa može se koristiti za procenu
  stepena održavanja
• Broj zahteva vezanih za održavanje ispravnosti
• Prosecno vreme neophodno za analizu uticaja
• Prosecno vreme potrebno za implementaciju zahteva
  za promenom
• Broj nerešenih zahteva za promenom
• Ako bilo koji ili svi od ovih parametara pocnu da
  se uvecavaju, to može znaciti da dolazi do
  smanjenja stepena održavanja

19
Predikcija stepena održavanja odredivanjem 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
  meduzavisnosti izmedu softverskih jedinica,
  modula ili komponenti

20
Kohezija
Nivo kohezije Objašnjenje
1. 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 cemu 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. Logicki Jedinica (modul) obavlja niz slicnih zadataka. Ali su elementi jedinice poprilicno nezavisni.
7. Podudarni Jedinica (modul) obavlja više nepovezanih zadataka.
Što viši to bolji nivo
21
Sparivanje
Nivo sparivanja Objašnjenje
1. Sadržajni Dve jedinice (modula) imaj pristup internim (unutrašnjim) ili proceduralnim podacima druge jedinice.
2. Zajednicki Dve jedinice dele zajednicke globalne promenljive.
3. Kontrolni Jedna jedinica prosleduje kontrolne podatke i eksplicitno utice na logiku druge jedinice.
4. Markirani Jedna jedinica prosleduje grupu (cele strukture ili zapise) podataka drugoj jedinici.
5. Na nivou podataka Jedna jedinica prosleduje samo neophodne podataka drugoj jedinici.
6. Nema sparivanja Idealan slucaj, 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 predvida i
  odreduje delove softverskog sistema koji mogu
  biti pogodeni promenama tog sistema
• Skup promena Delovi softverskog sistema koji ce
  biti promenjeni
• Skup uticaja Delovi softverskog sitema koji ce
  biti pogodeni tim novim promenama
• Dva tipa analize
• Staticka
• Dinamicka

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
Staticka analiza uticaja

• Zasniva se na analizi izvornog koda
• Bazirana na predpostavci o svim mogucim
  ponašanjima softvera u vreme izvršavanja
• Može se desiti da rezultati neefikasno ukljuce
  veliki deo
• softverskog sistema u skup uticaja

Ispitivanje izvornog koda
Analiziranje zavisnosti medu programaskim
entitetima
Zahtevi za promenama
Skup uticaja
Zapisivanje mogucih ponašanja sistema
27
Dinamicka analiza uticaja

• Bazirana na podacima iz vremena izvršavanja
  softvera i dinamickim interaktivnim ponašanjima
  softverskog sistema
• Zavisi od skupa izvršavanja datog sistema
• Teži da proizvede preciznije rezultate nego
  staticka analiza

Izvršavanje softverskog sistema
Analiziranje zavisnosti medu programaskim
entitetima iz vremenu izvršavanja
Skupljanje podataka iz vremena izvršavanja sistema
Zahtevi za promenama
Skup uticaja
28
Efekat talasa

• Efekat talasa (engl. Ripple effect)
• Pojava gde promena u jednom delu softverskog
  sistema utice 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 takode budu
  izmenjeni
• Ovi zavisni delovi sistema, posle izmene, takode
  mogu zahtevati promene u drugim delovima softvera
• Na taj nacin, jedna izmena u jednom delu sistema
  može dovesti do propagacije promena kroz citav
  softverski sistem

30
Analiza uticaja i propagacija izmena

• Obici komponentu po komponentu sistema
• Ako je posecena komponenta promenjena, moguce je
  da više ne odgovara kao takva u sistemu
• Sekundarne izmene moraju biti nacinjene 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