Dokumentacja projektowa systemu informatycznego

System informatyczny obsługi firmy doradztwa podatkowego

Wersja pierwsza

ZESPÓŁ WYTWÓRCZY 3/2010/GB

Stanowisko	Imię i Nazwisko	Zrealizowane zadania
Kierownik projektu / Zamawiający	Justyna Sokołowska	Interfejs systemu, zarządzanie, formatowanie dokumentu
Zamawiający / Tester akceptacyjny	Michał Szałwiński	Diagramy
Analityk / Projektant	Bartłomiej Sujkowski, Marcin Szczepaniak	Protokoły komunikacyjne, Harmonogram implementacji, optymalizacja systemu, Plan testów, Podsumowanie, Wstęp
Analityk / Tester wewnętrzny	Paweł Stempień	Baza danych
Projektant / Tester wewnętrzny	Damian Sulej	Diagram klas

PROWADZĄCY

Grzegorz Bliźniuk

Warszawa, 2010

Spis treści:

 

1. Wstęp

2. Diagram klas

1. Diagram klas

2. Definicje

3. Projekt bazy danych

1. Model konceptualny

2. Definicje

4. Optymalizacja systemu

5. Interfejs użytkownika

6. Protokoły komunikacyjne

7. Diagramy wdrożeniowe

1. Diagram komponentów

2. Diagram rozlokowania

8. Harmonogram implementacji

9. Plan testów

10. Podsumowanie

1. Wstęp

Niniejszy dokument opisuje fazę projektową systemu informatycznego tworzonego dla firmy doradztwa podatkowego „Jussoko-team”. Celem tej fazy jest opracowanie szczegółowego opisu implementacji systemu. Rozstrzyga ona kwestie jak zbudowany ma być system, aby zrealizować wszystkie wymagania określone w fazach poprzedzających. W dokumencie opisane zostały wszystkie szczegóły, zwłaszcza szczegóły techniczne, o które wzbogacony został model systemu, tak aby był jak najbardziej wydajny, niezawodny i łatwy w konserwacji.

2. Diagram klas

Diagram klas fazy analizy przedstawiał uproszczony, poglądowy zbiór klas, na które składa się system informatyczny. Diagram utworzony w fazie projektowania jest rozszerzeniem diagramu z fazy analizy. Oprócz relacji pomiędzy klasami takimi jak Asocjacje czy Generalizacje przedstawia również wszystkie wymagane zmienne (atrybuty) oraz funkcje (metody).

1. Diagram klas

2. Definicje

• Klasa Dane osobowe jest klasą abstrakcyjną. Dziedziczą po niej wszystkie klasy reprezentujące ludzi, tj osób korzystających z systemu informatycznego. Każda z osób ma określoną nazwę_użytkownika oraz przywileje.

• Klasami pochodnymi są:

• Administrator- nieograniczony dostęp do bazy danych, modyfikacja użytkowników danego systemu

• Użytkownik - dostęp do słownika, przepisów prawnych, możliwość dokupienia abonamentu, dodawanie problemów standardowych/niestandardowych, korzystanie z tutoriali, przeglądanie wcześniej wypełnionych dokumentów

• Konsultant - przeglądanie i rozwiązywanie problemów użytkowników oraz ich ewentualna modyfikacja

• Pracownik - wgląd do danych osobowych oraz problemów użytkowników systemu borykającymi się z problemami podatkowymi

• Klasa Gość nie dziedziczy po abstrakcyjnej klasie Dane osobowe. Jest wyjątkiem spośród klas reprezentujących ludzi, mianowicie gość nie posiada swoich danych osobowych gdyż jest to postać anonimowa, ma jedynie przywileje, które umożliwiają mu przeglądanie słownika, przepisów prawnych bądź ewentualnie wykupienie abonamentu, dzięki czemu może stać się pełnoprawnym użytkownikiem systemu.

• Klasa Przepisy podatkowe zawiera akty prawne i ustawy dotyczące podatków, a odpowiadają za to atrybuty nr_artykułu, paragraf oraz przepis. Dostęp mają tutaj zarówno pełnoprawni użytkownicy jak i Goście.

• W klasie Słownik pojęć możemy znaleźć trudne i nie zrozumiałe dla nas pojęcia z tematyki podatków, metoda szukaj() znajduję interesujące dla nas pojęcie wraz z jego opisem.

