1 / 31

Evolucija softvera

Evolucija softvera. Procena troškova Predikcija izmena Analiza uticaja. Sadržaj. Uvod Procena troškova Predikcija izmena Analiza uticaja. Održavanje softvera.

denna
Télécharger la présentation

Evolucija softvera

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 trebaizvrš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 2001. 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 (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 : 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, modulaili komponente • Sparivanjekoje se definiše kao “stepen međuzavisnosti” između softverskih jedinica, modula ili komponenti

  20. Kohezija Što viši to bolji nivo

  21. Sparivanje Š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 jepostupak 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

More Related