Konserwacja oprogramowania - Software maintenance
Rozwój oprogramowania |
---|
Konserwacja oprogramowania w inżynierii oprogramowania jest modyfikacja oprogramowania po porodzie w celu skorygowania błędów, do poprawy wydajności lub innych atrybutów.
Powszechnie uważa się, że konserwacja obejmuje jedynie naprawę usterek . Jednak jedno badanie wykazało, że ponad 80% wysiłku konserwacyjnego jest wykorzystywane do działań niekorygujących. Postrzeganie to jest utrwalane przez użytkowników zgłaszających problemy, które w rzeczywistości są ulepszeniami funkcjonalności systemu. Nowsze badania zbliżają odsetek naprawiania błędów do 21%.
Historia
Utrzymaniem oprogramowania i ewolucją systemów po raz pierwszy zajął się Meir M. Lehman w 1969 roku. W ciągu dwudziestu lat jego badania doprowadziły do sformułowania Praw Lehmana (Lehman 1997). Kluczowe wnioski z jego badań wskazują, że konserwacja jest tak naprawdę rozwojem ewolucyjnym, a decyzje dotyczące konserwacji są wspomagane przez zrozumienie, co dzieje się z systemami (i oprogramowaniem) z biegiem czasu. Lehman wykazał, że systemy ewoluują w czasie. W miarę ewolucji stają się bardziej złożone, chyba że zostaną podjęte jakieś działania, takie jak refaktoryzacja kodu , aby zmniejszyć złożoność. Pod koniec lat 70. słynne i szeroko cytowane badanie ankietowe przeprowadzone przez Lientza i Swansona ujawniło bardzo dużą część kosztów cyklu życia, które były wydawane na konserwację.
Badanie wykazało, że około 75% prac konserwacyjnych dotyczyło dwóch pierwszych typów, a korekcja błędów pochłonęła około 21%. Wiele późniejszych badań sugeruje podobną wielkość problemu. Badania pokazują, że wkład użytkowników końcowych jest kluczowy podczas zbierania i analizy nowych danych dotyczących wymagań. Jest to główna przyczyna wszelkich problemów podczas ewolucji i konserwacji oprogramowania. Konserwacja oprogramowania jest ważna, ponieważ pochłania dużą część ogólnych kosztów cyklu życia, a także brak możliwości szybkiej i niezawodnej zmiany oprogramowania oznacza utratę szans biznesowych.
Znaczenie konserwacji oprogramowania
Kluczowe kwestie związane z utrzymaniem oprogramowania mają charakter zarówno zarządczy, jak i techniczny. Kluczowe kwestie zarządcze to: dostosowanie do priorytetów klienta, personel, która organizacja zajmuje się utrzymaniem, szacowanie kosztów. Kluczowe kwestie techniczne to: ograniczone zrozumienie, analiza wpływu , testowanie, pomiar pielęgnowalności.
Utrzymanie oprogramowania to bardzo szerokie działanie, które obejmuje korekcję błędów, ulepszanie możliwości, usuwanie przestarzałych możliwości i optymalizację. Ponieważ zmiana jest nieunikniona, należy opracować mechanizmy oceny, kontroli i wprowadzania modyfikacji.
Tak więc każda praca wykonana w celu zmiany oprogramowania po jego uruchomieniu jest uważana za pracę konserwacyjną. Celem jest zachowanie wartości oprogramowania w czasie. Wartość można zwiększyć poprzez poszerzenie bazy klientów, spełnienie dodatkowych wymagań, stanie się łatwiejsza w obsłudze, wydajniejsza i wykorzystująca nowszą technologię. Utrzymanie może trwać 20 lat, podczas gdy rozwój może trwać od 1 do 2 lat.
Planowanie konserwacji oprogramowania
Integralną częścią oprogramowania jest utrzymanie, które wymaga zbudowania dokładnego planu utrzymania podczas tworzenia oprogramowania. Powinien określać, w jaki sposób użytkownicy będą żądać modyfikacji lub zgłaszać problemy. Budżet powinien zawierać oszacowanie zasobów i kosztów, a opracowanie każdej nowej funkcji systemu i jego cele jakościowe powinny zostać podjęte w celu podjęcia nowej decyzji. Utrzymanie oprogramowania, które może trwać ponad 5 lat (lub nawet dekady) po procesie rozwoju, wymaga skutecznego planu, który może obejmować zakres utrzymania oprogramowania, dostosowanie procesu po dostawie/wdrożeniu, wyznaczenie, kto będzie zapewnić konserwację i oszacować koszty cyklu życia.
Procesy utrzymania oprogramowania
W tej sekcji opisano sześć procesów konserwacji oprogramowania, takich jak:
- Proces wdrożenia obejmuje czynności związane z przygotowaniem i przejściem oprogramowania, takie jak koncepcja i stworzenie planu utrzymania; przygotowanie do rozwiązywania problemów zidentyfikowanych podczas opracowywania; oraz kontynuację zarządzania konfiguracją produktów.
- Proces analizy problemu i modyfikacji, który jest wykonywany, gdy aplikacja stanie się obowiązkiem grupy utrzymania ruchu. Programista utrzymania musi przeanalizować każde żądanie, potwierdzić je (poprzez odtworzenie sytuacji) i sprawdzić jego ważność, zbadać je i zaproponować rozwiązanie, udokumentować żądanie i propozycję rozwiązania, a na koniec uzyskać wszystkie wymagane uprawnienia do zastosowania modyfikacji.
- Proces uwzględniający wdrożenie samej modyfikacji.
- Proces akceptacji modyfikacji, poprzez potwierdzenie zmodyfikowanej pracy z osobą, która złożyła wniosek, w celu upewnienia się, że modyfikacja zapewniła rozwiązanie.
- Proces migracji ( na przykład migracja platformy ) jest wyjątkowy i nie jest częścią codziennych zadań konserwacyjnych. Jeśli oprogramowanie musi zostać przeniesione na inną platformę bez zmiany funkcjonalności, ten proces zostanie wykorzystany i prawdopodobnie do tego zadania zostanie przydzielony zespół projektu konserwacji.
- Wreszcie ostatni proces utrzymania, również wydarzenie, które nie występuje na co dzień, to wycofanie części oprogramowania.
Istnieje wiele procesów, czynności i praktyk, które są unikalne dla opiekunów, na przykład:
- Przejście: kontrolowana i skoordynowana sekwencja czynności, podczas której system jest stopniowo przenoszony od programisty do opiekuna
- Umowy o poziomie usług (SLA) i specjalistyczne (specyficzne dla domeny) umowy serwisowe negocjowane przez opiekunów
- Help Desk wniosków o modyfikację i raportów o problemach: proces obsługi problemów używany przez opiekunów do ustalania priorytetów, dokumentowania i kierowania otrzymywanych żądań
Kategorie konserwacji oprogramowania
EB Swanson początkowo zidentyfikował trzy kategorie konserwacji: naprawczą, adaptacyjną i perfekcyjną. Standard IEEE 1219 został zastąpiony w czerwcu 2010 przez P14764 . Zostały one zaktualizowane, a norma ISO/IEC 14764 przedstawia:
- Konserwacja naprawcza : Reaktywna modyfikacja oprogramowania wykonywana po dostarczeniu w celu skorygowania wykrytych problemów. Konserwacja naprawcza może być zautomatyzowana dzięki automatycznemu naprawianiu błędów .
- Adaptacyjna konserwacja: Modyfikacja produktu oprogramowania przeprowadzana po dostarczeniu w celu utrzymania produktu oprogramowania do użytku w zmienionym lub zmieniającym się środowisku.
- Perfekcyjna konserwacja: Modyfikacja oprogramowania po dostarczeniu w celu poprawy wydajności lub łatwości konserwacji .
- Konserwacja zapobiegawcza : modyfikacja oprogramowania po dostarczeniu w celu wykrycia i skorygowania ukrytych błędów w oprogramowaniu, zanim staną się one błędami skutecznymi.
Istnieje również pojęcie konserwacji przed dostarczeniem/wydaniem, czyli wszystkich dobrych rzeczy, które robisz, aby obniżyć całkowity koszt posiadania oprogramowania. Rzeczy takie jak zgodność ze standardami kodowania, które obejmują cele w zakresie utrzymania oprogramowania. Zarządzanie sprzężeniem i spójnością oprogramowania. Osiągnięcie celów wsparcia oprogramowania (np. SAE JA1004, JA1005 i JA1006). Niektóre instytucje akademickie prowadzą badania w celu ilościowego określenia kosztów bieżącego utrzymania oprogramowania ze względu na brak zasobów, takich jak dokumenty projektowe oraz szkolenia i zasoby w zakresie rozumienia systemu/oprogramowania (pomnożyć koszty przez ok. 1,5-2,0 w przypadku braku danych projektowych) .
Czynniki utrzymania
Wpływ kluczowych czynników dostosowawczych na konserwację (posortowane według maksymalnego pozytywnego wpływu)
Czynniki utrzymania | Plus zakres |
---|---|
Specjaliści ds. utrzymania ruchu | 35% |
Wysokie doświadczenie personelu | 34% |
Zmienne i dane sterowane tabelą | 33% |
Niska złożoność kodu podstawowego | 32% |
Y2K i specjalne wyszukiwarki | 30% |
Narzędzia restrukturyzacji kodu | 29% |
Narzędzia do przeprojektowania | 27% |
Języki programowania wysokiego poziomu | 25% |
Narzędzia inżynierii odwrotnej | 23% |
Narzędzia do analizy złożoności | 20% |
Narzędzia do śledzenia defektów | 20% |
Specjaliści od „masowej aktualizacji” Y2K | 20% |
Zautomatyzowane narzędzia do kontroli zmian | 18% |
Nieopłacone nadgodziny | 18% |
Pomiary jakości | 16% |
Formalne inspekcje kodu bazowego | 15% |
Biblioteki testów regresji | 15% |
Doskonały czas reakcji | 12% |
Szkolenie roczne > 10 dni | 12% |
Wysokie doświadczenie w zarządzaniu | 12% |
POMOC automatyka biurka | 12% |
Brak modułów podatnych na błędy | 10% |
Zgłaszanie usterek on-line | 10% |
Pomiary produktywności | 8% |
Doskonała łatwość użytkowania | 7% |
Pomiary satysfakcji użytkowników | 5% |
Wysokie morale zespołu | 5% |
Suma | 503% |
Nie tylko moduły podatne na błędy są kłopotliwe, ale wiele innych czynników może również obniżyć wydajność. Na przykład bardzo złożony kod spaghetti jest dość trudny do bezpiecznego utrzymania. Bardzo powszechną sytuacją, która często obniża wydajność, jest brak odpowiednich narzędzi konserwacyjnych, takich jak oprogramowanie do śledzenia defektów, oprogramowanie do zarządzania zmianami i oprogramowanie biblioteki testów. Poniżej opisz niektóre czynniki i zakres wpływu na utrzymanie oprogramowania.
Wpływ kluczowych czynników dostosowawczych na konserwację (posortowane według maksymalnego negatywnego wpływu)
Czynniki utrzymania | Zakres minus |
---|---|
Moduły podatne na błędy | -50% |
Osadzone zmienne i dane | -45% |
Brak doświadczenia personelu | -40% |
Wysoka złożoność kodu | -30% |
Nie ma 2000 specjalnych wyszukiwarek | -28% |
Ręczne metody kontroli zmian | -27% |
Języki programowania niskiego poziomu | -25% |
Brak narzędzi do śledzenia defektów | -24% |
Brak specjalistów od „masowej aktualizacji” Y2K | -22% |
Słaba łatwość użytkowania | -18% |
Brak pomiarów jakości | -18% |
Brak specjalistów od konserwacji | -18% |
Słaby czas odpowiedzi | -16% |
Brak kontroli kodu | -15% |
Brak bibliotek testowych regresji | -15% |
Brak automatyzacji pomocy technicznej | -15% |
Brak zgłaszania usterek on-line | -12% |
Brak doświadczenia w zarządzaniu | -15% |
Brak narzędzi do restrukturyzacji kodu | -10% |
Brak corocznych szkoleń | -10% |
Brak narzędzi do przeprojektowania | -10% |
Brak narzędzi do inżynierii wstecznej | -10% |
Brak narzędzi do analizy złożoności | -10% |
Brak pomiarów produktywności | -7% |
Słabe morale zespołu | -6% |
Brak pomiarów satysfakcji użytkownika | -4% |
Brak niepłatnych nadgodzin | 0% |
Suma | -500% |
Dług alimentacyjny
W referacie na 27. Międzynarodową Konferencję Zarządzania Jakością Oprogramowania w 2019 r. John Estdale wprowadził termin „dług serwisowy” dla potrzeb konserwacyjnych generowanych przez zależność wdrożenia od zewnętrznych czynników IT, takich jak biblioteki, platformy i narzędzia, które stały się przestarzałe. Aplikacja nadal działa, a dział IT zapomina o tej teoretycznej odpowiedzialności, skupiając się na pilniejszych wymaganiach i problemach gdzie indziej. Taki dług narasta z czasem, po cichu pochłaniając wartość zasobu oprogramowania. W końcu dzieje się coś, co sprawia, że zmiana systemu jest nieunikniona.
Właściciel może wtedy odkryć, że systemu nie można już modyfikować – jest dosłownie nie do utrzymania. Mniej dramatycznie, konserwacja może zająć zbyt dużo czasu lub kosztować zbyt wiele, aby rozwiązać problem biznesowy i należy znaleźć alternatywne rozwiązanie. Oprogramowanie nagle uległo awarii do wartości 0 GBP.
Estdale definiuje „dług serwisowy” jako: lukę między obecnym stanem wdrożenia aplikacji a stanem idealnym, przy wykorzystaniu wyłącznie funkcjonalności komponentów zewnętrznych, które są w pełni utrzymywane i wspierane. Ten dług jest często ukryty lub nierozpoznany. Ogólna łatwość utrzymania aplikacji zależy od ciągłej dostępności wszelkiego rodzaju komponentów od innych dostawców, w tym:
- Narzędzia programistyczne: edycja źródeł, zarządzanie konfiguracją, kompilacja i kompilacja
- Narzędzia testowe: wybór testów, wykonanie/weryfikacja/raportowanie
- Platformy do realizacji powyższych: sprzęt, system operacyjny i inne usługi
- Środowisko produkcyjne i wszelkie udogodnienia w trybie gotowości/odzyskiwania po awarii, w tym środowisko uruchomieniowe w języku kodu źródłowego, a także szerszy ekosystem planowania zadań, przesyłania plików, replikowanej pamięci masowej, tworzenia kopii zapasowych i archiwizacji, jednokrotnego logowania itp.
- Pozyskiwane osobno pakiety, np. DBMS, grafika, komunikacja, oprogramowanie pośredniczące
- Kupiony w kodzie źródłowym, bibliotekach kodów obiektowych i innych usługach nieodwołalnych
- Wszelkie wymagania wynikające z innych aplikacji współdzielących środowisko produkcyjne lub współpracujących z daną aplikacją
i oczywiście
- Dostępność odpowiednich umiejętności w firmie lub na rynku.
Całkowite zniknięcie komponentu może sprawić, że aplikacja nie będzie możliwa do odbudowania lub wkrótce stanie się niemożliwa do utrzymania.
Zobacz też
- Wycofanie aplikacji
- Journal of Software Maintenance and Evolution: Research and Practice
- Długoterminowa pomoc
- Inżynieria oprogramowania oparta na wyszukiwaniu
- Archeologia oprogramowania
- Opiekun oprogramowania
- Rozwój oprogramowania
Bibliografia
Dalsza lektura
- ISO/IEC 14764 IEEE Std 14764-2006 Inżynieria oprogramowania — Procesy cyklu życia oprogramowania — Konserwacja . 2006. doi : 10.1109/IEEESTD.2006.235774 . Numer ISBN 0-7381-4960-8.
- Pigoski, Tomasz M. (1996). Praktyczna konserwacja oprogramowania . Nowy Jork: John Wiley i synowie. Numer ISBN 978-0-471-17001-3.
- Pigoski, Thomas M. Opis ewolucji i konserwacji oprogramowania (wersja 0.5) . Obszar wiedzy SWEBOK.
- kwiecień, Alain; Abran, Alain (2008). Zarządzanie konserwacją oprogramowania . Nowy Jork: Wiley-IEEE. Numer ISBN 978-0-470-14707-8.
- Gopalaswamy Ramesh; Ramesz Bhattiprolu (2006). Konserwacja oprogramowania: efektywne praktyki dla środowisk rozproszonych geograficznie . Nowe Delhi: Tata McGraw-Hill. Numer ISBN 978-0-07-048345-3.
- Grubb, Penny; Takang, Armstrong (2003). Konserwacja oprogramowania . New Jersey: World Scientific Publishing. Numer ISBN 978-981-238-425-6.
- Lehman, MM; Belady, LA (1985). Ewolucja programu: procesy zmiany oprogramowania . Londyn: Academic Press Inc. ISBN 0-12-442441-4.
- Page-Jones, Meilir (1980). Praktyczny przewodnik po projektowaniu systemów strukturalnych . Nowy Jork: Yourdon Press. Numer ISBN 0-917072-17-0.