• Klasa Tutorial zawiera opisy pomocy, tj. w jaki sposób wypełniać niektóre dokumenty. Skorzystać z niej mogą jedynie pełnoprawni użytkownicy.

• Klasy Logowanie i Zalogowany odpowiadają za logowanie do systemu. Pierwsza klasa zawiera login oraz hasło danego użytkownika, za pomocą metody zaloguj() następuję jego zalogowanie. Zalogowane osoby to: użytkownik, pracownik, konsultant, administrator. Osobą nie korzystającą z klasy Zalogowany jest Gość.

• Problem niestandardowy to klasa którą „tworzy” użytkownik. Zawiera ona nazwę, opis oraz datę utworzenia problem. Może on być zatwierdzony bądź przesłany do konsultanta za pomocą odpowiednich metod. W sytuacji wyjątkowej możliwe jest z korzystanie z metody przejdz_do_pomocy().

• Użytkownik może również korzystać z problemów standardowych za co odpowiada klasa Problem Standardowy. Atrybutami tutaj są typ_dokumentu oraz data utworzenia danego problemu. Tutaj również mamy do czynienia z metodami zatwierdz_problem() oraz przejdz_do_pomocy().

• Klasa Dokument wykorzystywana jest przez użytkownika. Zawiera typ wypełnianego dokumentu oraz imię i nazwisko użytkownika. Za sprawdzeniem poprawności dokumentu stoi klasa Weryfikacja dokumentu. Posiada takie same atrybuty jak Dokument oraz dodatkowo typ i miejsce powstałego błędu. Dany dokument podlega metodzie sprawdz(). Może być tutaj zatwierdzony, można również zapisać bądź anulować zmiany. Po sprawdzeniu poprawności wędruje on do klasy Lista dokumentów. W Liście dokumentów mamy nr_dokumentu, jego właściciela oraz datę złożenia. Za pomocą metody wyświetl_dokument() wyświetlamy treść sprawdzonego dokumentu.

3. Projekt bazy danych

1. Model konceptualny

2. Definicje

Encja Witryna skupia na sobie składniki danej witryny poprzez relacje z nimi, lecz nie ma przymusu ich posiadania.

Użytkownik jest składnikiem Witryny, encją abstrakcyjną, która nie jest generowana. Zawiera postawowe informacje dotyczące użytkowników witryny internetowej oraz klucz główny pozawalający ich rozróżniać. Dziedziczą po niej encje Klienta oraz Pracownika. Użytkownicy muszą być przydzieleni do Witryny.

Pracownik dziedziczy po encji Użytkownik i jest encją generowaną, odpowiada za osoby fizyczne będące zatrudnione w firmie jednak nie zajmujące się na ogół pracą z witryną internetową. Jest ona w relacji z encją Wynagrodzenie oraz Witryna. Dziedziczą po niej encje Administrator oraz Konsultant rozszerzając pojęcie Pracownika.

Wynagrodzenie jest w relacjach z encjami reprezentującymi pracowników, każdy z pracowników musi otrzymać Pensję jednak nie każde z przewidzianych wynagrodzeń musi być wykorzystane, np.: specjalne premie.

Administrator dziedziczy po encji Pracownik, rozszerza ją i ma te same relacje.

Konsultant dziedziczy po encji Pracownik, rozszerza ją i poza relacjami encji Pracownik jest związana z encjami Problem, H_Problem oraz Konsultacja. Nie musi on mieć przydzielonych Konsultacji bądź problemów, lecz one muszą być przydzielone do konsultanta.

Encja Konsultacja jest związana relacjami również z Klientem oraz Problemem ponieważ odnosi się również do nich.

Klient dziedziczy po encji Użytkownik, może mieć przydzielone Konsultacje, Problemy, H_Problemy czyli problemy z rozwiązaniami oraz Opłaty zgodnie z posiadanymi relacjami.

Problem jest związany z Klientem oraz Konsultantem na zasadzie jeden z wielu i musi być do nich przydzielony, sam natomiast może mieć przydzielone Konsultacje oraz Załącznik(i)_Skan. Jest także bezpośrednią składową Witryny.

Podobnie Encja Problem względem Encja H(istoria)_Problem(u) jest w relacji z Klientem, Konsultantem oraz jest składnikiem Witryny z tym, że jest to Problem wraz z rozwiązaniem, dalej juz nie podlegający w tym momencie konsultacjom. Jej składnikiem może być analogicznie Encja H_Załącznik_Skan.

