Modyfikacja oprogramowania

1
Modyfikacja oprogramowania

• Omówienie zagadnien zwiazanych z modyfikacja
  oprogramowania

2
Prezentowane zagadnienia

• Dynamika ewolucji programów
• Pielegnacja oprogramowania
• Ewolucja architektoniczna

3
Wstep - Potrzeba modyfikacji oprogramowania

• Niezaleznie od wielkosci nie da sie zbudowac
  systemu, którego nie bedzie trzeba zmieniac.
• Modyfikacja oprogramowania jest wiec istotnym
  zagadnieniem, poniewaz wiekszosc firm calkowicie
  zalezy od swoich systemów oprogramowania, w które
  zainwestowaly miliony.
• Zatem firmy musza inwestowac w modyfikacje
  systemu, aby utrzymywac ich wartosc.

4
Strategie modyfikowania oprogramowania

• Pielegnacja oprogramowania. Oprogramowanie jest
  zmieniane w odpowiedzi na zmiany wymagan, ale
  zasadnicza struktura oprogramowania pozostaje
  niezmieniona.
• Przeksztalcenie architektoniczne. Jest to
  bardziej radykalne podejscie do modyfikacji
  oprogramowania, poniewaz polega na wprowadzeniu
  znacznych zmian w architekturze systemu
  oprogramowania.
• Restrukturyzacja oprogramowania. System jest
  modyfikowany w celu zwiekszenia jego
  zrozumialosci i ulatwienia zmian. Nie doklada
  sie nowej funkcjonalnosci do systemu.

5
1.Dynamika ewolucji programów

• Dynamika ewolucji programów to studium zmiany
  systemu.
• Wiekszosc wyników w tej dziedzinie przypisuje sie
  Lehmanowi i Beladyemu (1985), którzy jako wynik
  swych studiów sformulowali pewien zbiór praw
  zmiany systemu (tzw. prawa Lehmana).
• Autorzy uwazaja, ze prawa sa niezmienne i maja
  szerokie zastosowania.

6
Prawa Lehmana
Prawo Opis Ustawiczna Program uzytkowy w
rzeczywistym srodowisku nieuchronnie musi
podlegac zmiana zmianom albo stawac sie coraz
mniej uzyteczny w tym srodowisku. Rosnaca W
miare jak ewoluujacy program zmienia sie, jego
struktura staje sie coraz zlozonosc bardziej
zlozona. Na zachowywanie i upraszczanie struktury
trzeba przeznaczyc dodatkowe
zasoby. Ewolucja Ewolucja programu jest
samoregulujacym sie procesem. Atrybuty systemu,
ogromnych takie jak wielkosc, czas miedzy
wydaniami i liczba zgloszonych bledów,
sa programów w przyblizeniu takie same dla
wszystkich wydan systemów. Stabilnosc W czasie
zycia programu tempo jego rozwoju jest w
przyblizeniu stale organizacyjna i niezalezne od
zasobów przeznaczonych na zbudowanie
systemu. Stala W czasie zycia systemu
przyrostowa zmiana jest stala w kazdym
wydaniu. zmiennosc
7
2.Pielegnacja oprogramowania

• Pielegnacja oprogramowania to ogólny proces
  zmieniania systemu po jego dostarczeniu.
• Moga to byc proste zmiany w celu poprawienia
  bledów w kodzie, bardziej intensywne w celu
  poprawienia bledów projektowych, a nawet znaczne
  rozszerzenia w celu poprawienia bledów w
  specyfikacji lub spelnienia nowych wymagan.
• Pielegnacja oprogramowania zwykle nie obejmuje
  duzych zmian architektonicznych systemu.
• Zmiany implementuje sie przez modyfikacje
  istniejacych komponentów systemu oraz, gdy jest
  to konieczne, przez dodawanie nowych komponentów.

8
Rózne rodzaje pielegnacji oprogramowania

• Pielegnacja w celu naprawy usterek
  oprogramowania. Poprawienie bledów w kodzie jest
  zwykle dosc tanie. Bledy projektowe sa znacznie
  kosztowniejsze, poniewaz ich poprawienie moze
  wymagac przepisania kilku komponentów programów.
