Algorytm nie zawsze silny

Automatyczne korygowanie danych jest dobre, gdy mamy do czynienia z klarownymi uwarunkowaniami. W przeciwnym przypadku można sobie napytać niezłej biedy.

Algorytm nie zawsze silny
Raport specjalny Data Governance

Dbałość o jakość danych wciąż w dużej mierze zależy od racjonalnej polityki człowieka. Jak uniknąć błędów we wprowadzaniu danych? Dobre i złe strony stosowania mechanizmów automatycznej weryfikacji danych. Jak uniknąć zniekształcenia danych podczas migracji do nowego systemu? Na co zwrócić uwagę podczas integracji systemów. Odpowiadamy na te i wiele innych pytań.

Do tej pory zajmowaliśmy się skutkami zmian struktur danych, ich miejsca pobytu czy wreszcie wzajemnego ich kojarzenia w procesie konsolidacji. Jest to jedna strona medalu w batalii o jakość danych. Drugą stroną jest warstwa aplikacji, z jej logiką, sposobem organizacji interfejsu i zastosowaniem. Okazuje się, że zmiana otoczenia aplikacyjnego może silnie wpływać na interpretację danych i nie zawsze problemy te poddają się korekcie przez zastosowanie algorytmów.

Istotną sprawą związaną z przetwarzaniem danych jest problem aktualizacji oprogramowania. Odbywać się to może dwiema drogami: z towarzyszącą temu zmianą lub bez zmiany struktur danych. W tym drugim przypadku nakłada się nowe wersje aplikacji, które z reguły działają poprawnie - przynajmniej na zestawach danych testowych oraz danych użytkowych, na jakich pracuje się w trybie bieżącym. Jeśli produkt nie zostanie należycie przetestowany, to błędy wnet wychwyci użytkownik i z pewnością bez ogródek i cyzelowanych określeń da tego wyraźny sygnał.

Każda modyfikacja oprogramowania powinna być uwieńczona testowaniem jego sprawności w pełnym spektrum danych, w tym również danych historycznych, z którymi bywa największy problem. W realnych warunkach najczęściej nie ma mowy o tak szerokim zakresie sprawdzenia wpływu zmian, więc zdarza się, że po kilku cyklach modernizacji oprogramowania coś przestaje funkcjonować w starszych zestawach danych, o czym najczęściej dowiadujemy się przypadkowo i jak zwykle w najmniej spodziewanym momencie. Albo nie pasują reguły do wartości, albo też formatowanie w warstwie prezentacyjnej nie daje sobie rady z określonym zakresem wartości, albo też zagubiono gdzieś wartości słownikowe zaszyte niegdyś na stałe w aplikacji, w związku z czym zamiast ładnego tekstu przy nazwie obiektu na wydruku pokazuje się ciąg "krzaków".

Dużo częściej zdarza się, że zmianie aplikacji towarzyszy jakaś, często nieznaczna, modyfikacja struktury danych. Takie "małe zmiany" kończą się często tragicznie, jeśli nie zostaną dostatecznie mocno przetestowane.

Informacja zależna od interpretacji

W zasadzie każda zmiana formatu lub struktury danych wymaga skontrolowania wpływu tych zmian na wszelkie ogniwa procesu przetwarzania. Jest to zadanie praktycznie trudne do wykonania we wszystkich detalach. Zazwyczaj testuje się główne ciągi procesów aplikacji, ale miejsc, gdzie wpływ tej zmienionej struktury może objawić swoje zdradliwe oblicze, jest wiele. Najczęściej problem pojawia się przesunięty w czasie i kojarzony bywa z zupełnie odmiennymi przyczynami niż faktycznie ma to miejsce.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200