Modernizacja oprogramowania

Kiedy ta usługa pomaga

Modernizacja oprogramowania: co mogą nam Państwo zlecić.

Zastępowanie wycofanych technologii
Przywracanie przewidywalności zmian
Zabezpieczanie wiedzy zgromadzonej w aplikacjach rozwijanych przez lata

Aplikacje, które działają od lat, ale opierają się na przestarzałych frameworkach, modernizujemy stopniowo, w ramach zaplanowanej zmiany. Po inwentaryzacji kodu, zależności i przepływów danych wybieramy dla każdej aplikacji odpowiednią drogę: replatforming do kontenerów, refaktoryzację na moduły, migrację danych do nowego modelu lub zastąpienie aplikacją następczą. Stare i nowe elementy działają równolegle, dopóki nie zostanie przeniesiony ostatni proces.

Co może wchodzić w zakres zlecenia

Inwentaryzacja obejmująca analizę kodu, listę zależności, przepływy danych i koszty eksploatacji dla każdej aplikacji
Ocena pod kątem korzyści biznesowych i ryzyka, decyzja między replatformingiem, refaktoryzacją a zastąpieniem
Testy charakteryzujące dla istniejącego kodu, zanim zostanie zmieniona pierwsza linia
Stopniowa dekompozycja metodą Strangler Pattern, równoległa eksploatacja starych i nowych elementów
Migracja danych z uzgadnianiem, próbnym przebiegiem i udokumentowanym planem powrotu do poprzedniego stanu

Konkretny zakres, odbiory i zaangażowanie Państwa strony ustalamy w ofercie.

Powiązania na pierwszy rzut oka

Zrozumieć istniejący system. Opanować zmianę.

01
Rozpoznanie
Uwidocznienie logiki biznesowej i zależności
02
Zabezpieczenie
Porównywalne testy dotychczasowego działania systemu
03
Przełączenie
Kontrola wiodącego źródła danych i przełączenia
04
Wycofanie
Uporządkowane wyłączenie starych komponentów

Planowanie, realizacja i decyzje

Modernizacja oprogramowania: co jest najważniejsze.

01

Zrozumienie przed zastąpieniem

W kodzie źródłowym często kryją się reguły biznesowe, których żaden dokument w pełni nie opisuje. Dlatego łączymy analizę kodu i zależności z rozmowami w dziale biznesowym oraz obserwacją rzeczywistych procesów. Powtarzające się zakłócenia, ręczne poprawki i przypadki szczególne pokazują, gdzie leżą faktyczne ryzyka. Uwzględniamy również źródła danych, zadania działające w tle i zewnętrzne systemy wywołujące.

Testy charakteryzujące dokumentują, jak aplikacja działa obecnie. Nie każde istniejące zachowanie jest prawidłowe; błędy merytoryczne są wyraźnie oddzielane od funkcji, które muszą zostać zachowane. Powstaje w ten sposób solidna podstawa do porównania systemu starego z nowym.

02

Odnowa w kontrolowanych krokach

Przeniesienie na nową platformę nie rozwiązuje automatycznie problemów w kodzie aplikacji. Dlatego rozróżniamy zmiany w środowisku uruchomieniowym i eksploatacji, przebudowę poszczególnych modułów oraz pełne zastąpienie. Tam, gdzie ma to sens, nowy komponent stopniowo przejmuje zadania od systemu istniejącego. Eksploatacja równoległa to zaplanowana faza przejściowa z jasno określoną odpowiedzialnością za dane.

Każdy krok otrzymuje cel, zakres testów i kryteria decyzji o powrocie do poprzedniego stanu. Okna serwisowe i możliwe przerwy planujemy wspólnie; pracy bez przerw nie obiecujemy z góry. Kolejny element zostaje przełączony dopiero wtedy, gdy dostępny jest dowód dla danego procesu.

03

Migracja danych i kontrolowane wycofanie z eksploatacji

Dane historyczne zawierają duplikaty, brakujące wartości i reguły pochodzące z wcześniejszych wersji. Przed migracją produkcyjną definiujemy mapowanie, oczyszczanie i uzgadnianie danych. Próbne przebiegi pokazują, czy czasy wykonania, ilości danych i wyjątki są możliwe do opanowania. Szczególnie istotne sumy, powiązania i próbki danych są sprawdzane merytorycznie.

Przed wyłączeniem systemu muszą być wyjaśnione również eksporty, przechowywanie danych, zapytania dotyczące dawnych spraw oraz systemy zależne. Dokumentujemy, które dane pozostają dostępne i gdzie, a także kiedy powrót do poprzedniego stanu nie jest już możliwy. Do przekazania należy nowa dokumentacja eksploatacyjna, a także sposób postępowania z systemem wycofanym z eksploatacji.

