Modyfikacja oprogramowania l Omwienie zagadnie zwizanych z modyfikacj

Modyfikacja oprogramowania l Omówienie zagadnień związanych z modyfikacją oprogramowania ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 1

Cele l l l Poznać trzy różne strategie modyfikowania systemów oprogramowania, tzn. pielęgnację oprogramowania, ewolucję architektoniczną i restrukturyzację oprogramowania. Poznać zasady pielęgnacji oprogramowania i dowiedzieć się, dlaczego pielęgnowanie oprogramowania jest kosztowne. Dowiedzieć, w jaki sposób można przekształcić systemy odziedziczone w systemy klient-serwer w celu wydłużenia ich życia i skutecznego wykorzystania nowoczesnego sprzętu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 2

Potrzeba modyfikacji oprogramowania l l l Niezależnie od wielkości nie da się zbudować systemu, którego nie będzie trzeba zmieniać. Modyfikacja oprogramowania jest więc istotnym zagadnieniem, ponieważ niektóre firmy całkowicie zależą od swoich systemów oprogramowania, w które zainwestowały miliony dolarów. Zatem firmy muszą inwestować w modyfikację systemu, aby utrzymywać ich wartość. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 4

Strategie modyfikowania oprogramowania l l l Pielęgnacja oprogramowania. Oprogramowanie jest zmieniane w odpowiedzi na zmiany wymagań, ale zasadnicza struktura oprogramowania pozostaje niezmieniona. Przekształcenie architektoniczne. Jest to bardziej radykalne podejście do modyfikacji oprogramowania, ponieważ polega na wprowadzeniu znacznych zmian w architekturze systemu oprogramowania. Restrukturyzacja oprogramowania. System jest modyfikowany w celu zwiększenia jego zrozumiałości i ułatwienia zmian. Nie dokłada się nowej funkcjonalności do systemu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 5

Dynamika ewolucji programów l l Dynamika ewolucji programów to studium zmiany systemu. Większość wyników w tej dziedzinie przypisuje się Lehmanowi i Belady’emu (1985), którzy jako wynik swych studiów sformułowali pewien zbiór „praw” zmiany systemu (tzw. prawa Lehmana). Autorzy uważają, że „prawa” są niezmienne i mają szerokie zastosowania. Lehman i Belady badali rozwój i ewolucje kilku wielkich systemów oprogramowania. Wyniki tych pomiarów były podstawą zaproponowanych praw. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 6

Prawa Lehmana Prawo Opis Ustawiczna zmiana Program użytkowy w rzeczywistym środowisku nieuchronnie musi podlegać zmianom albo stawać się coraz mniej użyteczny w tym środowisku. Rosnąca W miarę jak ewoluujący program zmienia się, jego struktura staje się coraz złożonośćbardziej złożona. Na zachowywanie i upraszczanie struktury trzeba przeznaczyć dodatkowe zasoby. Ewolucja ogromnych programów Ewolucja programu jest samoregulującym się procesem. Atrybuty systemu, takie jak wielkość, czas między wydaniami i liczba zgłoszonych błędów, są w przybliżeniu takie same dla wszystkich wydań systemów. Stabilność organizacyjna W czasie życia programu tempo jego rozwoju jest w przybliżeniu stałe i niezależne od zasobów przeznaczonych na zbudowanie systemu. Stała zmienność W czasie życia systemu przyrostowa zmiana jest stała w każdym wydaniu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 7

Pielęgnacja oprogramowania l l Pielęgnacja oprogramowania to ogólny proces zmieniania systemu po jego dostarczeniu. Mogą to być proste zmiany w celu poprawienia błędów w kodzie, bardziej intensywne w celu poprawienia błędów projektowych, a nawet znaczne rozszerzenia w celu poprawienia błędów w specyfikacji lub spełnienia nowych wymagań. Pielęgnacja oprogramowania zwykle nie obejmuje dużych zmian architektonicznych systemu. Zmiany implementuje się przez modyfikacje istniejących komponentów systemu oraz, gdy jest to konieczne, przez dodawanie nowych komponentów. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 8

Różne rodzaje pielęgnacji oprogramowania l l l Pielęgnacja w celu naprawy usterek oprogramowania. Poprawienie błędów w kodzie jest zwykle dość tanie. Błędy projektowe są znacznie kosztowniejsze, ponieważ ich poprawienie może wymagać przepisania kilku komponentów programów. Pielęgnacja w celu dostosowania oprogramowania do innego środowiska operacyjnego. Ten rodzaj pielęgnacji jest niezbędny, gdy pewien element środowiska systemu, taki jak sprzęt, system operacyjny platformy lub oprogramowanie pomocnicze, ulega zmianie. Pielęgnacja w celu rozszerzenia lub zmodyfikowania funkcjonalności systemu. Ten rodzaj pielęgnacji jest niezbędny, gdy zmienia się wymagania systemowe w odpowiedzi na zmiany gospodarcze i organizacyjne. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 9

