Dla Zespołu Informatyki Wyborczej Krajowego Biura Wyborczego czas wyborów jest testem prawdy. Wielomiesięczne przygotowania podlegają weryfikacji przez dwa, trzy dni w ciągu roku. Ostatnie wybory prezydenckie ZIW może zaliczyć do udanych. Od strony informatycznej nie było żadnej wpadki. Apetyt rośnie jednak w miarę jedzenia. Od nowego roku Państwowa Komisja Wyborcza, wraz z utworzeniem Delegatur KBW, postanowiła bowiem użytkować system informatyczny w trybie ciągłym. Powód? Coraz większa liczba referendów na szczeblu lokalnym oraz konieczność ciągłej aktualizacji rejestru wyborców. Przygotowania do tej operacji zajęły bez mała 4 lata.

Przy tworzeniu systemu informatycznego KBW, w przeciwieństwie do Poltaxu, zastosowało metodę "małych kroków". Od samego początku jego tworzenia, tzn. od 1990 r. było jasne, że decydujący dla powodzenia systemu będzie nie sam proces rejestrowania danych, a niezawodność ich transmisji. System powoli rozwijał się od formy prostego BBS w 1990 r. poprzez Polpakowską sieć on-line w 1993 r. do systemu klient/serwer z pełną replikacją danych w sieci opartej na protokole TCP/IP w 1995 r.

"W roku 1990 po raz pierwszy wdrożyliśmy BBS oparty na komputerach PC, które otrzymaliśmy z GUS-u, i na bazie danych zrobionych pod Clipperem" - mówi Andrzej Florczyk, dyrektor Zespołu Informatyki Wyborczej przy KBW. Centralna baza danych działała pod Xenixem w Informixie i to przywiązanie KBW do Informixa trwa do dzisiaj. Przełomowy dla systemu stał się rok 1993. Po przejściu na znacznie bardziej nowoczesny system operacyjny (SCO Unix) serwis i zarządzanie lokalnymi bazami danych przekazano specjalistom z policji. W tym samym czasie KBW podpisało umowę z Polpakiem na stworzenie sieci pakietowej oraz zakupiło nowe serwery (Compaq Deskpro M33). "Dostawcą była gdańska firma Prokom, z którą KBW jest związane od samego początku tworzenia systemu" - mówi Andrzej Florczyk. "Prokom po wygraniu w 1991 r. przetargu na dostawę centrali i ogólnopolski serwis dla KBW, zadeklarował chęć współtworzenia z nami kompletnego systemu informatycznego. Kulminacyjnym okazał się rok 1995 r., kiedy to Prokom wygrał przetarg na stworzenie oprogramowania obsługującego nasz system i wywiązał się z zadania bez zarzutu" - mówi Andrzej Florczyk.

Faza projektowania

Nad założeniami systemu do obsługi wyborów prezydenckich KBW pracowało od marca 1995 r. Specyfikacja techniczna dla bazy danych, procedur wprowadzania danych oraz wydruków kontrolnych i ostatecznych, została sprecyzowana w lipcu ub. r. Najwięcej czasu poświęcono problemowi integralności baz danych oraz zminimalizowania prawdopodobieństwa wprowadzenia błędnych danych wybierając metodę dublowania z blokowaniem terminali w przypadku niezgodności danych.

Przetarg ograniczony na opracowanie centralnego i lokalnego oprogramowania do obsługi KBW i sieci WBW (Wojewódzkich Biur Wyborczych) oraz modernizację sieci transmisji danych (routery TCP/IP) ogłoszono 1 września 1995 r., zgodnie z ustawą o zamówieniach publicznych. 15 września przetarg na oprogramowanie wygrał Prokom, a na dostawę routerów TCP/IP - 3COM. Za niezawodność linii komunikacyjnych odpowiedzialny był Polpak.

Tworzenie pierwszego w Polsce oprogramowania klient/serwer, opartego na pełnej replikacji danych, trwało zaledwie miesiąc (do 15 października ub.r.). System tworzyło 15 osób, z czego 10 z Prokomu. Komisyjny odbiór zamówionego oprogramowania odbył się po tygodniu (22 października ub.r.) i został oparty na opinii trzech niezależnych ekspertów (KIR, PIIiT, Inst. Podst.Inf. PAN) w zakresie analizy funkcjonalnej produktu. Ujawnione błędy Prokom usunął w ciągu 2 dni. Było to możliwe dzięki Object Lifecycle, metodzie projektowania polegającej na tym, że raz zdefiniowane obiekty przechodząc przez fazę prototypowania umożliwiały empiryczne sprawdzenie, jakiego rodzaju dane mogą być przesyłane w sieci i czy stosowane narzędzia oraz technologie mogą sprostać takim potrzebom. "W pierwszej kolejności baliśmy się o linie trasmisyjne, które zapychały się w 1993 r., ale ratunek przyszedł w postaci TCP/IP" - mówi Andrzej Florczyk.

Ostateczna konfiguracja systemu wyglądała następująco: 49 lokalnych baz danych było zreplikowanych w komputerze centralnym, a poprzez protokół TCP/IP były realizowane replikacyjne transakcje. W momencie jakiejkolwiek lokalnej zmiany danych lokalny motor bazy danych powodował replikację danych on-line w centralnym serwerze. Zaletą tego rozwiązania było zwielokrotnienie poziomu bezpieczeństwa.

Przy rozproszonym systemie lokalne motory baz danych są odpowiedzialne za to, aby w przypadku zerwania łączności były w stanie zapewnić integralność całej bazy po nawiązaniu łączności. Co więcej każda lokalna baza danych jest autonomiczna, tzn. że bezpieczeństwo centralnej bazy danych nie zależy od bezpieczeństwa baz lokalnych. Jeśli któraś z nich zostaje uszkodzona, to jej kopią on-line dysponuje centrala i można z niej korzystać do czasu usunięcia uszkodzenia. "W trakcie wyborów nie zdarzyło się, aby baza danych utraciła integralność" - mówi Andrzej Florczyk.