DEKOMPOZYCJA ATRYBUTU ŁATWOŚĆ KONSERWACJI PRODUKTU PROGRAMOWEGO

Transkrypt

1 DEKOMPOZYCJA ATRYBUTU ŁATWOŚĆ KONSERWACJI PRODUKTU PROGRAMOWEGO Andrzej Kobyliński Wprowadzenie W procesie wytwórczym dedykowanego produktu programowego, kiedy po przejściu testów akceptacyjnych oprogramowanie trafia do klienta, albo w przypadku produktu sprzedawanego na skalę masową po przejściu testów beta, produkt wprowadzany jest do dystrybucji, dla twórców oprogramowania rozpoczyna się etap konserwacji (pielęgnacji, utrzymania, ang. maintenance). Wszystkie zmiany dokonane od tej pory w produkcie programowym 1 zaliczają się do działań konserwacyjnych. Powszechnie uwaŝa się, Ŝe istnieją trzy zasadnicze powody dokonywania zmian w oprogramowaniu, po oddaniu go do uŝytku: naprawa błędów (konserwacja korekcyjna), doskonalenie produktu, wykonywane w celu zwiększenia funkcjonalności, wydajności, łatwości uŝycia lub innych atrybutów jakości oprogramowania (konserwacja doskonaląca), dostosowanie oprogramowania do zmieniających się warunków zewnętrznych: zarówno prawnych i organizacyjnych, jak i technicznych (konserwacja adaptacyjna). Znamienne jest, Ŝe brakuje nowych danych dotyczących proporcji prac związanych z róŝnymi rodzajami konserwacji. Praktycznie wszyscy autorzy poruszający tematykę konserwacji oprogramowania powołują się na stare badanie, dokonane jeszcze w 1978 r. przez Lientza, Swansona i Tompkinsa [LST78], [Lo- Sw80]. Na przykład na rezultaty tego przeglądu powołują się autorzy najpopularniejszych podręczników z inŝynierii oprogramowania: Sommerville [Somm03, s. 606], Pressman [Pres01, s. 805], Schach [Scha93, s. 10]. Rezultaty wzmiankowanego badania przedstawia rys Zgodnie z normą [ISO2382] na produkt programowy, oprócz oprogramowania, składają się równieŝ procedury, dokumentacja i dane przekazywane uŝytkownikowi. 467

2 ROZDZIAŁ V konserwacja adaptacyjna 18% inna 4% konserwacja korekcyjna 17% konserwacja doskonaląca 61% Rys. 1. Podział pracy przy konserwacji Źródło: opracowanie na podstawie [LST78] Pozostałe, nie opisane na wykresie 4% działań związanych z konserwacją, moŝna zakwalifikować do prac innego rodzaju, np. konserwacji prewencyjnej dokonywanej po to, by z wyprzedzeniem zapobiec moŝliwości wystąpienia błędu w systemie. Po upływie dekady, zbliŝone wyniki uzyskali w swoich badaniach Nosek i Palvia [NoPa90]. 2 O tym, jak łatwo moŝna zmienić oprogramowanie, decyduje atrybut jakości oprogramowania, zwany łatwością konserwacji. Definiuje się go następująco: Łatwość konserwacji (ang. maintainability) cecha oprogramowania odzwierciedlająca to, jak łatwo jest dokonywać w oprogramowaniu róŝnego rodzaju modyfikacji (szybko i tanim kosztem). Ten atrybut oprogramowania, choć nieistotny i niedostrzegalny dla przeciętnego uŝytkownika, ma kluczowe znaczenie dla producentów, a szczególnie programistów konserwujących i przenoszących oprogramowanie na inną platformę sprzętową lub systemową. Łatwość dokonywania w oprogramowaniu zmian róŝnego typu, jest tak waŝna ze względu na fakt, Ŝe przeciętnie firmy informatyczne 2/3 swojego budŝetu przeznaczają na konserwację oprogramowania, a tylko 1/3 na rozwój nowych produktów [Scha93, s. 8-12]. 2 Wyniki badania [LST78] dopiero ostatnio zostały skrytykowane przez S. Schacha [Scha04], który w swoich badaniach, oprócz innych ciekawych obserwacji, doszedł do wniosku, Ŝe konserwacja korekcyjna pochłania ponad 50% nakładów, doskonaląca niespełna 40%, a adaptacyjna poniŝej 5%. 468