• Pielegnacja w celu dostosowania oprogramowania do
  innego srodowiska operacyjnego. Ten rodzaj
  pielegnacji jest niezbedny, gdy pewien element
  srodowiska systemu, taki jak sprzet, system
  operacyjny platformy lub oprogramowanie
  pomocnicze, ulega zmianie.
• Pielegnacja w celu rozszerzenia lub
  zmodyfikowania funkcjonalnosci systemu. Ten
  rodzaj pielegnacji jest niezbedny, gdy zmienia
  sie wymagania systemowe w odpowiedzi na zmiany
  gospodarcze i organizacyjne.

9
Statystyczny naklad odzial pracy przy pielegnacji
Naprawienie usterek

(
1
7

)
Dodawanie i modyfikowanie funkcjonalnosci
Przystosowywanie oprogramowania

(
1
8

)
(
6
5

)
10
Model spiralny tworzenia
Specyfikowanie
Implementowanie
Poczatek

Wydanie 1
Dzialanie
Zatwierdzanie
Wydanie 2

Wydanie 3

11
Glówne czynniki, które róznia tworzenie i
pielegnacje,i powoduja wyzsze koszty pielegnacji

• Stabilnosc zespolu. Po dostarczeniu systemu
  zespól wytwórczy jest zwykle rozwiazywany, a jego
  czlonkowie przechodza do nowych przedsiewziec.
  Nowy zespól albo osoby odpowiedzialne za
  pielegnacje systemu nie znaja go ani przyczyn
  podjetych decyzji projektowych.
• Zobowiazania umowne. Umowa na pielegnacje systemu
  jest zwykle oddzielona od umowy na budowe
  systemu. Umowa pielegnacyjna moze byc podpisana z
  inna firma, a nie wytwórca pierwotnego systemu.
  Ten czynnik wraz z brakiem stabilnosci zespolu
  oznacza, ze zespól wytwórczy nie ma motywacji do
  pisania oprogramowania tak, aby bylo latwe do
  modyfikacji.
• Umiejetnosci personelu. Personel pielegnujacy ma
  czesto male doswiadczenie i nie jest obznajomiony
  z dziedzina zastosowania. Pielegnacja nie jest
  dobrze postrzegana przez inzynierów
  oprogramowania. Uwaza sie ja za proces wymagajacy
  mniej umiejetnosci niz tworzenie systemu i
  przydziela do niej najmlodszych pracowników. Co
  wiecej, stare systemy moga byc napisane w
  przestarzalych jezykach programowania.
• Wiek i struktura systemu. W miare starzenia sie
  programu jego struktura ulega degradacji w wyniku
  zmian. Takie systemy jest wiec trudniej zrozumiec
  i modyfikowac.

12
Proces pielegnacji

• Procesy pielegnacji moga znacznie sie od siebie
  róznic zaleznie od rodzaju pielegnowanego
  oprogramowania, przyjetego w firmie procesu
  tworzenia i osób uczestniczacych w tym procesie.
• W niektórych przedsiebiorstwach pielegnacja jest
  procesem nieformalnym, z kolei w innych firmach
  jest to sformalizowany proces ze strukturalna
  dokumentacja opracowana na kazdym etapie procesu.
• Na poziomie abstrakcyjnym wszystkie procesy
  pielegnacji obejmuja jednak te same zasadnicze
  czynnosci analize zmiany, planowanie wydania,
  implementacje systemu i przekazanie systemu
  uzytkownikom.

13
Szkic procesu pielegnacji
Zadana zmiana
Analiza wplywu
Wydanie systemu
Implementacja zmiany
Planowanie wydania
Naprawa usterek
Dostosowanie do platformy
Rozszerzenie systemu
14
Implementacja zmiany
Proponowane zmiany
Tworzenie oprogramowania
Aktualizacja wymagan
Analiza wymagan
15
Proces awaryjnej naprawy
Dostarcz zmodyfikowany system
Zadanie zmian
Zmodyfikuj kod zródlowy
Zanalizuj kod zródlowy
16
Przewidywanie pielegnacji