Dla osób odpowiedzialnych merytorycznie i zespołów technicznych

Decyzje stojące za realizacją.

04

Zabezpieczenie zachowania biznesowego zamiast ślepego przenoszenia starego kodu

W systemach rozwijanych przez lata kod często wyjaśnia tylko część procesu. Niezbędne zadania mogły przejąć eksporty do arkuszy, ręczne poprawki danych i zadania uruchamiane cyklicznie. Rejestrujemy te dodatkowe ścieżki i tworzymy katalog charakterystycznych przypadków: przypadki standardowe, historyczne wyjątki, wartości graniczne i znane błędy. Przebieg porównawczy między systemem starym a nowym ujawnia rozbieżności, ale sam w sobie nie rozstrzyga, który wynik jest poprawny merytorycznie.

Dział biznesowy ocenia różnice wspólnie z zespołem programistycznym. Zaokrąglanie, strefy czasowe, kolejność sortowania czy historyczne reguły cenowe mogą powodować pozornie niewielkie rozbieżności o dużym znaczeniu. Zamierzone zmiany zachowania są oddzielane od niezamierzonych regresji. Dopiero w ten sposób powstaje sensowna podstawa odbioru. Udokumentowane przypadki służą później jako trwała siatka bezpieczeństwa dla kolejnych przebudów i utrwalają wiedzę, którą dotychczas dysponowały tylko pojedyncze osoby.

05

System wiodący dla danych w eksploatacji równoległej i planowanie przełączenia

Dopóki stare i nowe komponenty współpracują ze sobą, odpowiedzialność za zapis danych nie może być niejasna. Dla każdego obszaru danych wyznaczamy system wiodący i planujemy przekazanie tej odpowiedzialności. Dwie aplikacje zapisujące dane bez wzajemnej koordynacji mogą wytworzyć sprzeczne stany, nawet jeśli każda z nich działa poprawnie. Architektura przejściowa potrzebuje więc własnych interfejsów, mechanizmów uzgadniania danych i ograniczonego czasu istnienia.

Plan migracji obejmuje pierwszą migrację danych, zmiany w okresie przejściowym i ostateczne uzgodnienie. Sprawdzamy liczbę rekordów, sumy merytoryczne, powiązania oraz reprezentatywne przypadki jednostkowe. Przed przełączeniem ustalamy kryteria przerwania, uprawnienia decyzyjne i dopuszczalne przerwy w zapisie. Powrót do poprzedniego stanu jest realistyczny tylko wtedy, gdy nowo powstałe dane można ponownie przetworzyć. Tam, gdzie nie jest to możliwe, przed zatwierdzeniem określamy moment i konsekwencje tego ograniczenia.

06

Techniczne rozdzielenie systemów i zakończenie zastępowania

Nowy interfejs nałożony na niezmienioną starą architekturę nie usuwa automatycznie jej ograniczeń. Analizujemy współdzielone tabele, niejawne formaty plików, bezpośredni dostęp do bazy danych oraz biblioteki wiążące jednocześnie kilka aplikacji. Wprowadzane stopniowo adaptery mogą przechwytywać zmiany. Są one jednak komponentami przejściowymi wymagającymi własnego utrzymania i nie powinny niepostrzeżenie stać się trwałym drugim środowiskiem systemowym.

Dlatego dla każdej zastąpionej funkcji istnieje również zadanie związane z jej wycofaniem. Stare zadania cykliczne, konta użytkowników, interfejsy, infrastruktura i licencje są sprawdzane pod kątem dalszego wykorzystania. Zapytania o dane historyczne mogą wymagać dostępu tylko do odczytu lub udokumentowanego eksportu. Modernizacja tego etapu jest zakończona dopiero wtedy, gdy zależności zostały rozwiązane, dokumentacja eksploatacyjna zaktualizowana, a odpowiedzialność przekazana. Zapobiega to trwałemu sumowaniu się kosztów starego i nowego systemu.

Przejrzyste rezultaty prac

Co trafia w Państwa ręce.

Rezultat 01

Oceniony portfel aplikacji ze ścieżką modernizacji dla każdej aplikacji

Rezultat 02

Zmodernizowana aplikacja z pokryciem testami i obrazami kontenerów

Rezultat 03

Protokół migracji z uzgodnieniem danych i planem powrotu do poprzedniego stanu

Przykładowy przebieg projektu

Tak może wyglądać realizacja.

System rozliczeniowy działa w środowisku uruchomieniowym, które nie jest już wspierane. Najpierw obliczenia są zabezpieczane za pomocą testów porównawczych. Następnie przychodzi kolej na wydzielony moduł; migracja danych jest wielokrotnie testowana, zanim zostanie zatwierdzone produkcyjne przełączenie.

Scenariusz poglądowy, nie referencja klienta ani gwarancja rezultatu.