Podział pracy przy pielęgnacji Naprawienie usterek (17%) Przystosowywanie oprogramowania Dodawanie i modyfikowanie funkcjonalności (18%) (65%) ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 10

Model spiralny tworzenia Specyfikowanie Implementowanie Początek Wydanie 1 Działanie Zatwierdzanie Wydanie 2 Wydanie 3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 11

Koszty tworzenia i pielęgnacji System 1 System 2 0 50 Koszty tworzenia ©Ian Sommerville 2000 150 200 250 300 350 400 450 Koszty pielęgnacji Inżynieria oprogramowania, Rozdział 27 Slide 12 500 $

Główne czynniki, które różnią tworzenie i pielęgnację, i powodują wyższe koszty pielęgnacji l l Stabilność zespołu. Po dostarczeniu systemu zespół wytwórczy jest zwykle rozwiązywany, a jego członkowie przechodzą do nowych przedsięwzięć. Nowy zespół albo osoby odpowiedzialne za pielęgnację systemu nie znają go ani przyczyn podjętych decyzji projektowych. Zobowiązania umowne. Umowa na pielęgnację systemu jest zwykle oddzielona od umowy na budowę systemu. Umowa pielęgnacyjna może być podpisana z inna firmą, a nie wytwórcą pierwotnego systemu. Ten czynnik wraz z brakiem stabilności zespołu oznacza, że zespół wytwórczy nie ma motywacji do pisania oprogramowania tak, aby było łatwe do modyfikacji. Umiejętności personelu. Personel pielęgnujący ma często małe doświadczenie i nie jest obznajomiony z dziedziną zastosowania. Pielęgnacja nie jest dobrze postrzegana przez inżynierów oprogramowania. Uważa się ją za proces wymagający mniej umiejętności niż tworzenie systemu i przydziela do niej najmłodszych pracowników. Co więcej, stare systemy mogą być napisane w przestarzałych językach programowania. Wiek i struktura systemu. W miarę starzenia się programu jego struktura ulega degradacji w wyniku zmian. Takie systemy jest więc trudniej zrozumieć i modyfikować. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 13

Proces pielęgnacji l l l Procesy pielęgnacji mogą znacznie się od siebie różnić zależnie od rodzaju pielęgnowanego oprogramowania, przyjętego w firmie procesu tworzenia i osób uczestniczących w tym procesie. W niektórych przedsiębiorstwach pielęgnacja jest procesem nieformalnym, z kolei w innych firmach jest to sformalizowany proces ze strukturalną dokumentacją opracowaną na każdym etapie procesu. Na poziomie abstrakcyjnym wszystkie procesy pielęgnacji obejmują jednak te same zasadnicze czynności: analizę zmiany, planowanie wydania, implementację systemu i przekazanie systemu użytkownikom. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 14

Szkic procesu pielęgnacji Żądana zmiana Analiza wpływu Naprawa usterek ©Ian Sommerville 2000 Planowanie wydania Dostosowanie do platformy Implementacja zmiany Wydanie systemu Rozszerzenie systemu Inżynieria oprogramowania, Rozdział 27 Slide 15

Implementacja zmiany Proponowane zmiany ©Ian Sommerville 2000 Analiza wymagań Aktualizacja wymagań Inżynieria oprogramowania, Rozdział 27 Tworzenie oprogramowania Slide 16

Proces awaryjnej naprawy Żądanie zmian ©Ian Sommerville 2000 Zanalizuj kod źródłowy Zmodyfikuj kod źródłowy Inżynieria oprogramowania, Rozdział 27 Dostarcz zmodyfikowany system Slide 17

Przewidywanie pielęgnacji l Menedżerowie nienawidzą niespodzianek, jeśli ich wynikiem są nieoczekiwanie wysokie koszty. Z ich punktu widzenia warto więc starać się przewidywać, jakie żądania zmian systemu prawdopodobnie się pojawią, które części systemu prawdopodobnie sprawią personelowi pielęgnującemu największe trudności oraz jakie będą całkowite koszty pielęgnacji systemu w ustalonym okresie. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 18

