Odpowiedzi 22.24.25.06.10 Wrota Bogatyni

Projekt pn. System elektronicznych usług publicznych w Bogatyni- „Wrota Bogatyni” współfinansowany ze
środków Europejskiego Funduszu Rozwoju Regionalnego w ramach priorytetu nr 2 ”Rozwój społeczeństwa
społeczeństwa informacyjnego na Dolnym Śląsku (Społeczeństwo Informacyjne) Działanie nr
2.2. „Rozwój usług elektronicznych” Regionalnego Programu Operacyjnego dla Województwa
Dolnośląskiego na lata 2007-2013.
ODPOWIEDZI NA ZAPYTANIA
Bogatynia, 30.06.2010r.
IZP.341-14-6/281/1981/10
dot. pism z dnia: 22.06.2010r.
24.06.2010r.
25.06.2010r.
Uczestnicy postępowania
Dotyczy: postępowania prowadzonego w trybie przetargu nieograniczonego na „System elektronicznych usług
publicznych w Bogatyni – „Wrota Bogatyni” współfinansowanego ze środków Europejskiego Funduszu Rozwoju
Regionalnego w ramach priorytetu nr 2 „Rozwój społeczeństwa informacyjnego na Dolnym Śląsku
(Społeczeństwo Informacyjne) Działanie 2.2 „Rozwój usług elektronicznych” Regionalnego Programu
Operacyjnego dla Województwa Dolnośląskiego na lata 2007-2013”, Nr zamówienia: IZP.341-14/10
Zamawiający – Gmina Bogatynia na podstawie art. 38 ust. 1 i 2 ustawy z dnia 29 stycznia
29 stycznia 2004 r. Prawo zamówień publicznych (t. jedn. Dz. U. z 2007 r. Nr 223 poz. 1655 ze zm.) zawiadamia,
Ŝe w trakcie toczącego się postępowania wpłynęły następujące zapytania do treści Specyfikacji Istotnych Warunków
Zamówienia:
Pytania z dnia 22.06.2010r.
Pytanie 1:
Czy UPS ma być przygotowany do przyszłej rozbudowy oraz posiadać pracę z falownika?
Pytanie 2:
Czy UPS powinien być wyposaŜony w system nieciągłego ładowania baterii?
Pytanie 3:
Czy UPS powinien posiadać odczyt parametrów elektrycznych wejścia/wyjścia?
Pytanie 4:
Dla jakiej wartości ma się odnosić parametr „Czas podtrzymania: min. 12 min.” w urządzeniu UPS?
Pytanie 5:
Czy baterie mogą być umieszczone na zewnątrz obudowy UPS?
Pytanie 6:
Czy UPS ma posiadać układy obejścia?
Pytanie 7:
Zamawiający dopuszcza składanie ofert częściowych na pakiety 1 i 2.
Czy w związku z tym wymóg dotyczący pakietu nr 1, a zawarty w SIWZ w punkcie 9.1.1 moŜe brzmieć:
„wykaŜą, Ŝe posiadają wiedzę i doświadczenie, na potwierdzenie których udokumentują wykonanie tj.
zakończenie w ciągu ostatnich trzech lat, a jeŜeli okres prowadzenia działalności jest krótszy - w tym
okresie, co najmniej 1 dostawy wraz z zainstalowaniem i uruchomieniem instalacji technicznych, sprzętu
i oprogramowania dla projektu porównywalnego z zakresem zamówienia, zawartym w pakiecie nr 1”?
Pytanie 8:
Czy moŜna uwaŜać wymóg zawarty w punkcie 9.2. SIWZ (dotyczący tylko pakietu nr 2) podpunkt 9.2.1
za wystarczający,
„wykaŜą, Ŝe posiadają wiedzę i doświadczenie, na potwierdzenie których
udokumentują, iŜ Wykonawca wykonał w okresie ostatnich 3 lat przed upływem terminu składania ofert,
a jeŜeli okres prowadzenia działalności jest krótszy – w tym okresie , co najmniej dwa zamówienia
polegające na dostawie i wdroŜeniu systemu autorstwa Wykonawcy, którego elementem było
oprogramowanie aplikacyjne będące przedmiotem oferty Wykonawcy porównywalne z przedmiotem
zamówienia przynajmniej w zakresie Systemu Elektronicznego Obiegu Dokumentów SEOD oraz
elektronicznej skrzynki podawczej dla co najmniej 120 uŜytkowników lub gdzie wartość projektu
wynosiła co najmniej 500 tys. PLN kaŜda?
Pytanie 9:
Czy zamawiający dopuszcza, by tylko klient poczty wychodzącej był wbudowany w system EOD?
Wbudowany w system klient poczty przychodzącej, stanowi bardzo istotne i bezpośrednie zagroŜenie
sprawnej i wydajnej pracy systemu oraz uŜytkowników poprzez przyjmowanie tzw. poczty niechcianej
(spam).
Pytanie 10:
W nawiązaniu do wymogu zawartego w Załączniku nr 2 do SIWZ, a dotyczącego aplikacji typu CMS Czy zamawiający dopuszcza moŜliwość dokonywania uploadu plików na serwer/do galerii za pomocą
protokołu http, jeśli w ten sposób moŜna równieŜ przesłać wiele plików jednocześnie?
Pytanie 11:
Czy jest moŜliwe, by zamawiający dopuścił, aby pliki były przechowywane na wydzielonym serwerze
plików? Ma to istotny wpływ na wydajność bazy danych, jej pojemność i zdolność do efektywnego
wyszukiwania informacji przez wszystkich uŜytkowników systemu.
Powszechną praktyką, jest trzymanie plików poza silnikiem bazy danych, dlaczego więc forsowane jest
rozwiązanie odwrotne, gdzie jak powszechnie wiadomo, bazy danych nie są idealnym miejscem do
przechowywania duŜych rozmiarem binariów. Dodatkowo przez to wzrasta znacznie, a niepotrzebnie,
obciąŜenie silnika bazy danych. W sytuacji gdy przestanie wystarczać jedna maszyna wraz z przyrostem
danych – powstaje bardzo duŜy problem – konieczność wymiany serwera na mocniejszy, klastrowanie, co
między innymi pociąga za sobą znaczny wzrost kosztów uŜytkowania systemu, takŜe związanych z
licencjami za oprogramowanie, nowym sprzętem oraz konieczną migracją danych.
Czy Zamawiający dopuści rozwiązanie wydajniejsze i nie generujące niepotrzebnych kosztów w którym
pliki przechowywane są na serwerze plików?
Pytanie 12:
Wymóg zamawiającego zawarty w punkcie 2.6.ppkt 4 lit. "e” opisu przedmiotu zamówienia, dotyczący
zarządzania konfiguracją systemu, w tym incydentami i problemami, powinien być prowadzony zgodnie
z odpowiednimi standardami (np. ITIL, ISO 20000. COBI itp.) Czy w opinii Zamawiającego certyfikat
bezpieczeństwa informatycznego oraz bezpieczeństwa informacji, zgodny z normą ISO 27001, jest
certyfikatem zgodnym z wymogami zamawiającego?
Pytanie 13:
Czy wymóg zawarty w punkcie 2.6 podpunkt 4 ,litera „J”, opisu przedmiotu zamówienia, a dotyczący
zezwolenia na wykonywanie zaleŜnego prawa autorskiego, moŜe być anulowany na rzecz wymagań
określonych w literach „I” oraz „K” tegoŜ samego punktu? Interes zamawiającego, dotyczący posiadania
kodów źródłowych, w opisywanych przypadkach, jest naleŜycie w nich chroniony .
Pytanie 14:
Wnioskujemy o rozwaŜenie moŜliwości zmiany zapisu zawartego w punkcie 2.6 podpunkt 2 opisu
przedmiotu zamówienia na: metodologia wdroŜenia po stronie zamawiającego i wykonawcy – PRINCE 2
lub równowaŜna.
Pytanie 15:
Nawiązując do wymogu zamawiającego, zawartego w załączniku nr 2 do SIWZ punkt 2.2.4 dotyczącym
aplikacji CMS, proszę o doprecyzowanie, czy moŜliwość wyboru miejsca w szablonie graficznym, gdzie
mogą być wyświetlane bannery moŜe być ograniczona do kilku wybranych i stałych miejsc wskazanych
przez zamawiającego?
Pytanie 16:
W związku z wymogiem zawartym w SIWZ w punkcie 3.2.2 podpunkt 1 litera „A”, dotyczącym próbki
systemu, czy jest moŜliwe zaprezentowanie materiału w formie prezentacji wizualnej – zrzutów ekranu –
przedstawiających funkcjonalności systemu wraz z ich opisami? Czy zamawiający przewiduje
organizację prezentacji funkcjonalności systemu, prowadzonej bezpośrednio na oferowanym systemie?
Pytanie 17:
Przewidziany termin wykonania zamówienia, dotyczący pakietu nr 2 – do dnia 10.12.2010 r określa czas
niezbędny na wykonanie i dostawę przedmiotu zamówienia. Czy w związku z tym, dostarczona próbka
musi zawierać wszystkie wymagane funkcje i elementy na dzień złoŜenia oferty, skoro czas wykonania
przedmiotu zamówienia jest wielokrotnie dłuŜszy?
Odpowiedzi na wyŜej wymienione pytania:
ad. pytania 1:
UPS ma być przygotowany do przyszłej rozbudowy w układzie pracy równoległej do maksymalnie
czterech jednostek. W przypadku braku komunikacji logicznej urządzenia zapewnią podtrzymanie
zasilania przy zaniku napięcia z sieci (praca z falownika) z równomiernym obciąŜeniem wszystkich
jednostek układu.
ad. pytania 2:
Urządzenie powinno być wyposaŜone w system nieciągłego ładowania baterii. Okres spoczynkowy w
jednym cyklu nie moŜe być krótszy niŜ 14 dni.
ad. pytania 3:
UPS powinien być wyposaŜony w komunikacyjny wyświetlacz LCD z odczytem parametrów
elektrycznych wejścia/wyjścia i komunikatów o stanie pracy UPS w języku polskim.
ad. pytania 4:
Czas podtrzymania ma wynosić co najmniej 12 minut przy obciąŜeniu mocą min. 28kW.
ad. pytania 5:
Urządzenie powinno posiadać baterie umieszczone wewnątrz obudowy (UPS i baterie w jednej
obudowie).
ad. pytania 6:
UPS ma być wyposaŜony w wewnętrzny elektroniczny i w zewnętrzny zintegrowany mechaniczny
serwisowy układ obejściowy oraz fabrycznie montowane kółka, ułatwiające transport i czynności
serwisowe.
ad. pytania 7:
Zamawiający podtrzymuje zapisy punktu 9.1.1.
ad. pytania 8:
Zamawiający podtrzymuje zapisy punktu 9.2.1.
ad. pytania 9:
SEOD musi posiadać wbudowanego klienta zarówno poczty wychodzącej jak i przychodzącej.
ad. pytania 10:
Zamawiający dopuszcza rozwiązanie które pozwali na przesyłanie na serwer plików zgromadzonych we
wskazanym folderze lokalnym bez konieczności ich kaŜdorazowego wybierania za pomocą okien
dialogowych.
ad. pytania 11:
Zamawiający oczekuje, Ŝe pliki bieŜące będą przechowywane przez system w bazie danych SEOD,
natomiast pliki archiwalne mogą być przechowywane poza bazą danych SEOD.
ad. pytania 12:
Certyfikat bezpieczeństwa informatycznego i informacji iso 27001 spełnia podany przez zamawiającego
wymóg.
ad. pytania 13:
Zamawiający podtrzymuje wymienione wymaganie.
ad. pytania 14:
Zamawiający dopuszcza metodologię wdroŜenia równowaŜną do PRINCE 2.
ad. pytania 15:
Aplikacja CMS musi zapewniać moŜliwość dowolnego modelowania strony w tym dowolne
zdefiniowanie miejsca prezentacji banerów, treści, ikon, grafik itp. Nie dopuszcza się rozwiązania
narzucającego konkretny (zdefiniowany przez Wykonawcę) rozkład strony.
ad. pytania 16:
Zamawiający w punkcie 3.2.2 SIWZ podpunkt 1 litera „a” jednoznacznie i wyczerpująco opisał, iŜ Ŝąda
„Próbki systemu (na nośniku elektronicznym, płytach CD, DVD) i zrzuty ekranowe”.
Próbka winna zawierać obszary merytoryczne oprogramowania aplikacyjnego w zakresie:
- SEOD;
- Wrota Bogatyni;
- Portal Informacyjny w szczególności moduł CMS;
- Biuletyn Informacji Publicznej.
Próbka powinna być przygotowana w formie maszyny wirtualnej zawierającej serwer bazy danych,
serwer aplikacji umoŜliwiającej pracę w systemie przez przeglądarkę internetową. Wykonawca powinien
dostarczyć instrukcję uruchomienia próbki wraz z działającymi loginami i hasłami uŜytkowników.
Zamawiający nie przewiduje organizacji prezentacji funkcjonalności systemu. Dostarczona wraz z ofertą
instrukcja uruchomienia próbki powinna zapewnić moŜliwość weryfikacji bez udziału Wykonawcy.
ad. pytanie 17:
Zgodnie z zapisami SIWZ, próbka winna zawierać obszary merytoryczne oprogramowania aplikacyjnego
w zakresie:
- SEOD;
- Wrota Bogatyni;
- Portal Informacyjny w szczególności moduł CMS;
- Biuletyn Informacji Publicznej.
Wykonawca jest zobowiązany do dostarczenia całości oprogramowania, zainstalowania,
przeniesienia dotychczas eksploatowanych danych w formie elektronicznej i uruchomienia
do eksploatacji uŜytkowej do dnia 10.12.2010.
Pytania z dnia 24.06.2010r.
Pytanie 1.
Mamy rozumieć, Ŝe w przypadku Konsorcjum wymóg „dostaw i udroŜnienia systemu autorstwa
Wykonawcy” odniósł się do łącznego potencjału Wykonawców wspólnie ubiegających się o zamówienie
i zostanie spełniony gdy kaŜdy z Wykonawców – Członem Konsorcjum wykaŜe po jednej dostawie i
wdroŜeniu systemu swojego autorstwa, czy tak?
Pytanie 2.
Czy zamawiający wprowadzając wymóg określony w pkt 9.2.1 SIWZ dopuszcza jego rozumienie w ten
sposób, Ŝe wymóg ten zostanie spełniony gdy Wykonawca zgodnie z art. 26 ust. 2b p.z.p. będzie polegać
na wiedzy i doświadczeniu innych podmiotów w zakresie dostaw i wdroŜenia systemu autorstwa
podmiotu zobowiązującego się do udostępnienia wiedzy i doświadczenia?
Odpowiedzi na wyŜej wymienione pytania:
ad. pytania 1
Nie – gdyŜ zasada udokumentowania doświadczenia zostały szczegółowo opisane w pkt. 10.4.3. SIWZ
gdzie stwierdza się –„ Wykonawca występujący wspólnie zobowiązany jest udokumentować
doświadczenie w wykonywaniu robót powierzonych mu do wykonania. Wykonawcy występujący
wspólnie muszą wykazać, Ŝe przynajmniej jeden z nich samodzielnie spełnia warunek dotyczący
doświadczenia określonego w punkcie 9.1.1. lub 9.2.1.”
ad. pytania 2
Wymóg określony w pkt. 9.2.1 SIW został szczegółowo opisany w pkt. 10.4.3 SIWZ w którym zapisano Wykonawca występujący wspólnie zobowiązany jest udokumentować doświadczenie w wykonywaniu
robót powierzonych mu do wykonania. Wykonawcy występujący wspólnie muszą wykazać, Ŝe
przynajmniej jeden z nich samodzielnie spełnia warunek dotyczący doświadczenia określonego w
punkcie 9.1.1. lub 9.2.1.
Pytania z dnia 25.06.2010r.
Pytanie 1.
Pod kontrolą jakich systemów operacyjnych mogą działać stacje robocze na których będzie
wykorzystywany SEOD?
Pytanie 2.
Czy Zamawiający dopuszcza, aby narzędzie do definiowania formularzy zostało zrealizowane jako
aplikacja typu deskop?
Pytanie 3.
Wracając do wymagania 142 Pakietu 2 – Wskazują Państwo, Ŝe system SEDO powinien przechowywać
dane w bazie danych. Ponadto wskazują Państwo, Ŝe pliki dokumentów powinny być przechowywane w
repozytorium poza bazą danych. Czy poza bazą danych ma być przechowywane repozytorium wszystkich
plików (w tym treść dokumentów bieŜących), czy tylko plików archiwalnych, czy teŜ miejsce
przechowywania tych plików nie ma dla Państwa znaczenia?
Odpowiedzi na wyŜej wymienione pytania:
ad. pytania 1:
System ma umoŜliwiać pracę na stacjach roboczych działających pod kontrolą systemów Windows od
wersji XP oraz systemu Linux z jądrem do wersji 2.6.26-21 i KDE do wersji 3.5.9.
ad. pytania 2:
Zamawiający dopuszcza oby narzędzie do definiowania formularzy elektronicznych nie było dostępne
przez przeglądarkę internetową.
ad. pytania 3:
Zamawiający oczekuje, Ŝe pliki bieŜące będą przechowywane przez system w bazie danych SEDO,
natomiast pliki archiwalne mogą być przechowywane poza bazą danych SEOD.
Pytania z dnia 25.06.2010r.
Pytanie nr 1.
W punkcie 2.3. SIWZ „ Wymagania stawiane wobec zamawiającego oprogramowania aplikacyjnego” w
punkcie nr 8 Zamawiający określił następujące wymagania względem systemu: oprogramowanie
aplikacyjne posiada repozytorium plików, przechowujące pliki w bazie danych. Nie dopuszcza się
przechowywania plików na serwerze plików.
Ten zapis w bardzo duŜym stopniu ogranicza konkurencję na rynku poprzez drastyczne zmniejszenie
liczby dostawców oprogramowania poniewaŜ większość systemów oraz aplikacji przechowuje pliki w
repozytorium dyskowym. RównieŜ najwięksi producenci oprogramowania zarządzania dokumentami
stosują repozytoria dyskowe z uwagi na ich bezpieczeństwo i najwyŜszą wydajność i elastyczność.
Przechowywanie plików w repozytorium dyskowym jest najtańszym z punktu widzenia utrzymania oraz
najszybszym z punktu widzenia dostępu do danych rozwiązaniem gwarantującym jednocześnie
najwyŜszy moŜliwy poziom bezpieczeństwa danych. W przypadku przechowywania plików w
repozytorium dyskowym dostęp do plików ma jedynie administrator (identycznie jak
w przypadku repozytorium bazy danych). śaden inny uŜytkownik nie ma dostępu do repozytorium
plików bezpośrednio, a jest to moŜliwe jedynie poprzez oprogramowanie aplikacyjne (identycznie jak w
przypadku repozytorium bazy danych). NaleŜy równieŜ uwzględnić łatwość integracji wielu róŜnych
systemów poprzez uŜycie repozytorium dyskowego, które jest uniwersalne i udostępnia pliki bez
konieczności uŜycia dodatkowych aplikacji (ang. Connector), brokerów pośredniczących podczas
dostępu do danych (plików). W przypadku integracji z repozytorium bazy danych konieczne jest uŜycie
dodatkowych aplikacji zmniejszających ogólną wydajność systemu.
Kolejnym argumentem przemawiającym na za repozytorium dyskowym jest znacznie większa wydajność
podczas zapisu informacji, co przekłada się bezpośrednio na znacznie wyŜszy komfort pracy
uŜytkowników. W przypadku repozytorium bazy danych kaŜdy zapis pliku powoduje zablokowanie bazy
danych na czas zapisu co ma duŜe znaczenie nawet w przypadku plików o rozmiarze kilkuset kilobajtów.
Taki problem nie istnieje w przypadku repozytorium dyskowego.
W przypadku repozytorium dyskowego koszta rozbudowy będą znacznie niŜsze gdyŜ jest to powiązane
jedynie z zakupem dysków twardych. W przypadku repozytorium bazy danych, w celu utrzymania
wydajności na komfortowym dla uŜytkowników poziomie konieczne jest często partycjonowanie bazy
danych, co wymaga zakupu drogich licencji silnika bazy danych (koszt około 20000 tysięcy złotych dla
procesora fizycznego lub rdzenia procesora).
Doskonałym przykładem zastosowania repozytorium dyskowego jest System Zarządzania Treścią (ang.
CMS Content Management System) eZ Publish zastosowany do budowy posiadanej przez Państwa strony
WWW, gdzie wszystkie elementy przechowywane są w repozytorium opartym o system plików.
W związku z powyŜszym zwracamy się z prośbą o dopuszczenie uŜycia repozytorium dyskowego w celu
przechowywania plików w dostarczonym oprogramowaniu. Poprzez tę modyfikację Zamawiający
zapewni sobie większą konkurencyjność ofert w postępowaniu, co moŜe bezpośrednio wpłynąć na
uzyskanie niŜszej ceny na oprogramowanie dostarczone w ramach postępowania.
Pytanie nr 2.
W punkcie 2.3. SIWZ „Wymagania stawiane wobec zamawianego oprogramowania aplikacyjnego” w
punkcie numer 19 Zamawiający określił następujące wymagania względem systemu:
„oprogramowanie aplikacyjne musi być zbudowane w oparciu o motor bazy danych Oracle lub
równowaŜny i stworzony w narzędziach autorstwa producenta bazy danych przynajmniej w zakresie
modułów SEOD”.
Ten zapis w bardzo duŜym stopniu ogranicza konkurencję na rynku poprzez drastyczne zmniejszenie
liczby dostawców. Twórcy oprogramowania celowo stosują technologie umoŜliwiające prace z wieloma
silnikami baz danych przez co wzrasta elastyczność wytwarzanych przez nich aplikacji. Większość
producentów zajmujących się tworzeniem oprogramowania tworzy je w sposób umoŜliwiający
współpracę w kilkoma róŜnymi silnikami baz danych. NaleŜy podać przykład aplikacji utworzonych w
technologii NET, której autorem jest firma Microsoft współpracującej doskonale z bazą danych Oracle
My SQL oraz Microsoft SQL lub aplikacji napisanej w technologii PHP zalecanej do współpracy z bazą
danych My SQL oraz równie dobrze współpracującej z silnikami baz danych Oracle oraz Microsoft SQL.
Bezsprzecznie korzystne dla Zamawiającego jest dopuszczenie dostawy oprogramowania, które nie jest
stworzone w technologii oferowanej przez np.: Oracle lub Microsoft (firmy te posiadają własne produkty
– silniki bazy danych ), ale umoŜliwiającej współpracę z tą bazą lub inną, równowaŜną. Zestawienie
technologii aplikacyjnych bazodanowych pochodzących od róŜnych producentów jest najbardziej
powszechne pośród twórców oprogramowania, a najbardziej powszechnym rozwiązaniem jest
zestawienie technologii PHP oraz MySQL. Doskonałym przykładem zastosowania tej technologii jest
System Zarządzania Treścią (ang. CMS Content Management System) eZ Publish zastosowany do
budowy posiadanej przez Państwa strony WWW, dla którego certyfikowaną platformą jest połączenie
ww. technologii (http://ez.no/ezpublish/reguirements Certified Platform).
W związku z powyŜszym zwracamy się z prośbą o dopuszczenie moŜliwości dostawy oprogramowania,
które zbudowane jest w oparciu o nowoczesne technologie szeroko stosowane przez producentów
oprogramowania, posiadające duŜe wsparcie wśród ich producentów.
Zwracamy się równieŜ z zapytaniem jaki motor bazy danych Zamawiający uwaŜa za równowaŜny w
stosunku do Oracle.
Odpowiedzi na wyŜej wymienione pytania:
ad. pytania 1:
Zamawiający oczekuje, Ŝe pliki bieŜące będą przechowywane przez system w bazie danych SEOD, natomiast pliki
archiwalne mogą być przechowywane poza bazą danych SEOD, np. przy zastosowaniu repozytorium plików.
ad. pytania 2:
Zamawiający podtrzymuje zapisy punktu 2.3 SIWZ ppkt. 8.
Za równowaŜny z Oracle Zamawiający uwaŜa motor bazy danych spełniający wymagania:
1 Oprogramowanie bazy danych powinno być dostępne na współczesne 64-bitowe platformy Unix
(HP-UX dla procesorów PA-RISC i Itanium, Solaris dla procesorów SPARC i Intel/AMD, IBM
AIX), Intel/AMD Linux 32-bit i 64-bit, MS Windows 32-bit i 64-bit. Serwer bazy danych
powinien oferować identyczą funkcjonalność na ww. platformach.
2. Oprogramowanie serwera bazy danych powinno zapewnić niezaleŜność platformy systemowej
dla oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych.
3. Powinna istnieć moŜliwość przenoszenia (migracji) struktur bazy danych i danych pomiędzy
wymienionymi w pkt 1. platformami bez konieczności rekompilacji aplikacji bądź migracji
środowiska aplikacyjnego.
4. Serwer bazy danych powinien przetwarzać dane z zachowaniem ich spójności i maksymalnego
moŜliwego stopnia współbieŜności.
5. Powinna istnieć moŜliwość uruchomienia niezaleŜnej transakcji wewnątrz transakcji nadrzędnej.
6. MoŜliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z
serwera aplikacyjnego do serwera bazy danych.
7. Oprogramowanie serwera bazy dabych powinno wspierać standard XA (określający specyfikację
rozproszonego przetwarzania transakcji).
8. Wsparcie standardu JDBC 3.0.
9. Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym.
10. Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar
(liczbę wierszy).
11. MoŜliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT,
UPDATE, DELETE) wykonywanej na tabeli, na poziomie kaŜdego wiersza modyfikowanego
przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji
DDL, start serwera, stop serwera, próba zalogowania uŜytkownika, wystąpienie specyficznego
błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umoŜliwiać oprogramowanie
obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw.
niemodyfikowalnych widokach.
12. W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez
motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML
musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu
musi odzwierciedlać chwilę przed rozpoczęciem instrukcji DML, podczas przetwarzania której
wystąpił ww. błąd lub wyjątek. W przypadku gdy triggery wykonywane są kaskadowo
(instrukcja DML na pierwszej tabeli powoduje uruchomienie triggera, który modyfikuje dane w
drugiej tabeli, która ma trigger modyfikujący dane w trzeciej tabeli) to wyjątek występujący na
dowolnym trigerze na dowolnym poziomie zagnieŜdŜenia powinien spowodować wycofanie
transakcji do chwili przed rozpoczęciem pierwszej instrukcji DML.
13. Powinna istnieć moŜliwość autoryzowania uŜytkowników bazy danych za pomocą rejestru
uŜytkowników załoŜonego w bazie danych.
14. Baza danych powinna umoŜliwiać wymuszanie złoŜoności hasła uŜytkownika, narzucanie czasu
Ŝycia hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku
przekroczenia limitu nieudanych logowań.
15. Przywileje uŜytkowników bazy danych powinny być określane za pomocą przywilejów
systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo do
tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu /
modyfikacji tabeli, wykonania procedury). Baza danych powinna umoŜliwiać nadawanie ww.
przywilejów za pośrednictwem mechanizmu grup uŜytkowników / ról bazodanowych. W danej
chwili uŜytkownik moŜe mieć aktywny dowolny podzbiór nadanych ról bazodanowych.
16. MoŜliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer bazy
danych.
17. MoŜliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu
odpowiedniej liczby kopii nadmiarowych - stosownie do załoŜonej polityki nadmiarowości
backup'ów. MoŜliwość integracji z powszechnie stosowanymi systemami backupu (Legato,
Veritas, Tivoli, OmniBack, ArcServe itd). Wykonywanie kopii bezpieczeństwa powinno być
moŜliwe w trybie offline oraz w trybie online.
18. MoŜliwość wykonywania kopii bezpieczeństwa w trybie online (hot backup).
19. Odtwarzanie powinno umoŜliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź
cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili
wystąpienia awarii odtwarzaniu moŜe podlegać cała baza danych bądź pojedyncze pliki danych.
20. W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz
danych mogą być dostępne dla uŜytkowników.
Niniejsze odpowiedzi stanowi integralną część SIWZ.
Z powaŜaniem
Burmistrz
Miasta i Gminy Bogatynia
mgr Andrzej Grzmielewicz
Otrzymują:
1. Uczestnicy postępowania /www.bogatynia.pl/
2. a/a
Sprawę prowadzi:
Komisja Przetargowa
Tel. 0 75 77 33 961 wew. 55
Wydział Zamówień Publicznych
ul. 1 Maja 29; 59-920 Bogatynia
POSIADAMY CERTYFIKOWANY PRZEZ PCBC S.A.
e-mail: [email protected] SYSTEM ZARZADZANIA JAKOŚCIĄ – CERTYFIKAT NR 1418/2/2008