ODPOWIEDZI NA ZAPYTANIA Bogatynia, r. Uczestnicy postępowania

Transkrypt

1 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 IZP /281/1981/10 dot. pism z dnia: r r r. ODPOWIEDZI NA ZAPYTANIA Bogatynia, r. 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 , Nr zamówienia: IZP /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 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 r. 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 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 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?

2 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 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 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 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 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.

3 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 ad. pytania 8: Zamawiający podtrzymuje zapisy punktu 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 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 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

4 do eksploatacji uŝytkowej do dnia Pytania z dnia r. 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 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 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 lub ad. pytania 2 Wymóg określony w pkt SIW został szczegółowo opisany w pkt 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 lub Pytania z dnia r. 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 i KDE do wersji 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 r. 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

5 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 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 ( 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.

6 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 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.

7 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 / 2. a/a Sprawę prowadzi: Wydział Zamówień Publicznych ul. 1 Maja 29; Bogatynia Komisja Przetargowa Tel wew. 55 POSIADAMY CERTYFIKOWANY PRZEZ PCBC S.A. zamowienia.publiczne@bogatynia.pl SYSTEM ZARZADZANIA JAKOŚCIĄ CERTYFIKAT NR 1418/2/2008