Konserwacja oprogramowania

O konserwacji oprogramowania trzeba myśleć już w chwili jego projektowania.

O konserwacji oprogramowania trzeba myśleć już w chwili jego projektowania.

Źadnemu przedsiębiorstwu nie powinno zależeć na opracowaniu dla siebie aplikacji własnymi siłami, gdyż zwykle jest to zadanie nieopłacalne. Najlepszym rozwiązaniem jest jej zakup. Nie oznacza to jednak, że nie będzie żadnych problemów. Wartość aplikacji można ocenić dopiero w chwili, gdy osiągnie stan produkcyjny, tj. zostanie wdrożona i użytkownicy będą jej używać. Ponadto żadna aplikacja nie jest wolna od błędów, zmieniają się wymagania firmy (co powoduje konieczność dodania nowych właściwości funkcjonalnych) i warunki działalności (przepisy prawne, rodzaj działalności), technologia itp.

Jeżeli aplikacja nie będzie zmieniać się zgodnie z tymi uwarunkowaniami, szybko stanie się przestarzała i bezużyteczna. Musi być więc konserwowana, co ma podstawowe znaczenie dla odzyskania zinwestowanych w w nią funduszy; zwykle jest to korzystniejsze niż rozpoczynanie nowego projektu informatycznego w celu zastąpienia starzejącej się aplikacji. Mimo to, konserwacja jest elementem działalności informatycznej w przedsiębiorstwie rzadko docenianym, często niezrozumiałym, a zdarza się, że ignorowanym przez "prawdziwego informatyka".

Co to jest konserwacja?

Najprościej zdefiniować ją można jako dowolną zmianę kodu produkcyjnej aplikacji; nie zaliczymy więc do niej np. strojenia baz danych lub systemu w celu uzyskania większej wydajności ani zmiany systemu plików. Trzeba sobie przy tym uświadomić, że konserwacja i zmiana kodu w trakcie opracowania aplikacji w celu zaadaptowania go do zmienionych warunków, to różne sprawy. Zmiana kodu aplikacji produkcyjnej wpływa na wszystkich jej użytkowników, może spowodować poważne szkody dla przedsiębiorstwa na skutek zatrzymania pracy oraz wymaga ścisłej koordynacji w całej firmie. Nie może bowiem tak się zdarzyć, że część użytkowników już korzysta z nowej wersji, obsługuje klientów, dostawców lub partnerów zgodnie z innymi regułami niż pozostała część firmy.

Jaka konserwacja?

Obserwacja działania dowolnej aplikacji dowodzi istnienia kilku podstawowych rodzajów działań konserwacyjnych:

* poprawianie i usuwanie błędów

*ulepszanie aplikacji przez zastosowanie nowej technologii lub polepszenie parametrów aplikacji (np. wydajności transakcyjnej)

* zmiana właściwości funkcjonalnych aplikacji w celu dostosowania jej do zmienionych warunków działania lub otoczenia.

Łatwo zauważyć, że konserwacja dotyczy dowolnych aplikacji, starych lub nowych, wykonanych na miejscu lub kupionych od niezależnego dostawcy; nie ma znaczenia technologia, w jakiej zostały opracowane, ani język programowania.

Czy można wyeliminować konserwację?

Tak, ale pod warunkiem, że aplikacje będą bezbłędne, nie ulegną zmianie wymagania użytkowników i akceptacja istniejącej technologii w czasie funkcjonowania aplikacji. Są to założenia nierealne, więc nie można bagatelizować sprawy konserwacji aplikacji. Bo jeżeli nie można wyeliminować konserwacji, to trzeba myśleć o zwiększeniu jej efektywności. Przez ponad 40 lat informatycy dopracowali różne narzędzia i metody zwiększające efektywność konserwacji oprogramowania. Nie wszystkie z nich mają nadal zastosowanie w środowisku przetwarzania rozproszonego. Jednak zaniedbanie konserwacji w procesie projektowania i implementacji powoduje poważne konsekwencje w przyszłości.

Myśleć o konserwacji od początku

Niedotrzymywanie terminów wykonania aplikacji, przekraczanie zaplanowanego budżetu i produkowanie aplikacji niezgodnej z zadaną funkcjonalnością sprawia, że nowe aplikacje wymagają modyfikacji już w chwili powstania.

Ponadto takie aplikacje często zawierają tak dużo błędów, że wiele wysiłku trzeba włożyć w ich usunięcie. Najwięcej oszczędności w konserwacji można osiągnąć w zakresie polepszania właściwości funkcjonalnych i ulepszania jej w wyniku zmian technologii.