Przewidywanie pielęgnacji Które części systemu będą najdroższe w pielęgnacji? Których części systemu będą najczęściej dotyczyły żądani zmian? Przewidywanie zdatności do pielęgnacji Przewidywanie kosztów zmian systemu pielęgnacji Jakie będą koszty pielęgnacji systemu w następnym roku? Jak dużo spodziewamy się żądań zmian? ©Ian Sommerville 2000 Jaki będzie koszt pielęgnacji systemu w czasie całego jego życia? Inżynieria oprogramowania, Rozdział 27 Slide 19

Ocena związków między systemem, a środowiskiem l l l Liczba i złożoność interfejsów systemu. Im większa jest liczba i złożoność tych interfejsów, tym większe jest prawdopodobieństwo pojawienia się oczekiwań zmian. Liczba z natury płynnych wymagań systemu. Wymagania odzwierciedlające firmowe strategie i procedury są zwykle bardziej zmienne niż wymagania, których podstawą są stabilne właściwości dziedziny. Procesy gospodarcze, w których używa się systemu. W miarę ewolucji procesów gospodarczych powstają żądania zmian systemu. Im bardziej w procesach gospodarczych korzysta się z systemu, tym więcej pojawi się oczekiwań zmiany systemu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 20

Przykłady miar procesowych przy ocenie zdatności do pielęgnacji l l Liczba żądań pielęgnacji korygujących. Jeśli rośnie liczba zgłoszonych awarii, być może w trakcie procesu pielęgnacji liczba nowych błędów wprowadzonych do programu jest większa niż liczba naprawianych błędów. Średni czas niezbędny do wykonania analizy wpływu. Odzwierciedla liczbę komponentów programu, na które oddziałują żądania zmian. Średni czas spędzony nad implementacją żądania zmiany. Czas trwania zmiany zależy od trudności jej zaprogramowania. Liczba oczekujących żądań zmian. Jeśli ta liczba rośnie z czasem, może to oznaczać zmniejszenie zdatności do pielęgnacji. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 21

Ewolucja architektoniczna l l W trakcie pielęgnacji systemu wprowadzone zmiany są lokalne; nie wpływają na architekturę systemu. Od lat osiemdziesiątych XX wieku ekonomia systemów komputerowych zmieniała się jednak radykalnie. Najbardziej opłacalnym rozwiązaniem problemów gospodarczych jest często system rozproszony, a nie scentralizowany. Wiele firm staje więc przed koniecznością przeobrażenia swoich scentralizowanych systemów na komputerach głównych w systemy klient-serwer. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 22

Bodźce, które przyczyniają się do przemiany l l l Koszt sprzętu. Koszt zakupu i utrzymania rozproszonego systemu klient-serwer jest zwykle znacznie mniejszy niż koszt zakupu komputera głównego o takiej samej mocy. Oczekiwania wobec interfejsu użytkownika. Wiele odziedziczonych systemów na komputerach głównych oferuje znakowy interfejs formularzowy. Większość użytkowników oczekuje obecnie interfejsów graficznych i łatwiejszej interakcji z systemem. Rozproszony dostęp do systemu. Firmy coraz bardziej rozpraszają swoje struktury i nie utrzymują wszystkich udogodnień w jednym ośrodku. Ich systemy komputerowe muszą być dostępne z wielu miejsc i za pomocą rozmaitych rodzajów sprzętu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 23

Czynniki wpływające na decyzje o rozproszeniu systemu Czynnik Znaczenie gospodarcze Opis Stopa zwrotu z inwestycji w rozproszenie systemu odziedziczonego zależy od znaczenia dla przedsiębiorstwa i tego, jak długo się ono utrzyma. Jeśli rozproszenie skutecznie wspomaga stabilne procesy gospodarcze, to prawdopodobnie będzie to bardziej opłacalna strategia ewolucyjna. Wiek systemu Im starszy jest system, tym trudniej jest modyfikować jego architekturę, ponieważ wcześniejsze zmiany pogorszyły strukturę systemu. Struktura systemu Im system jest bardziej modularny, tym łatwiej jest zmienić jego architekturę. Jeśli usługi użytkowe, zarządzanie danymi i interfejs użytkownika są w systemie ściśle splecione, to trudno będzie wydzielić funkcje przy przekształceniu. Strategie zaopatrywania się w sprzęt Rozproszenie programu użytkowego może być konieczne, jeśli w firmie przyjęto strategię wymiany drogich komputerów głównych na tańsze serwery. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 24

Idealna i realistyczna struktura systemu odziedziczonego Interfejs użytkownika Usługi Baz danych Model idealny do rozproszenia ©Ian Sommerville 2000 Prawdziwe systemy odziedziczone Inżynieria oprogramowania, Rozdział 27 Slide 25