3 REALIZACJA SYSTEMÓW WSPOMAGANIA ORGANIZACJI I ROZWIĄZANIA... Model atrybutu łatwość konserwacji oprogramowania Atrybut łatwości konserwacji oprogramowania jest wyjątkowo ogólny, a przez to trudny do oceny. W podobnych przypadkach, powszechnie stosowaną metodą jest opisanie takiej trudnej do zdefiniowania kategorii przy pomocy innych, bardziej konkretnych, lepiej zdefiniowanych i łatwiejszych przez to do oceny, a nawet pomiaru, atrybutów szczegółowych. PoniŜej zaprezentowana została autorska dekompozycja omawianego atrybutu na atrybuty niŝszych poziomów. Dokonując kolejnych logicznych podziałów, wynikających z przesłanek merytorycznych, uzyskany został rozbudowany model atrybutu łatwości konserwacji. NaleŜy teŝ w tym miejscu podkreślić, Ŝe w związku z niejednolitością terminologii, a miejscami nawet zupełnym brakiem odpowiedniej nomenklatury, autor zmuszony został do zaproponowania własnego nazewnictwa. Naprawialność Po oddaniu oprogramowania do uŝytku, praktycznie zawsze pozostają w nim błędy, nie zauwaŝone na etapie rozwoju. Niekiedy producenci, przynaglani przez nieprzekraczalne terminy zakończenia prac, świadomie oddają do uŝytku niedopracowane oprogramowanie (ang. good enough software) [Koby03]. Prace związane z eliminacją błędów z ukończonego i oddanego juŝ do uŝytku oprogramowania, składają się na konserwację korekcyjną. Celem konserwacji korekcyjnej jest zatem doprowadzenie do sytuacji, Ŝe oprogramowanie staje się zgodne ze swą specyfikacją. śadna bowiem specyfikacja, nigdy nie zakłada, Ŝe oprogramowanie powinno posiadać błędy. Cechę oprogramowania, która decyduje o tym, jak łatwo jest eliminować błędy z oprogramowania proponuje się nazwać naprawialnością. Naprawialność (ang. correctability) cecha oprogramowania obrazująca łatwość usuwania błędów w oprogramowaniu. Elastyczność W przeciwieństwie do omówionej konserwacji korekcyjnej, pozostałe dwa rodzaje konserwacji: doskonaląca i adaptacyjna, pociągają za sobą modyfikację specyfikacji oprogramowania. NiezaleŜnie od tego, czy trzeba rozbudować oprogramowanie, włączając doń dodatkowe funkcje, czy wymienić algorytmy przetwarzania na wydajniejsze, czy zwiększyć łatwość obsługi, czy dostosować oprogramowanie do zmieniających się warunków otoczenia, np. zmian w prawie, czy teŝ przystosować do działania na innej platformie sprzętowej lub w innym środowisku systemowym wszystkie tego rodzaju zmiany wymagają przeróbki specyfikacji oprogramowania. Jak wynika z rys. 1, spośród ogólnych 469

4 ROZDZIAŁ V nakładów na konserwację, zmiany pociągające za sobą modyfikację specyfikacji pochłaniają ok. 80% ogółu kosztów konserwacji. To, jak łatwo jest dokonywać zmian, polegających na doskonaleniu i adaptacji, proponuje się nazwać elastycznością oprogramowania. Elastyczność (ang. flexibility) cecha oprogramowania świadcząca o łatwości dokonywania zmian w oprogramowaniu, wymagających zmiany pierwotnej specyfikacji. Naprawialność Łatwość konserwacji Rys. 2. Łatwość konserwacji (opr. wł.) Elastyczność W dalszej części rozdziału omówiona została dekompozycja atrybutu elastyczność. Rozszerzalność Średni czas Ŝycia duŝego systemu mieści się w przedziale 5-15 lat [Four91, s. 325], chociaŝ przykładowo w Departamencie Obrony USA wykorzystywanych jest wiele systemów, których czas eksploatacji wynosi od 30 do 50 lat [Ober98, s. 6]. Aby pozostać na rynku w tak długim okresie, firma musi uzupełniać (rozszerzać) oprogramowanie o dodatkowe funkcje, wprowadzone juŝ w międzyczasie przez konkurencję do innych, podobnych produktów. Atrybut oprogramowania, który świadczy o łatwości rozbudowy oprogramowania, proponuje się nazwać rozszerzalnością. Rozszerzalność (ang. expandability, augmentability, extensibility) cecha oprogramowania decydująca o łatwości dokonywania w oprogramowaniu rozszerzeń funkcjonalności. Adaptacyjność PoniewaŜ czas Ŝycia oprogramowania jest stosunkowo długi, uŝytkownicy często domagają się przeprowadzenia w nim zmian, polegających na: dostosowaniu oprogramowania do zmieniających się warunków zewnętrznych (np. prawnych) lub zwiększeniu wydajności oprogramowania - ten rodzaj dostosowywania będzie nazwany modyfikowalnością (patrz modyfikowalność) dostosowaniu do nowego środowiska oprogramowania: nowej wersji systemu operacyjnego, innego sprzętu (procesora, urządzeń wejścia/wyjścia) ten rodzaj adaptacji zyskał nazwę przenośności (patrz przenośność). 470