• Menedzerowie nienawidza niespodzianek, jesli ich
  wynikiem sa nieoczekiwanie wysokie koszty. Z ich
  punktu widzenia warto wiec starac sie
  przewidywac, jakie zadania zmian systemu
  prawdopodobnie sie pojawia, które czesci systemu
  prawdopodobnie sprawia personelowi pielegnujacemu
  najwieksze trudnosci oraz jakie beda calkowite
  koszty pielegnacji systemu w ustalonym okresie.

17
Przewidywanie pielegnacji
Które czesci systemu beda najdrozsze w
pielegnacji?
Których czesci systemu beda najczesciej dotyczyly
zadani zmian?
Przewidywanie zdatnosci do pielegnacji
Jaki bedzie koszt pielegnacji systemu w czasie
calego jego zycia?
Przewidywanie kosztów pielegnacji
Przewidywanie zmian systemu
Jak duzo spodziewamy sie zadan zmian?
Jakie beda koszty pielegnacji systemu w nastepnym
roku?
18
Czynniki majace wplyw na koniecznosc pielegnacji.

• Liczba i zlozonosc interfejsów systemu. Im
  wieksza jest liczba i zlozonosc tych interfejsów,
  tym wieksze jest prawdopodobienstwo pojawienia
  sie oczekiwan zmian.
• Liczba z natury plynnych wymagan systemu.
  Wymagania odzwierciedlajace firmowe strategie i
  procedury sa zwykle bardziej zmienne niz
  wymagania, których podstawa sa stabilne
  wlasciwosci dziedziny.
• Procesy gospodarcze, w których uzywa sie systemu.
  W miare ewolucji procesów gospodarczych powstaja
  zadania zmian systemu. Im bardziej w procesach
  gospodarczych korzysta sie z systemu, tym wiecej
  pojawi sie oczekiwan zmiany systemu.

19
Przyklady miar procesowych przy ocenie zdatnosci
do pielegnacji

• Liczba zadan pielegnacji korygujacych. Jesli
  rosnie liczba zgloszonych awarii, byc moze w
  trakcie procesu pielegnacji liczba nowych bledów
  wprowadzonych do programu jest wieksza niz liczba
  naprawianych bledów.
• Sredni czas niezbedny do wykonania analizy
  wplywu. Odzwierciedla liczbe komponentów
  programu, na które oddzialuja zadania zmian.
• Sredni czas spedzony nad implementacja zadania
  zmiany. Czas trwania zmiany zalezy od trudnosci
  jej zaprogramowania.
• Liczba oczekujacych zadan zmian. Jesli ta liczba
  rosnie z czasem, moze to oznaczac zmniejszenie
  zdatnosci do pielegnacji.

20
3.Ewolucja architektoniczna

• W trakcie pielegnacji systemu wprowadzone zmiany
  sa lokalne nie wplywaja na architekture systemu.
• Od lat osiemdziesiatych XX wieku ekonomia
  systemów komputerowych zmieniala sie jednak
  radykalnie.
• Najbardziej oplacalnym rozwiazaniem problemów
  gospodarczych jest czesto system rozproszony, a
  nie scentralizowany.
• Wiele firm staje wiec przed koniecznoscia
  przeobrazenia swoich scentralizowanych systemów
  na komputerach glównych w systemy klient-serwer
  badz w systemy rozproszone.

21
Bodzce, które przyczyniaja sie do przemiany

• Koszt sprzetu. Koszt zakupu i utrzymania
  rozproszonego systemu klient-serwer jest zwykle
  znacznie mniejszy niz koszt zakupu komputera
  glównego o takiej samej mocy.
• Oczekiwania wobec interfejsu uzytkownika. Wiele
  odziedziczonych systemów na komputerach glównych
  oferuje znakowy interfejs formularzowy. Wiekszosc
  uzytkowników oczekuje obecnie interfejsów
  graficznych i latwiejszej interakcji z systemem.