To ułatwia start

Kod źródłowy i działające środowisko testowe, o ile istnieją
Znane błędy, zależności i krytyczne terminy
Merytoryczne przypadki testowe i osoby kontaktowe ds. reguł historycznych

Brak dokumentów nie wyklucza rozpoczęcia współpracy. Wspólnie ustalamy, jakie informacje należy pozyskać w pierwszej kolejności.

Państwa przedsięwzięcie w szczegółach

Modernizacja bez przerywania bieżącej działalności.

Planujemy odnowę istniejących aplikacji z uwzględnieniem ich znaczenia biznesowego. Zakres prac może obejmować zarówno ukierunkowaną modernizację techniczną, jak i stopniową wymianę poszczególnych funkcji.

Utrwalenie dotychczasowego zachowania systemu przed wprowadzeniem zmian

Sama dokumentacja rzadko opisuje wszystkie reguły aplikacji używanej od wielu lat. Wspólnie z Państwa użytkownikami zbieramy reprezentatywne procesy, wyjątki i znane błędy. Odpowiednio dobrane testy porównawcze utrwalają, które zachowania muszą pozostać bez zmian, a które odstępstwa należy świadomie skorygować.

Techniczna inwentaryzacja jest łączona z priorytetyzacją biznesową. Przestarzałe biblioteki, trudne do zmiany moduły i częste zakłócenia w eksploatacji mają różne skutki. Punkt startowy wybieramy tam, gdzie korzyść, ryzyko i zależności pozwalają na przeprowadzenie kontrolowanego etapu.

Jednoznaczne definiowanie przejść i odpowiedzialności za dane

Podczas równoległej eksploatacji musi być jasne, który system jest wiodący dla których danych. Niekontrolowany dwukierunkowy zapis może prowadzić do sprzecznych stanów danych. Synchronizację, adaptery przejściowe i uzgadnianie danych planujemy wyłącznie na faktycznie potrzebny okres przejściowy.

Droga powrotna zależy od zmian danych, które już nastąpiły. Dlatego jeszcze przed przełączeniem określamy, do jakiego momentu powrót jest możliwy i jakie prace dodatkowe byłyby wówczas konieczne. Po pomyślnym przejściu stare dostępy, zadania i infrastruktura są celowo wyłączane, aby rozwiązanie przejściowe nie generowało trwale dodatkowej złożoności.

Poglądowy scenariusz projektu

Jak usługa pomaga w codziennej pracy.

Przykład: istniejąca aplikacja ma otrzymać nowy obszar klienta. Najpierw wydzielamy widok klienta działający w trybie tylko do odczytu i porównujemy jego dane z systemem starszego typu. Procesy zapisu są dodawane później, wraz z określonym momentem zmiany odpowiedzialności za dane.

Ten przykład opisuje możliwy przebieg i nie jest referencją klienta.

Przed zleceniem

Modernizacja oprogramowania: Państwa pytania.

Czy wszystko trzeba zbudować od nowa?

Nie. Dobrze działająca logika biznesowa może zostać zachowana. Inwentaryzacja pokazuje, czy sensowna jest zmiana środowiska uruchomieniowego, odnowa poszczególnych modułów czy pełne zastąpienie. Decydujące znaczenie mają łatwość utrzymania, ryzyko oraz planowane zmiany w procesie biznesowym.

Co się dzieje w przypadku braku dokumentacji?

Odtwarzamy zależności na podstawie kodu, danych i rzeczywistych procesów. Szczególnie ważni są przy tym pracownicy posiadający wiedzę merytoryczną. Brak dostępu lub uprawnień do korzystania z systemu może ograniczyć zakres prac; takie luki wyjaśniamy, zanim złożymy wiążącą deklarację.

Czy system może w tym czasie nadal działać?

Zmianę często można przeprowadzić etapami. To, czy potrzebna jest eksploatacja równoległa, krótkie okno serwisowe czy dłuższa przerwa, zależy od sposobu przechowywania danych i architektury. Przełączenie planujemy wraz z merytorycznym uzgodnieniem danych i realistyczną, możliwą do zastosowania drogą powrotu do poprzedniego stanu.

Warto połączyć

Doradztwo w zakresie oprogramowania Oprogramowanie dedykowane Portale internetowe i aplikacje Tworzenie interfejsów Testy oprogramowania DevOps i wydania Utrzymanie oprogramowania

Kolejny krok

Prosimy powiedzieć nam, gdzie dziś pojawiają się trudności.

Do rozpoczęcia wystarczy krótki opis Państwa aplikacji, problemu i celu. Wybrana usługa zostanie uwzględniona w Państwa zapytaniu kontaktowym.

Zapytaj o tę usługę

Menu

Stare oprogramowanie. Rosnące ryzyko.