Składnikami witryny będzie również pomoc. Ogólna Encja opisująca jej działy - Dział_Pomocy jest rozłożona poprzez encję Element_Pomocy, na konkretne elementy w działach.

Zależnie od typu Elementu_Pomocy może on mieć dodatkowe składniki. Jeśli będzie on tutorialem, Encja Krok_Tutoriala reprezentuje kolejne kroki prezentowane Klientowi przez witrynę internetową. Podobnie jeśli elementem będą Dokumenty, których wypełnienie umożliwia witryna wtedy rozszerza go encja Dokument, która to posiada poszczególne Pola_Do_Wypełnienia oraz jest związana również z konkretnym Klientem.

Encja Opłata jest również składnikiem witryny, jako jedna z możliwych wielu musi być przyporządkowana do danego Klienta. Służy ona umożliwieniu realizacji Konsultacji bądź to Problemu co widać poprzez Atrybuty Zezwolenie_Na_*.

4. Optymalizacja systemu

Podczas implementacji systemu, wybieramy możliwie najlepsze typy danych tj. takie, które wystarczająco obejmują zakres zmienności swoich wartości.

System będzie tworzony w dużej mierze obiektowo, dlatego też zdecydowaliśmy się na pisanie aplikacji w języku C++. Dużą zaletą tego języka jest także możliwość tworzenia funkcji wplatanych, które pozwolą na korzystanie z innych języków programowania.

Dodatkowo podczas tworzenia systemu eksperckiego posłużymy się aplikacjami napisanymi w języku prolog, który jest dobrym podłożem do tworzenia takiego typu systemów.

W bazie danych często będzie potrzeba wyszukiwania danych, aby przyspieszyć ten proces zastosowane zostaną indeksy, a w nich indeksy wyszukiwania pełno testowego.

Z punktu widzenia korzystania z systemu przez klienta ważnym aspektem i mechanizmem jest cache. Klient często będzie wracał do podstrony lub wyszukiwania. Jeżeli dane się w tym czasie nie zmieniły dzięki cache serwer nie musi na nowo obsługiwać żądania powrotu do podstrony, ponieważ jest ona w cache. Dzięki temu ruch komunikacyjny klient-serwer może zostać ograniczony a co za tym idzie będzie mniej obciążony i będzie działał wydajniej.

Dodatkowo interfejsy osób użytkujących system będą ograniczone do niezbędnego minimum, do strony nie będą ładować się filmy, czy też dźwięk, które znacznie mogą opóźniać ładowanie strony i korzystanie z systemu. Grafika również będzie sprowadzała się do ergonomicznego stylu, tak aby ułatwić użytkownikom pracę. Przyśpieszy to działanie serwera, który nie będzie musiał obsługiwać ciągłego transferu dużych plików.

Omówione powyżej mechanizmy optymalizacji zapewniają duży wzrost wydajności oraz niezawodności systemu.

5. Interfejsy użytkownika

1. Strona WWW

Strona WWW ma być wyświetlana pod wszystkimi czołowymi przeglądarkami internetowymi.

Niezalogowany użytkownik ma do dyspozycji jedynie podstawowe zakładki. Na podstawie których jest w stanie określić koszty pozyskania potrzebnych mu informacji oraz podstawowe informacje o firmie.

2. logowanie do systemu

Podczas logowania strona wykorzystuje transmisję szyfrowaną. Niezarejestrowany użytkownik przed otrzymaniem osobistego konta musi wnieść opłatę.

3. Interfejs zalogowanego użytkownika

Każdy zarejestrowany użytkownik ma osobiste konto w systemie. Zalogowany użytkownik ma dostęp do rozszerzonej pomocy składającej się na: słownik, tutorial, zbiór dokumentów, aktualne przepisy prawne wraz z ich opracowaniem, system ekspercki umożliwiający identyfikację problemu oraz możliwość konsultacji z pracownikiem biura. Może przeglądać wcześniej wypełnione przez siebie dokumenty oraz historię problemów. Korzystanie z niektórych opcji wymaga wniesienia wcześniejszej opłaty (umówienie się na spotkanie, rozmowa telefoniczna z konsultantem).

4. Interfejs konsultanta