• Rozproszony dostep do systemu. Firmy coraz
  bardziej rozpraszaja swoje struktury i nie
  utrzymuja wszystkich udogodnien w jednym osrodku.
  Ich systemy komputerowe musza byc dostepne z
  wielu miejsc i za pomoca rozmaitych rodzajów
  sprzetu.
• Niezawodnosc dostepu do systemu. Kazda
  niedostepnosc uslugi wiaze sie z potencjalna
  strata zysków.

22
Czynniki wplywajace na decyzje o rozproszeniu
systemu
Czynnik Opis Znaczenie Stopa zwrotu z inwestycji
w rozproszenie systemu odziedziczonego zalezy
gospodarcze od znaczenia dla przedsiebiorstwa i
tego, jak dlugo sie ono utrzyma. Jesli
rozproszenie skutecznie wspomaga stabilne
procesy gospodarcze, to prawdopodobnie bedzie
to bardziej oplacalna strategia ewolucyjna. Wiek
systemu Im starszy jest system, tym trudniej jest
modyfikowac jego architekture, poniewaz
wczesniejsze zmiany pogorszyly strukture
systemu. Struktura systemu Im system jest
bardziej modularny, tym latwiej jest zmienic jego
architekture. Jesli uslugi uzytkowe,
zarzadzanie danymi i interfejs uzytkownika sa w
systemie scisle splecione, to trudno bedzie
wydzielic funkcje przy przeksztalceniu. Strate
gie Rozproszenie programu uzytkowego moze byc
konieczne, jesli w firmie zaopatrywania przyjeto
strategie wymiany drogich komputerów glównych na
tansze sie w sprzet serwery.
23
Idealna i realistyczna struktura systemu
odziedziczonego
Interfejs uzytkownika
Interfejs uzytkownika

Uslugi
Uslugi
Baz danych
Baz danych




Model idealny do rozproszenia Prawdziwe systemy
odziedziczone
24
Rozproszenie systemu odziedziczonego
Biurkowe komputery osobiste z uruchomionym
programem uzytkowym
System odziedziczony
Warstwa sródprogramowa (oslona)
Uslugi uzytkowe
Baza danych
System odziedziczony
Interfejs uzytkownika
25
Rozproszenie interfejsu uzytkownika

• Wiele systemów odziedziczonych zaprojektowano,
  zanim pojawily sie graficzne interfejsy
  uzytkownika.
• Takie systemy obejmowaly interfejsy formularzowe
  dzialajace na specjalnych terminalach, które
  mogly wyswietlac jedynie znaki.
• Te terminale mialy ograniczona moc obliczeniowa i
  wlasciwosci wyswietlania, a zatem wyswietlanie i
  wszystkie zwiazane z nim funkcje obliczeniowe
  byly obslugiwane przez centralny system komputera
  glównego.
• Nawet po zastapieniu tych terminali przez
  komputery osobiste te znakowe interfejsy sa nadal
  w uzyciu dzieki programom nasladujacym terminale
  na komputerze osobistym.

26
Rozproszenie interfejsu uzytkownika
Biurkowe komputery osobiste z interfejsem
graficznym
Opis ekranów
System odziedziczony
Uslugi uzytkowe
Sródprogram zarzadzajacy ekranami
Baza danych
Interfejs uzytkownika
27
Wady i zalety strategii przenoszenia interfejsu
uzytkownika
Strategia Zalety Wady Implementacja
Dostep do wszystkich funkcji Zaleznosc
od platformy z uzyciem interfejsu uzytkownika, a
wiec Trudniej osiagnac spójnosc systemu
okienkowego brak ograniczen przy projekto-
interfejsu -waniu interfejsu. Lepsza
efektywnosc interfejsu uzytkownika. Implemen
tacja Niezaleznosc od platformy
Potencjalnie gorsza z uzyciem Nizsze koszty
szkolenia dzieki efektywnosc przegladarki
WWW temu, ze uzytkownicy znaja Projekt
interfejsu jest WWW ograniczony
przez wlasci- Latwiej osiagnac spójnosc
-wosci przegladarek WWW interfejsu
28
Opracowne na podstawie

• Ian Sommerville 2000
• Inzynieria oprogramowania.
• Ewolucja i refaktoryzacja oprogramowania.