5 REALIZACJA SYSTEMÓW WSPOMAGANIA ORGANIZACJI I ROZWIĄZANIA... Adaptacyjność (ang. adaptability) cecha oprogramowania decydująca o łatwości dokonywania w oprogramowaniu zmian dostosowawczych do warunków zewnętrznych, sprzętu i oprogramowania systemowego. Elastyczność Rozszerzalność Rys. 3. Elastyczność (opr. wł.) Adaptacyjność W kolejnych podpunktach omówiona została dekompozycja atrybutu adaptacyjność. Modyfikowalność (ang. modifiability) cecha oprogramowania obrazująca łatwość dokonywania zmian w oprogramowaniu, polegających na dostosowaniu go do zmieniającego się otoczenia organizacji (np. warunków prawnych) lub zaimplementowania nowych, sprawniejszych algorytmów. Przenośność (ang. portability) cecha oprogramowania odzwierciedlająca łatwość dokonywania zmian w oprogramowaniu tak, by mogło ono pracować w róŝnych środowiskach. Pod pojęciem środowiska rozumiany jest sprzęt, oprogramowanie systemowe oraz kombinacja obu wymienionych składników. O ile wszystkie inne rozwaŝane do tej pory atrybuty jakości miały szczególne znaczenie dla programistów konserwujących, o tyle przenośność istotna jest dla programisty, którego zadaniem jest powiększanie potencjalnego kręgu odbiorców, poprzez dostosowanie oprogramowania do pracy w innym środowisku. Oprogramowanie jest łatwo przenośne, jeśli wszystkie załoŝenia dotyczące konkretnego środowiska są skupione w jednym miejscu (komponencie, procedurze), a przeniesienie produktu do innego środowiska wymaga wyłącznie wymiany tego elementu. Tę hermetyzację osiąga się w ten sposób, Ŝe tworzy się dodatkową warstwę pośrednią oddzielającą oprogramowanie aplikacyjne od sprzętu i oprogramowania systemowego (nosi ona angielską nazwę portability leyer). Warstwa ta daje aplikacji pewien abstrakcyjny interfejs do sprzętu i oprogramowania systemowego. JeŜeli zmieni się sprzęt i oprogramowanie systemowe, aplikacja moŝe pozostać bez zmiany, wystarczy wymienić na właściwą wspomnianą warstwę pośrednią. Sama aplikacja nie komunikuje się wprost ze środowiskiem, a wyłącznie z warstwą pośrednią [BCK98, s. 83]. 471

6 ROZDZIAŁ V Modyfikowalność Adaptacyjność Rys. 4. Adaptacyjność (opr. wł.) Przenośność ZaleŜności między opisanymi atrybutami podrzędnymi, składającymi się na łatwość konserwacji, przedstawia rys. 5. Naprawialność Łatwość konserwacji Rozszerzalność Elastyczność Modyfikowalność Adaptacyjność Rys. 5. Model atrybutu łatwość konserwacji (opr. wł.) Przenośność Główne atrybuty jakości wg normy ISO/IEC 9126 Norma dotycząca jakości oprogramowania ISO/IEC 9126 [ISO9126] wyszczególnia sześć podstawowych atrybutów jakościowych: funkcjonalność, uŝyteczność, niezawodność, wydajność, łatwość konserwacji, przenośność. O ile cztery pierwsze odnoszą się do jakości widzianej oczami klienta/uŝytkownika, to dwie ostatnie mają znaczenie wyłącznie dla programistów konserwujących, których zadaniem jest dalsza praca nad programem, juŝ po oddaniu go do uŝytku. Wzmiankowana norma definiuje te cechy następująco: Łatwość konserwacji: łatwość w modyfikowaniu oprogramowania. Modyfikacje mogą dotyczyć poprawy, doskonalenia lub adaptacji oprogramowania 472