Każdy pracownik ma zakładane osobiste konto w systemie. Konsultant ma możliwość przeglądania profilu klientów oraz wypełnione przez nich dokumenty. Dodatkowo posiada dostęp do aktualnych problemów wymagających rozwiązania oraz problemów zamkniętych.

W celu ułatwienia pracy konsultanta posiada on również dostęp do bazy danych przepisów prawnych.

5. Interfejs administratora

Każdy z administratorów posiada oddzielne konto w systemie. Posiada nieograniczony dostęp do baz danych. Może przeglądać konta klientów oraz konsultantów i modyfikować ich parametry oraz usuwać. Ma możliwość dodania nowych pracowników biura. W tym celu wprowadza dane osobiste oraz nadaje nazwę użytkownika oraz hasło.

Ma nieograniczony dostęp do bazy danych problemów. Może rozszerzać system ekspercki o nowe zagadnienia, zajmuje się aktualizacją przepisów oraz dokumentów.

6. Protokoły komunikacyjne

Ponieważ musimy zapewnić możliwość wymiany danych oraz łączność między jednostkami oraz urządzeniami, stosujemy do tego protokoły komunikacyjne. Są to reguły postępowania. W siedzibie firmy pracownicy , administratorzy i konsultanci korzystać będą z sieci lokalnej i transmisji FastEthernet, natomiast do komunikacji z klientami wykorzystywany będzie Internet czyli protokoły modelu TCP/IP. Możemy wyróżnić trzy protokoły, które będą najczęściej wykorzystywane przez klientów:

1. http - dzięki niemu klienci będą mogli poruszać się po systemie za pośrednictwem przeglądarki internetowej, która przesyła z serwera hipertekst ( strony sieci Web) do konkretnego użytkownika.

2. https - jest to protokół używany do transmisji między hostami, wykorzystywany jest w systemie podczas przesyłania poufnych danych takich jak dane logowania, informacje dokonywania płatności, oraz dane dotyczące rozliczeń podatkowych klienta.

3. ftp - wykorzystuje się ten protokół do przesyłania plików, pliki mogą zostać udostępnione do pobrania przez klientów np. materiały reklamowe, poradniki dotyczące rozliczeń podatkowych itp., w formacie PDF.

4. Pop3 i smtp - protokoły umożliwiające wymianę informacji za pomocą poczty elektronicznej.

7. Diagramy wdrożeniowe

1. Diagram komponentów

1. Strona i doradztwo

Komponenty dla strony internetowej i aplikacji doradztwa są do siebie podobne. Podczas przesyłania danych aby zapewnić ich bezpieczeństwo wykorzystujemy szyfrowanie RSA i DES. Baza danych są implementowane przez firmę Oracle, a ponadto mają być kompatybilne z bazą firmy Microsoft.

Przy wyborze oferty korzysta się z katalogu ofert. Natomiast opłata i zgłaszanie problemu wchodzą w skład jednego komponentu - transakcji.

Przy aplikacji doradztwa wyróżniono oddzielny komponent na interfejs użytkownika. Interfejs ten jest niezależny od samej aplikacji. Dzięki takiemu rozwiązaniu komponenty będzie można rozwijać oddzielnie.

Strona:

Doradztwo:

b) Centrala oraz konsultant

Jak w powyższym diagramie tutaj także wydzielono komponent interfejsu użytkownika. Aplikacja ma dostęp do katalogu ofert, a co najważniejsze komponent ofert daje możliwość ich dodawania i modyfikacji. Umożliwia także akceptację ofert indywidualnych nadesłanych przez biura.

Na diagramie uwzględniono także rolę konsultantów w systemie. Zaznaczono możliwość wzajemnej komunikacji. Komponent transakcji realizuje ponadto transakcje do zgłoszonych odpłatnych problemów w tym rozliczenie klienta. Również na tym diagramie uwzględniono, że systemu centrali wykorzystujący oprogramowanie firmy Oracle ma być kompatybilna Microsoft - Microsoft SQL Server.

1. Diagram rozlokowania

Diagramy rozlokowania zwane są też ogólnie diagramami wdrożeniowymi. Umożliwiają opis fizycznej alokacji poszczególnych komponentów aplikacji - na przykład w serwerowniach głównych, serwerowniach zapasowych, czy też miejscach użytkowania aplikacji na urządzeniach statycznych i urządzeniach mobilnych.

1. Obsługa klienta

