Z czym ten bull?

A może porozmawiajmy o systemie POLTAX? Bo ja w ogóle nie bardzo rozumiem tych trudności Bulla...

A może porozmawiajmy o systemie POLTAX? Bo ja w ogóle nie bardzo rozumiem tych trudności Bulla...

Projektanci systemów mają do czynienia z problemami o bardzo różnych stopniach skomplikowania i "nietypowości". Przeczytałem niedawno, że system dla sterowania wielką złożoną maszyną drukarską, trzeba za każdym razem projektować od nowa, bo każdą projektuje się i montuje indywidualnie, dla danego nabywcy. Ale nie mogłem zrozumieć Wielkiej Tajemnicy Niezwykle Złośliwych Trudności produkowania za każdym razem - prototypu.

Nie ma w maszynie drukarskiej, żeby największej, żadnych czynności niepowtarzalnych; zmieniają się tylko parametry lub kolejność danych operacji. System powinien więc składać się z kompozycji modułów, których parametry definiuje się wedle cech danej nowej maszyny, i odpowiednio łączy ze sobą. Nawet jeśli dana partia modułów tworzy jakąś pętlę, nie jest to poważna trudność; nawet jeśli się tych pętli rozgałęzia parę... Nie ma w nich, bo nie może być, czegoś nowego, czego w innej maszynie nie było; różnić może maszyny tylko skala. Czyli, że wielki producent drukarni albo nie wiedział, co zamówić u informatyków, albo też zamawia systemy sterowania za każdym razem u kogoś innego i zaczyna wszystko od zera.

Może ktoś podejrzewać, że producent... tylko udaje, kryjąc użycie gotowych już "klocków". Niestety, z opisu instalacji maszyny niedwuznacznie wynika, że testowano oprogramowanie całkiem zielone, nowe powstałe od zera.

Uprzedzam: nie znam założeń, jakie Ministerstwo Finansów przedstawiło Bullowi. Ale z parokrotnie opisywanych dziejów tego kontraktu dorozumiewam się, że po stronie zleceniodawcy nie było skarbowca-informatyka, ani po stronie Bulla - informatyka z jaką taką wiedzą o skarbowości. Nasz system podatkowy jest kiepski, ma dziesiątki wad i luk; ale operacje, jakie wykonuje się w systemach podatkowych, i rodzaje danych, na jakich się je wykonuje, są znane od stu kilkudziesięciu lat.

Co więcej, moduły software'owe przydatne do obsługi tych operacji są od lat typowym elementem ofert z gotowym oprogramowaniem, i to w wersji sparametryzowanej. Kiedy czytam, że dla systemu POLTAX "brak ogólnopolskiej bazy danych", śmiech mnie ogarnia. Wykonawca powinien dostarczyć sparametryzowanej, modularnej, ale przecie typowej od lat bazy danych. Operacje wyszukiwania (retrieval), sortowania czy zliczania w różnych przekrojach, a nawet analizy wewnętrznej zgodności pozycji danego zeznania podatkowego nie wymagają dla ich zaprogramowania znajomości konkretnego obowiązującego arkusza zeznania podatkowego. Może on zawierać nawet bzdury, ale przecie wszystkie - typowe; odpisy zmniejszające podstawę opodatkowania czy też ulgi pozostaną bez względu na przyczynę i charakter odpisami i ulgami, mogą tylko zmienić miejsce w procedurze i może być ich mniej lub więcej. Użytkownik zaś, czyli skarbowiec, sam powinien móc określić, jakie pozycje zeznania komputer ma porównać ze sobą i kiedy. Co oznacza, innymi słowy, że to sami użytkownicy powinni móc dostarczony sparametryzowany software zdefiniować wedle swoich potrzeb. Zwłaszcza w sytuacji, kiedy będą swój system podatkowy korygować przez

no, dobre parę lat.

Oczywiście, jest kwestią dyskusji czy systemowi podatkowemu potrzeba jednego centralnego zbioru danych, czy też lepiej mieć zdecentralizowane bazy danych. Osobiście byłbym za decentralizacją. Nie tylko ze względu na wyższą niezawodność; dziś podatnicy nie mogą się dowiedzieć oficjalnie, ile dany Urząd Skarbowy od nich zbiera, to są dane utajnione, ale demokracja musi z tym zrobić porządek. Kiedy powierzymy ściąganie podatków gminom, nie będziemy wtórnie decentralizować zbiorów lub zakładać nowych. A i tak serwer dla każdego Urzędu będzie musiał pracować z ogromną pamięcią operacyjną i olbrzymimi pamięciami masowymi...

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

TOP 200