7 REALIZACJA SYSTEMÓW WSPOMAGANIA ORGANIZACJI I ROZWIĄZANIA... do zmian w otoczeniu, w wymaganiach oraz w specyfikacjach funkcjonalnych [ISO9126, s. 10]. Przenośność: łatwość w dokonywaniu transferu oprogramowania z jednego środowiska do innego [ISO9126, s. 11]. W kontekście rozwaŝań dokonanych w poprzednim rozdziale, umieszczenie w modelu jakości ISO 9126 łatwości konserwacji i przenośności na tym samym poziomie hierarchii atrybutów jakościowych produktu programowego jest niesłuszne. Przenośność jest bowiem atrybutem podrzędnym w stosunku do łatwości konserwacji i obejmuje tylko pewien niewielki (i stosunkowo mało kosztowny) wycinek działań składających się na konserwację. WyróŜnienie tego właśnie atrybutu szczegółowego przez umieszczenie go na równym poziomie z innymi pięcioma głównymi atrybutami jakości jest zatem nieuzasadnione. Podsumowanie W opracowaniu przedstawiono autorski model jednego z podstawowych atrybutów jakości oprogramowania: łatwości konserwacji. Uzasadniono budowę tego hierarchicznego modelu. W związku z nieporządkiem terminologicznym, zaproponowano ujednoliconą nomenklaturę atrybutów jakości. Uzasadniono, dlaczego umieszczenie łatwości konserwacji i przenośności oprogramowania na tym samym poziomie atrybutów jakościowych w modelu ISO/IEC 9126 jest niewłaściwe. Wszystkie wyróŝnione w modelu łatwości konserwacji atrybuty podrzędne mają charakter zewnętrzny wynikają z logicznych rozwaŝań, ale nie mają wprost swego odbicia w kodzie oprogramowania. Dlatego dalsze badania będą koncentrowały się na znalezieniu przełoŝenia między opisanymi w pracy atrybutami zewnętrznymi a atrybutami wewnętrznymi kodu oprogramowania (takimi jak np. modularność, czytelność, prostota, jednolitość itp.). Literatura [BCK98] Bass L., Clements P., Kazman R.: Software Architecture in Practice, Addison-Wesley [Four91] Fournier R.: Practical Guide to Structured System Development and Maintenance, Prentice-Hall, Englewood Cliffs [ISO2382] PN-88/T-01016/01 Przetwarzanie informacji i komputery. Terminologia. Podstawowe terminy i definicje (polskie tłumaczenie normy: ISO :1984, Data processing - Vocabulary - Part 01: Fundamental terms) [ISO9126] ISO/IEC :2001: Software engineering - Product quality - Part 1: Quality model. 473

8 ROZDZIAŁ V [Koby03] [LST78] [LoSw80] [NoPa90] [Ober98] [Pres01] [Scha93] [Scha04] [Somm03] Kobyliński A.: Koncepcja dostatecznie dobrej jakości w praktyce wytwarzania oprogramowania, w: Nowoczesne technologie informacyjne w zarządzaniu, red. E. Niedzielska, H. Dudycz, M. Dyczkowski, Prace Naukowe Akademii Ekonomicznej we Wrocławiu, nr 986, Wyd. AE we Wrocławiu, Wrocław 2003, str Lientz B. P., Swanson E. B., Tompkins G. E.: Characteristics of Applications Software Maintenance, Communications of the ACM, 21(6), p , Lientz B. P., Swanson E. B.: Software Maintenance Management, Addison-Wesley, Reading (MA) Nosek J. T., Palvia P.: Software maintenance management: changes in the last decade, Software Maintenance: Research and Practice, 2(3), p , Oberndorf P.: COTS and Open Systems, SEI Monographs on the Use of Commercial Software in Government Systems, 1998, Pressman R. S.: Software Engineering. A Practitioner s Approach, 5th Ed., McGraw-Hill, New York Schach S.: Software Engineering, 2nd Ed., Aksen & Irwin, Homewood & Boston Schach S.: Three Unexpected Results in Empirical Open-Source Software Engineering ( ), Sommerville I.: InŜynieria oprogramowania, WNT, Warszawa