Klient/Gość łączy się z serwerem obsługi poprzez protokół TCP/IP. Komunikacja między serwerami firmy odbywa się poprzez FastEthernet.

Klient może się zarejestrować i przeglądać interesujące go oferty w tym te stworzone przez centralę. Po wybraniu odpowiedniego działu może zgłosić swój problem. Wszystkie zmiany zapisywane są w bazie danych. Komputer centrali i serwer obsługi klienta są połączone z centralną bazą danych.

2. Doradztwo

Pracownik doradztwa może łączyć się bazą danych centrali firmy poprzez zbiór protokołów TCP/IP. Może wyszukać ofertę i zgłosić tę, która dotyczy klienta. Może również pomóc w dalszej obsłudze zleceniodawcy.

3. Konsultanci

Konsultanci również komunikują się poprzez TCP/IP. Dane przez nich aktualizowane zapisują się w bazie danych dotyczących ich zasobów, natomiast sami pobierają zamówienia i informacje o klientach.

Każde żądanie przechodzi jednak przez serwer centrali celem zapewnienia poprawności i

spójności wymienianych danych.

4. Transakcje

W transakcjach pośredniczy serwer banku. Diagram ogólnie opisuje funkcjonalność komponentów.

8. Harmonogram implementacji

Tworzenie sytemu dla firmy doradztwa podatkowego „Jussoko-team” zostało podzielone na ileś etapów:

Terminarz poszczególnych etapów:

Rodzaj (etap) tworzenia systemu	Data rozpoczęcia i ukończenia etapu
Utworzenie baz danych	1.07.2010- 1.08.2010
Fizyczne ulokowanie serwera oraz stworzenie sieci w firmie	2.08.2010-1.09.2010
Implementacja wszystkich klas systemu	2.09.2010-1.11.2010
Implementacja systemu eksperckiego	2.11.2010-3.12.2010
Połączenie wszystkich elementów, implementacja pozostałych funkcjonalności, również powstałych w wyniku nieprzewidzianych dodatkowych wymagań klienta	3.12.2010-1.02.2011
Implementacja Interfejsów użytkownika, grafiki	2.02.2011-3.03.2011
Testy wewnętrzne	3.03.2011-1.05.2011
Wdrożenie	4.05.2011-20.05.2011
Testy, uzupełnianie baz danych	4.05.2011-1.06.2011
System oddany do użytku	20.06.2011

9. Plan testów

1. testowanie bazy danych

W bazach danych należy zwrócić szczególną uwagę na kwestie bezpieczeństwa, dlatego głównym celem tego etapu jest sprawdzenie zabezpieczeń. Należy przetestować wszystkie możliwe kanały, którymi dane mogą dostać się w niepowołane ręce. Ważną kwestią jest również przetestowanie przydzielania uprawnień poszczególnym użytkownikom systemu, do korzystania z danych zawartych w bazach danych. Nadawanie odpowiednich uprawnień jest bardzo ważne, biorąc pod uwagę możliwości wprowadzania zmian w bazie danych. W celu zabezpieczenia przed nieumyślnymi zmianami w skutek awarii systemu lub ingerencji użytkowników, należy przetestować działanie modułu tworzącego kopie zapasowe. Bazy należy sprawdzić pod względem ich budowy, tak aby zmniejszyć do minimum występowanie redundancji przechowywanych danych. Kolejnym krokiem w testowaniu baz danych będzie sprawdzenie ich wydajności oraz możliwości jednoczesnego korzystania z tych samych danych przez kilku użytkowników systemu.

2. testowanie aplikacji przeznaczonej dla klienta

Ten etap wymaga przede wszystkim przetestowania współpracy pomiędzy aplikacją klienta, a bazą danych, systemem eksperckim oraz systemem bankowym. Należy zadbać o to, by klientowi były wyświetlane odpowiednie dane w odpowiedniej formie. Sprawdzeniu powinny podlegać również wszystkie moduły dostępne z poziomu aplikacji klienta, oraz sterowanie poszczególnymi elementami systemu informatycznego.

Aplikacja przeznaczona dla klientów jest szczególnie narażona na ataki. Szczególnie należy zwrócić tu uwagę na uwierzytelnianie użytkowników, aby zmniejszyć ryzyko dostępu do systemu przez niepowołanych użytkowników. Należy zbadać również możliwości wykonywania skryptów na stronie, aby zabezpieczyć się przed atakami mającymi na celu kradzież danych użytkowników systemu lub możliwością zakładania wielu kont w bardzo krótkim czasie przez stworzone do tego celu automaty.