Rozproszenie systemu odziedziczonego Biurkowe komputery osobiste z uruchomionym programem użytkowym System odziedziczony Usługi użytkowe Warstwa śródprogramowa (osłona) Baza danych Interfejs użytkownika ©Ian Sommerville 2000 System odziedziczony Inżynieria oprogramowania, Rozdział 27 Slide 26

Warstwowy model rozproszenia Prezentacja Zatwierdzanie danych Sterowanie interakcją Usługi użytkowe Baza danych ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 27

Przegląd wariantów rozproszenia Serwer: Sterowanie interakcją Zatwierdzanie danych Usługi Baza danych Klient: Prezentacja Serwer: Usługi Baza danych Serwer: Baza danych Klient: Prezentacja Sterowanie interakcją Sterowanie akcją Zatwierdzanie danych Usługi Rosnące koszt i praca ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 28

Rozproszenie interfejsu użytkownika l l Wiele systemów odziedziczonych zaprojektowano, zanim pojawiły się graficzne interfejsy użytkownika. Takie systemy obejmowały interfejsy formularzowe działające na specjalnych terminalach, które mogły wyświetlać jedynie znaki. Te terminale miały ograniczoną moc obliczeniową i właściwości wyświetlania, a zatem wyświetlanie i wszystkie związane z nim funkcje obliczeniowe były obsługiwane przez centralny system komputera głównego. Nawet po zastąpieniu tych terminali przez komputery osobiste te znakowe interfejsy są nadal w użyciu dzięki programom naśladującym terminale na komputerze osobistym. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 29

Rozproszenie interfejsu użytkownika Opis ekranów Biurkowe komputery osobist z interfejsem graficznym System odziedziczony Usługi użytkowe Baza danych Śródprogram zarządzający ekranami Interfejs użytkownika ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 30

Wady i zalety strategii przenoszenia interfejsu użytkownika Strategia Implementacja z użyciem systemu okienkowego Zalety Dostęp do wszystkich funkcji interfejsu użytkownika, a więc brak ograniczeń przy projekto-waniu interfejsu. Lepsza efektywność interfejsu użytkownika. Wady Zależność od platformy Trudniej osiągnąć spójność interfejsu Implementacja z użyciem przeglądarki WWW Niezależność od platformy Niższe koszty szkolenia dzięki temu, że użytkownicy znają WWW Łatwiej osiągnąć spójność interfejsu Potencjalnie gorsza efektywność Projekt interfejsu jest ograniczony przez właści-wości przeglądarek WWW ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 31

Główne tezy l l Strategie zmieniania oprogramowania obejmują pielęgnację oprogramowania, ewolucję architektoniczną i restrukturyzacje oprogramowania. Okazuje się, że istnieje kilka niezmiennych związków (prawa Lehmana), które maja wpływ na ewolucję systemu oprogramowania. Wywnioskowano je z obserwacji empirycznych. Wynika z nich, że koszty pielęgnacji są nieuniknione. Stanowią porady na temat sposobów zarządzania procesem pielęgnacji. Istnieją trzy zasadnicze rodzaje pielęgnacji oprogramowania. Są to pielęgnacja w celu naprawy usterek oprogramowania, pielęgnacja w celu dostosowania oprogramowania do innego środowiska operacyjnego i pielęgnacja w celu rozszerzenia lub zmodyfikowania funkcjonalności systemu. Koszt zmieniania oprogramowania zwykle przekracza koszt jego budowy. Firmy utrzymują coraz większa liczbę systemów odziedziczonych, a zatem coraz większa część ich budżetu na oprogramowanie jest przeznaczona na pielęgnację systemów odziedziczonych. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 32

Główne tezy l l l Wysokie koszty pielęgnacji wynikają z braku stabilności personelu, z umów na budowę, które nie zachęcają do tworzenia kodu zdatnego do pielęgnacji, z niedostatecznych umiejętności niezbędnych do pielęgnowania systemu i ze struktur oprogramowania, które uległy degradacji ze względu na starzenie się i regularne modyfikacje systemu. Ewolucja architektoniczna polega na modyfikowaniu architektury systemu od scentralizowanej architektury zbudowanej wokół danych do architektury rozproszonej. Można rozproszyć zarówno interfejs użytkownika , jak i funkcjonalność systemu. Często występującą strategią przeobrażania systemów odziedziczonych jest obudowywanie systemu odziedziczonego jako serwera i zaimplementowanie interfejsu użytkownika, który korzysta z funkcjonalności systemu przez specjalnie napisany śródprogram. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 27 Slide 33