Stosowanie odpowiednich narzędzi automatyzujących proces konserwacji ma także niebagatelne znaczenie. W miarę komplikacji technicznej aplikacji stosowanie takich narzędzi może okazać się

koniecznością. Konserwacja aplikacji wykonanej dla mainframe'a jest dokonywana w jednym miejscu; sytuacja zmieniła się radykalnie po upowszechnieniu środowiska graficznego i aplikacji klient/serwer.

Trzeba dokonywać zmian w setkach stacji klienta. Zmieni się jeszcze bardziej po upowszechnieniu Internetu i intranetu. Niestety, postępowi w dziedzinie narzędzi do opracowania aplikacji nie towarzyszy odpowiedni rozwój w dziedzinie narzędzi do konserwacji. Większość producentów narzędzi do opracowania aplikacji nie wspomina w ogóle o konserwacji.

Praktyki kodowania

Większość powszechnie stosowanych języków programowania - Cobol, C, Pascal, Basic - zawiera zalecane lub standaryzowane praktyki pisania kodu, ułatwiające późniejszą konserwację kodu. Mimo to, nawet ugruntowany i popularny wśród programistów język, np. C/C++, pozwala na pisanie tak skomplikowanego kodu, że tylko autor jest w nim zorientowany i to krótko po napisaniu programu. Także uczelnie kładą nacisk na dobre praktyki programistyczne, stosowanie właściwego nazewnictwa, dołączanie dokumentacji do każdej części kodu oraz unikanie trików i sztuczek. Utrzymywanie dyscypliny programistycznej w zespole zapobiega tworzeniu tzw. spaghetti-kodu

i zmniejszy w przyszłości obciążenie zespółu związane z konserwacją.

Gorzej jest z innymi językami. Nie istnieją zalecenia w zakresie języka programowania stron HTML ani pisania zapytań SQL do baz danych.

Tylko tradycja i dzielenie się doświadczeniem może wspomóc nowych programistów.

Obiekty i elementy

Coraz częściej wiele aplikacji tworzy się przez składanie ich z gotowych elementów graficznych, obliczeniowych i wizualnych. Biblioteki klas, obiektów i komponentów stają się coraz popularniejsze.

Z punktu widzenia rozszerzania właściwości funkcjonalnych aplikacji dodanie nowych funkcji sprowadza się często do znalezienia nowej biblioteki i skorzystania z jej funkcji.

Niestety, często pojawiają się problemy z uruchamianiem aplikacji, zawierającej funkcje od różnych dostawców. Korzystanie z elementów składowych stwarza problemy, widoczne zbyt często w programach dla Windows.

Zainstalowanie nowego programu, posługującego się dawną wersją biblioteki, umożliwia wprawdzie jego uruchomienie, ale unieruchamia inne programy lub system. W środowisku programistów znane są metody pokonywania tego problemu. Zastosowanie centralnego repozytorium (składnicy) danych o obiektach w systemie i aplikacji pozwala na precyzyjne zarządzanie nimi, unikanie nadmiarowych obiektów o takich samych właściwościach oraz określanie ich zależności. Centralne repozytorium jest także nieocenioną pomocą w procesie konserwacji. Natomiast przeniesienie ścisłej dyscypliny obsługi obiektów do środowiska użytkownika wymaga stosowania jedynie aplikacji przetestowanych i zaakceptowanych przez konserwatora i administratora systemu.

Wersje aplikacji

Nawet niewielkie zespoły programistyczne mają trudności z niezgodnymi ze sobą wersjami aplikacji, powstającymi w trakcie jej testowania i powrotem do wersji już przetestowanych. Zdarza się, że nikt nie wie, która wersja aplikacji jest właściwa i jakie są jej moduły składowe. Ponadto w trakcie usilnych prób odtworzenia jej, usuwa się kluczowe pliki z systemu lub przerabia w sposób niemożliwy do odtworzenia. Jedyna metoda radzenia sobie z tym problemem polega na konsekwentnym stosowaniu narzędzi do kontroli wersji kodu źródłowego, zapobiegających "dzikiemu" modyfikowaniu przetestowanych już modułów i pozwalających na odtworzenie stanu aplikacji na dowolnym etapie jej tworzenia. Takie narzędzia są nadal niezbędne w procesie konserwacji. Przykładem jest pakiet PVCS firmy Intersolv, dostępny także w Polsce.


TOP 200