3. testowanie panelu konsultanta

Dla panelu konsultanta należy przede wszystkim zbadać poprawność działania kanałów komunikacji z klientem. Jest to główny moduł na którym będzie pracował konsultant, dlatego niezwykle ważne jest aby mógł on z poziomy swojego panelu korzystać z telefonu lub e-maila. Konsultant musi mieć również wgląd do dokumentów utworzonych przez klientów, dlatego koniecznym będzie sprawdzenie poprawności przesyłania ich pomiędzy bazą, a konsultantem oraz klientem i konsultantem.

4. testowanie panelu administratora

Administrator ma największe uprawnienia spośród wszystkich użytkowników. On jako jedyny może zmieniać większość elementów systemu. Szczególnie ważne są zmiany we wszelkiego rodzaju bazach danych, dlatego niezwykle istotny jest tu moduł odpowiedzialny za tworzenie kopii zapasowych danych. Należy przetestować go zarówno pod względem wydajności jak i niezawodności, aby możliwe było odtworzenie danych po awarii systemu lub ingerencji jednego z użytkowników. Należy też bardzo dokładnie sprawdzić poprawność działania wszelkich modułów służących do dodawania, usuwania lub zmiany danych, aby mieć pewność że operacje te dotyczą właściwych danych. Testy mające na celu sprawdzenie jak system reaguje na wprowadzanie niestandardowych danych ograniczają możliwość popełnienia błędów przez administratora, co w przyszłości będzie skutkowało większą niezawodnością systemu.

5. testowanie modułu współpracującego z systemem bankowym

Moduł ułatwiający dokonywanie przelewów jest elementem w którym trzeba zatroszczyć się o szczególne zabezpieczenia. Przesyłanie danych dotyczących kont bankowych jest szczególnie narażone na ataki, dlatego niezwykle ważnym jest sprawdzenie, czy system prawidłowo szyfruje dane i czy zostały wykluczone wszelkie możliwości podsłuchu. Kluczowa także jest poprawność przesyłanych danych, aby nie doszło do przekłamań kwot oraz innych danych potrzebnych przy dokonywaniu przelewu. Niezwykle istotne jest też rejestrowanie wszelkich prób nieprawidłowego uzyskania dostępu do tego modułu, aby możliwe było natychmiastowe reagowanie w przypadku prób uzyskania nieautoryzowanego dostępu.

6. testowanie systemu eksperckiego

System ekspercki zawiera zbiór pytań umożliwiających zidentyfikowanie problemu klienta oraz doradzenie mu odpowiedniego rozwiązania. Należy więc sprawdzić sposób doboru reguł przez mechanizm wnioskowania oraz działanie każdej reguły w różnych konkretnych przypadkach wymagających decyzji, rady czy opinii. Mechanizm należy przetestować pod względem łatwości obsługi oraz jednoznaczności odpowiedzi, tak aby użytkownik słabo zaznajomiony z systemem oraz prawem podatkowym nie miał problemu z ustaleniem odpowiedzi na poszczególne pytania. Zmniejszy to możliwość przekazania do konsultanta problemu, który mógłby zostać rozwiązany za pomocą systemu eksperckiego.

10. Podsumowanie

Niniejszy dokument podsumowuje wszelkie aspekty dotyczące projektowania systemu i wszelkich innych czynności koniecznych do wykonania przed jego wdrożeniem. Przedstawione zostały kwestie dotyczące technicznej i wizualnej strony projektu. Dokument zawiera graficzne przedstawienie zbioru klas systemu oraz budowy baz danych. Ukazany został i opisany interfejs systemu dostępny dla poszczególnych jego użytkowników. Poruszone zostały zagadnienia dotyczące optymalizacji systemu, protokołów komunikacyjnych oraz testów poszczególnych modułów, wchodzących w skład projektowanego systemu. Omówiona została także faza wdrożeniowa, gdzie opisano aspekty dotyczące udostępnienia gotowego systemu firmie doradztwa podatkowego. Dzięki temu system jest gotowy do implementacji nie pozostawiając wątpliwości co do budowy i wymagań funkcjonalnych.

System informatyczny obsługi firmy doradztwa podatkowego

Strona 24 z 24

---