Procedury dostawy, akceptacji i odbioru produktów

Wielkość: px
Rozpocząć pokaz od strony:

Download "Procedury dostawy, akceptacji i odbioru produktów"

Transkrypt

1 Załącznik nr 17 do Umowy nr... z dnia... Procedury dostawy, akceptacji i odbioru produktów I. Definicje Pojęcie Akceptacja Akceptacja z uwagami Awaria Baza Wiedzy Błąd Błąd regresji Błąd Blokujący Określenie znaczenia Odbiór jakościowy produktu ocena dostawy pod względem merytorycznym przeprowadzona przez specjalistów z dziedziny, dla której wykonywany jest produkt. Stwierdzenie zgodności z kryteriami akceptacji produktu. Podpisanie Protokołu Akceptacji. Dostarczony produkt nie spełnia wszystkich uzgodnionych z Zamawiającym kryteriów jakości. Akceptacja z uwagami stanowi warunkowe przyjęcie produktu przy deklaracji Wykonawcy wykonania poprawek w ustalonym terminie. Termin dostawy uważa się za dotrzymany. Awaria powoduje niefunkcjonowanie całego Systemu ZEFIR 2 lub jednego z jego komponentów. Jeden z modułów narzędzia klasy SD, który wykorzystywany jest przez operatorów Service Desk do rozwiązywania wpływających incydentów. Zawiera zaakceptowane rozwiązania oraz obejścia powtarzających się incydentów. Skategoryzowany incydent lub problem o określonym priorytecie, który ze względu na ograniczenia w poprawnym działaniu Systemu ZEFIR2 określany jest jako: Awaria Błąd Blokujący Błąd Poważny Błąd Średni Błąd Drobny Błędne działanie z elementami oprogramowania wcześniej odebranymi. Problem w oprogramowaniu Systemu ZEFIR 2, który uniemożliwia w ogóle wykonanie funkcjonalności programu, lub niedziałająca funkcjonalność Systemu ZEFIR 2 powodująca niemożność wykonywania przez Zamawiającego i jednostki 1

2 Błąd Poważny Błąd Średni Błąd Drobny COTS (Oprogramowanie COTS) DIP Dni robocze Help Desk I linia wsparcia przezeń nadzorowane obowiązków wynikających z przepisów prawa polskiego i UE za pośrednictwem Systemu ZEFIR 2 oraz innych działań wspierających wykonywanie tych obowiązków. Problem polegający na wystąpieniu błędu replikacji danych, komunikacji między usługami lub innego rozwiązania technicznego zaimplementowanego w Systemie, który powoduje utratę spójności danych w Systemie ZEFIR 2. Problem w oprogramowaniu Systemu ZEFIR 2 uniemożliwiający w sposób bezpośredni wykonanie funkcji programu wymuszający na użytkownikach/administratorach Systemu ZEFIR 2 jakąkolwiek zmianę, niezgodną z dokumentacją, sposobu korzystania z Systemu ZEFIR 2. Problem w oprogramowaniu Systemu ZEFIR 2, który nie stanowi zagrożenia wykonania funkcji programu, ale utrudnia wykonanie pojedynczych operacji w Systemie, bądź powoduje konieczność wykonania dodatkowych czynności w celu wykonania funkcjonalności programu, lub problem nieprawidłowego wyświetlania danych (m.in. na ewidencjach i listach dokumentów). Problem w oprogramowaniu Systemu ZEFIR 2, który nie stanowi zagrożenia wykonania funkcji programu, istnieje jego obejście poprzez skorzystanie z innych funkcji, ale utrudnia to jej wykonanie i wpływa negatywnie na komfort pracy użytkownika, związany z interfejsem użytkownika, kolejnością wykonania operacji, rozmiarem, kolorem ekranu i czcionki, a także inne błędy nie powodujące powstawania wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika. Oprogramowania typu Commercial of the Shelf Software - Powszechnie dostępne oprogramowanie standardowe, wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, dostępnego w systemie sprzedaży hurtowej oraz detalicznej. Dokument Inicjujący Projekt. Dni od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy. Projekt Programu e-cło wdrożenia jednolitej platformy udzielania informacji i pomocy w rozwiązywaniu problemów dla użytkowników Programu. Zespół Help Desku przyjmujący zgłoszenia, zajmujący się rejestracją zgłoszenia (Incydentu), klasyfikacją, wstępnym ustaleniem priorytetu, wstępną diagnozą i eskalacją (gdy jest konieczna) do II linii wsparcia. I linia wsparcia będzie zorganizowana w ramach Projektu Help 2

3 II linia wsparcia III linia wsparcia IC Incydent INFRA Komponent Merytoryczne Centrum Kompetencyjne (MCK) Metodyka szkoleń train the trainers Narzędzie klasy SD Odbiór ilościowy Odbiór jakościowy Desk (jeden z projektów Programu e-cło) Zespół Help Desku przyjmujący zgłoszenia po I linii wsparcia. Każdy z systemów objętych systemem Help Desk posiada własny zespół II linii wsparcia. II linia wsparcia diagnozuje zgłoszenia oraz eskaluje (gdy jest to konieczne) do III linii wsparcia. II linia wsparcia będzie zorganizowana w ramach Merytorycznego Centrum Kompetencyjnego Systemu ZEFIR 2 III linia wsparcia diagnozuje zgłoszenia oraz wprowadza zmiany w systemie gdy jest to konieczne. W przypadku systemu Help Desk zazwyczaj będzie to Wykonawca systemu bądź inny podmiot zewnętrzny świadczący usługi wsparcia dla Systemu. Izba Celna. Każde zdarzenie, które nie jest częścią standardowego działania Systemu. Projekt Programu e-cło przewidujący przygotowanie, standaryzację i sukcesywne dostarczanie infrastruktury technicznej dla pozostałych projektów Programu. Część systemu informatycznego, wyróżniona logicznie ze względu na realizację określonych funkcji biznesowych Komórka organizacyjna Służby Celnej zarządzająca usługami/systemami informatycznymi Systemu Informacyjnego Służby Celnej w zakresie funkcjonalnym (merytorycznym), technicznym (administracja informatyczną platformą programową) Formuła szkolenia stosowana, w dużych grupach polegająca na przeszkoleniu trzonu osób przyszłych trenerów, które stają się trenerami dla kolejnych grup użytkowników z możliwością powielania schematu, gdzie kolejne przeszkolone grupy stają się trenerami. Narzędzie klasy Service Desk jest to System teleinformatyczny dostarczony w ramach projektu Help Desk, działający zgodnie z ITIL v.3.0, obsługujący procesy biznesowe: Help Desk, Zarządzania Incydentem, Zarządzania Problemem, Zarządzania Usługami/wnioskami,zarządzania Bazą Wiedzy. System jest dostępny dla użytkowników 24/7/365 Odbiór wstępny dostawy produktu. Stwierdzenie, czy dostawa zawiera wszystkie wymagane elementy. Podpisanie Protokołu Dostawy. Odbiór merytoryczny (akceptacja) polega na zweryfikowaniu, czy produkt spełnia wymagania jakościowe. Dokonanie odbioru jakościowego potwierdzane jest Podpisaniem Protokołu Akceptacji. 3

4 Odbiór / Odbiór formalny Odrzucenie Problem Projekt Produkt Przypadek testowy Scenariusz testowy SI SC Odbiór ostateczny produktu. Potwierdzenie przez osobę upoważnioną, że wykonawca spełnił wymagania stawiane przed nim w umowie dla tego produktu. Podpisanie Protokołu Odbioru Produktu bez zastrzeżeń. Dostarczony produkt nie spełnia uzgodnionych z Zamawiającym kryteriów jakości, a zespół akceptacyjny przygotował zestaw uwag do ocenianego produktu. Kierownicy projektu obu stron ustalają nowy termin dostawy produktu. Termin dostawy uważa się za niedotrzymany. Nieznana przyczyna jednego lub wielu incydentów. Projekt wdrożenia Zintegrowanego Systemu Poboru Należności i Rozrachunków z UE i Budżetem ZEFIR 2. Projekt Programu e- Cło. Wszystkie elementy, które powstały w wyniku realizacji niniejszej umowy, m.in. dokumentacja, oprogramowanie, kody źródłowe, szkolenia. Zbiór danych wejściowych, warunków początkowych oraz oczekiwanych wyników utworzony, aby wykonać określony scenariusz testowy w systemie albo, aby zweryfikować zgodność z określonym wymaganiem. Sekwencyjny opis zadań, operacji, funkcji, jakie należy wykonać, aby obsłużyć procesy użytkownika przy pomocy systemu. Może opisywać pojedyncze funkcje lub kompleksowe procesy systemu. System Informacyjny Służby Celnej SIWZ Specyfikacja Istotnych Warunków Zamówienia. System Ilekroć mowa o Systemie dotyczy to Systemu ZEFIR 2. Środowisko testowe Środowisko testowe u Zamawiającego. Odzwierciedla środowisko Zamawiającego produkcyjne i służy do testowania systemu zarówno indywidualnie jak i we współpracy z innymi systemami. Środowisko testowe Środowisko testowe posiadane przez Wykonawcę w celu Wykonawcy testowania systemu na etapie produkcji. Techniczne Centrum Kompetencyjne (TCK) Testy akceptacyjne Komórka organizacyjna Służby Celnej zarządzająca infrastrukturą i systemami infrastrukturalnymi na rzecz usług/systemów informatycznych Systemu Informacyjnego Służby Celnej Testy wykonywane przez Zamawiającego w środowisku testowym Zamawiającego przy wsparciu Wykonawcy. Celem testów jest weryfikacja i formalne potwierdzenie zgodności testowanego systemu z zawartą wcześniej Umową pomiędzy Zamawiającym a Wykonawcą. 4

5 Testy systemowe Testy otwarte Test poinstalacyjny Testy utrzymania i rozwoju Użytkownik końcowy Testy wykonywane w środowisku testowym Wykonawcy w trakcie produkcji systemu przy możliwym udziale Zamawiającego lub w środowisku testowym Zamawiającego. Wykonanie testów ma zapewnić Zamawiającemu możliwość oceny funkcjonalności przygotowanego systemu, wykrycia błędów w systemie na wczesnym etapie jego produkcji i zgłaszania uwag, zmian i uzupełnień do założonej funkcjonalności. Testy wykonywane ad hoc w dowolnym czasie, bez formalnego uzgodnienia scenariuszy testowych i wcześniejszego ich zaplanowania. W wypadku wykonania takiego testu jego przebieg należy opisać na formularzu scenariusza testowego i przypadku testowego. Test stwierdzający, że instalacja jest kompletna i aplikacja uruchamia się poprawnie. Testy realizowane po uruchomieniu produkcyjnym systemu w okresie utrzymania i rozwoju systemu. Testy te zawierają między innymi testy regresywne. Osoba po stronie Zamawiającego wykorzystująca w rzeczywistości daną funkcjonalność Systemu Funkcjonariusz celny/pracownik administracji celnej zatrudniony w jednostkach resortu finansów. Użytkownik wewnętrzny Wykonawca Wykonawca Systemu ZEFIR 2 ZEFIR 2 Zintegrowany system poboru należności i rozrachunków z UE i budżetem ZEFIR 2. Projekt Programu e-cło. Zespół Akceptacyjny Zespół ekspertów dziedzinowych, powołany przez Kierownika Zespół Testowy projektu do oceny jakościowej produktu lub testów systemu. 5

6 II Procedura dostawy, akceptacji i odbioru oprogramowania 1. Przed realizacją procedury dostawy, akceptacji i odbioru oprogramowania muszą być wykonane u Wykonawcy następujące czynności wstępne poprzedzające dostawę oprogramowania: a) przygotowane i udokumentowane środowisko testowe Wykonawcy, b) wykonana instalacja dostarczanej wersji oprogramowania w środowisku testowym Wykonawcy, c) przeprowadzony test poinstalacyjny, d) załadowane dane testowe w środowisku testowym Wykonawcy, e) przeprowadzone z wynikiem pozytywnym testy wewnętrzne Wykonawcy, z których wynika, że oprogramowanie spełnia uzgodnione kryteria jakości. Procedura przeprowadzania testów wewnętrznych Wykonawcy zostanie określona w ramach PJP. Najpóźniej na 3 dni robocze przed terminem dostawy produktu Wykonawca zobowiązany jest poinformować Kierownika Projektu Zamawiającego o planowanej dostawie i zgłosić, że oprogramowanie jest gotowe do przeprowadzenia testów przez Zamawiającego. Zgłoszenie następuje w formie elektronicznej lub pisemnej. Podstawą zgłoszenia jest raport z testów wewnętrznych Wykonawcy, z którego wynika, że oprogramowanie spełnia uzgodnione kryteria jakości. Procedura przeprowadzania testów wewnętrznych Wykonawcy zostanie określona w PJP. Wykonawca zobowiązany jest dostarczyć oprogramowanie wraz z kodami źródłowymi oraz dokumentacją dotyczącą dostarczanego oprogramowania. W trakcie wdrożenia oraz w niektórych przypadkach, a zwłaszcza w sytuacjach, gdy dostarczane oprogramowanie w sposób znaczny modyfikuje lub oddziaływuje na dotychczasową architekturę, konfigurację lub funkcjonalność Systemu, Wykonawca przeprowadzi testy systemowe z udziałem Użytkownika końcowego. Testy systemowe przeprowadzane są na wniosek Wykonawcy albo na żądanie Kierownika Projektu Zamawiającego wystosowane co najmniej 30 dni przed planowanym terminem dostawy. Przed ich przeprowadzeniem Wykonawca przygotowuje projekt Planu Testów oraz Scenariusze Testów, które podlegają akceptacji przez Kierownika Projektu Zamawiającego. Jeżeli przeprowadzane były testy systemowe oprócz Raportu z testów wewnętrznych do dostawy produktu należy dołączyć Raport z testów systemowych. Obowiązki Wykonawcy w zakresie przygotowania Testów Systemowych: - przygotowanie szczegółowego harmonogramu dla iteracji testów - uzgodnienie ostatecznego zakresu testów, 6

7 - aktualizacja scenariuszy testów, - przygotowanie przypadków testowych, - przygotowanie danych testowych, - przygotowanie raportu z testów, - określenie i przygotowanie środowiska testowego, - załadowanie danych testowych, - instalacja oprogramowania w środowisku testowym, - przeprowadzenie testu instalacji/konfiguracji. 2. Odbiór ilościowy polega na weryfikacji przez Zamawiającego, czy dostawa zawiera wszystkie wymagane elementy. Odbiór ilościowy produktów oprogramowania dokonywany jest dla każdej dostawy. Wykonawca przekazuje Kierownikowi Projektu Zamawiającego produkt wraz z Protokołem Dostawy, do którego załącznikami są: wersja instalacyjna oprogramowania na nośnikach CD, lub innych uzgodnionych z właściwym Kierownikiem, oznaczonych nazwą systemu i podsystemu, numerem wersji i datą dostawy, instrukcja instalacji dostarczonego oprogramowania, protokół z testów wewnętrznych Wykonawcy dostarczonego oprogramowania, protokół z testów poinstalacyjnych realizowanych w Środowisku testowym Wykonawcy, protokół z testów systemowych, o ile takie były przeprowadzane, biuletyny zmiany do dokumentacji technicznej i użytkowej w zakresie związanym z dostarczanym produktem instrukcja użytkownika, lub podręcznik dla dostarczanego oprogramowania, dokumentacja techniczna w zakresie wymaganym dla zakresu dostawy oprogramowania. Kierownik Projektu Zamawiającego w terminie 2 dni roboczych od momentu dostawy weryfikuje kompletność dostawy zrealizowanej przez Wykonawcę. Weryfikacja obejmuje sprawdzenie prawidłowości wypełnienia Protokołu Dostawy i dostarczenia wszystkich elementów dostawy wyspecyfikowanych na Protokole Dostawy. Potwierdzeniem dokonania odbioru ilościowego dostawy jest podpisanie Protokołu Dostawy przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. Nie dopuszcza się dokonania odbioru ilościowego z uwagami. W przypadku stwierdzenia nieprawidłowości dostawa podlega bezwarunkowemu odrzuceniu, a ponowna dostawa powinna nastąpić w terminie nie dłuższym niż 7 dni roboczych od daty odrzucenia dostawy. 7

8 3. Odbiór jakościowy (merytoryczny) polega na zweryfikowaniu i potwierdzeniu przez zespół odbioru powołany przez Kierownika Projektu czy produkt spełnia wymagania jakościowe i kryteria akceptacji określone przez Zamawiającego poniżej w Tabeli 1 oraz na sprawdzeniu czy: oprogramowanie powstałe na skutek realizacji obszaru zmiennego umowy, zostało wykonane, zgodnie z wymaganiami określonymi przez Zamawiającego we Wniosku Zmiany, oprogramowanie powstałe na skutek usuwania wady zostało wykonane zgodnie z architekturą systemu, i nie zmienia jego funkcjonalności, a także sposobu korzystania z niego. W ramach ww. odbioru produkty akceptowane są w wyniku testów akceptacyjnych po stronie Zamawiającego. Kierownik Projektu Wykonawcy wraz z dostawą produktu dostarcza Kierownikowi Projektu Zamawiającego Plan Testów Akceptacyjnych. Zamawiający może w ciągu 3 dni roboczych od otrzymania Planu wprowadzić swoje uwagi do dokumentu i przekazać je pisemnie Wykonawcy. Dla uwag niezrealizowanych Wykonawca winien pisemnie podać uzasadnienie ich odrzucenia, niemniej decydujące jest stanowisko Kierownika Projektu Zamawiającego. Decyzja Zamawiającego w kwestii odbioru jakościowego oprogramowania powinna zapaść w terminie 20 dni roboczych licząc od dnia przystąpienia do odbioru. W wypadku gdy termin ten nie jest możliwy do dotrzymania Kierownicy Projektów Zamawiającego i Wykonawcy mogą uzgodnić przedłużenie terminu odbioru. Wykonawca może uczestniczyć w pracach komisji odbioru. Podstawą do podjęcia decyzji w kwestii odbioru jakościowego oprogramowania jest Raport z testów akceptacyjnych, który sporządzany jest w 3 egzemplarzach. Jeden egzemplarz dla Kierownika Projektu Zamawiającego, dwa dla Kierownika Projektu Wykonawcy.. Możliwe są następujące decyzje dotyczące odbioru jakościowego oprogramowania: a) Akceptacja bez uwag - jeśli oprogramowanie spełnia kryteria jakości, które zostały zamieszczone poniżej w Tabeli nr 1. W takim przypadku sporządzany jest Protokół Akceptacji Produktu, bez uwag, z rekomendacją dokonania odbioru formalnego, jeżeli dostarczone oprogramowania zawiera wady o dopuszczalnym w kryteriach jakości poziomie, stwierdzone wady powinny zostać usunięte w terminach i przy zastosowaniu procedur dotyczących 8

9 usuwania wad. b) Akceptacja z uwagami - jeśli dostarczony produkt nie spełnia określonych kryteriów jakości, jednakże odchylenie od tych kryteriów są akceptowalne z punktu widzenia Zamawiającego. Decyzję w tej mierze podejmuje Kierownik Projektu Zamawiającego mając na względzie zwłaszcza nieprzerwane i prawidłowe działanie najczęściej wykorzystywanych przez użytkowników funkcjonalności podsystemu. W takim wypadku sporządzany jest Protokół Akceptacji Produktu, z uwagami. Nie jest on równoznaczny z rekomendacją do odbioru końcowego, która może zostać udzielona tylko w odniesieniu do produktu spełniającego kryteria jakości. Akceptacja z uwagami oznacza, że Zamawiający będzie wykorzystywał dostarczone oprogramowanie w wersji produkcyjnej Systemu, do czasu ponownej dostawy produktu, który będzie uwzględniał uwagi wymienione zarówno w Protokole Akceptacji Produktu jak i w Raporcie z testów akceptacyjnych. Wady, stwierdzone zarówno w oprogramowaniu zaakceptowanym jak i w zaakceptowanym z uwagami, powinny zostać usunięte w terminach i przy zastosowaniu procedur dotyczących usuwania wad określonych w rozdziale 4 IPU - Warunki Dostaw i odbioru. c) Odrzucenie - jeśli dostarczony produkt nie spełnia założonych kryteriów jakości, a w szczególności, gdy poziom błędów wynikający z Raportu z testów akceptacyjnych odbiega od ustalonego. W takim wypadku dostawa jest odrzucana i produkt uznaje się za nie dostarczony. W przypadku odbioru jakościowego Produktu z uwagami albo odrzucenia Produktu przez Zamawiającego, Wykonawca zobowiązuje się w terminie 5 dni roboczych do dostarczenia poprawionego Produktu. Odbiór poprawionego Produktu następuje przy odpowiednim zastosowaniu punktu 2 niniejszej procedury. Szczegółowe procedury związane z zasadami przeprowadzania testów akceptacyjnych, a zwłaszcza zawartość Planów Testów i Scenariuszy Testów, a także Procedury Zgłaszania Błędów Testowych zostaną przez obie Strony uzgodnione w Planie Jakości Projektu. Potwierdzeniem dokonania odbioru jakościowego produktu jest podpisanie Protokołu Akceptacji Produktu bez uwag, przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. Za sporządzenie Protokołu Akceptacji Produktu odpowiedzialny jest Kierownik Projektu Zamawiającego. Protokół Akceptacji Produktu sporządzany jest w 3 egzemplarzach. Jeden egzemplarz dla Kierownika Projektu Zamawiającego, dwa dla Kierownika Projektu Wykonawcy 4. Odbiór formalny (końcowy) produktu - polega na potwierdzeniu przez Zamawiającego że produkt, w tym każdy jego element będący przedmiotem dostawy, spełnia warunki określone 9

10 w umowie i PJP oraz w przypadku produktu związanego z realizacją obszaru zmiennego Umowy, że spełnia on także wymagania określone we Wniosku Zmiany. W przypadku gdy, podczas odbioru formalnego Kierownik Projektu Zamawiającego stwierdzi, iż w trakcie procedury odbioru produktu zostały popełnione nieprawidłowości merytoryczne lub formalne, które w jego ocenie skutkują koniecznością powtórzenia czynności dotkniętych wadą, przeprowadzenia czynności uzupełniających lub dodatkowych czynności weryfikacyjnych, ewentualnie uzupełnienia wymaga dokumentacja związana z procedurą odbioru przekazuje Kierownikowi Projektu Wykonawcy stosowną informację w tym zakresie i razem podejmują niezbędne działania zmierzające do usunięcia stwierdzonych nieprawidłowości w odbiorze. Po usunięciu nieprawidłowości Kierownik Projektu Zamawiającego niezwłocznie podpisuje Protokół Odbioru Produktu. W przypadku, gdy stwierdzone nieprawidłowości dyskwalifikują sposób wykonania procedury odbioru produktu a w szczególności, gdy Kierownik Projektu Zamawiającego uzna, iż przeprowadzony odbiór jakościowy obarczony był wadami, które sprawiają, iż odbierany produkt może stanowić zagrożenie dla funkcjonowania podsystemu lub całego Systemu, może on odmówić dokonania odbioru końcowego produktu i zażądać ponownego przeprowadzenia całej trzystopniowej procedury odbiorczej. O fakcie tym, w terminie przewidzianym dla odbioru końcowego, informuje Kierownika Projektu Wykonawcy przekazując mu pisemnie swoją decyzję wraz z uzasadnieniem. Od tej decyzji Kierownik Projektu Wykonawcy może złożyć pisemne odwołanie do Kierownika Projektu Zamawiającego, który po zapoznaniu się ze sprawą w terminie 3 dni roboczych podejmuje ostateczną decyzję w tym zakresie. Odbiór końcowy produktu zostaje potwierdzony Protokołem Odbioru Produktu zgodnym ze wzorem określonym w Załączniku nr 5 do Umowy, podpisywanym przez właściwego Kierownika Projektu Zamawiającego lub osobę przez niego upoważnioną i Kierownika Projektu Wykonawcy. Za sporządzenie Protokołu Odbioru Produktu odpowiedzialny jest Kierownik Projektu Zamawiającego. Protokół Odbioru Produktu sporządzany jest w 3 egzemplarzach. Jeden egzemplarz dla Kierownika Projektu Zamawiającego, dwa dla Kierownika Projektu Wykonawcy.. Każdy z dokumentów potwierdzających dokonanie odbioru ilościowego, jakościowego i końcowego a więc odpowiednio Protokół Dostawy, Protokół Akceptacji Produktu oraz Protokół Odbioru Produktu przekazywane są Wykonawcy w terminie 3 dni roboczych po dniu podpisania. 10

11 Tabela nr 1 Nr Opis kryterium Co należy mierzyć Warunki spełnienia Cecha 1 - Funkcjonalność 1.1 Oprogramowanie realizuje kompletną funkcjonalność ustaloną według wymagań Zamawiającego i zapisaną w specyfikacji wymagań systemu wraz z aneksami. Dla ustalonego i zaakceptowanego zakresu projektu zgodność z wymaganiami kontraktowymi i późniejszymi zmianami. Utworzenie tabeli realizacji wymagań oraz wniosków zmian i przegląd stanu ich realizacji. Zrealizowano 100% funkcjonalności przewidzianej we wnioskach zmian. 1.2 Dopuszczalny poziom błędów dla nowej wersji oprogramowania zrealizowanej na podstawie Wniosku Zmiany Zdefiniowano klasyfikację błędów w systemie. Dopuszczane są następujące wagi błędów: Błędy blokujące, Błędy poważne, Błędy średnie, Błędy drobne. Liczba błędów każdego typu zapisana w rejestrze błędów ustanawianym dla każdego rodzaju testów potwierdzających funkcjona1ność (testy wewnętrzne i akceptacyjne). Liczba błędów każdego typu zapisana w rejestrze błędów prowadzonym dla testów dostarczonego oprogramowania nie przekracza następujących wartości: Błędy blokujące= 0, Błędy poważne= 1, Błędy średnie = 4, Błędy drobne = Dopuszczalny poziom błędów dla nowej wersji oprogramowania dostarczanej w wyniku usuwania wady Systemu (tzw. łata programowa patch) 11

12 Zdefiniowano klasyfikację błędów w systemie. Dopuszczane są następujące wagi błędów: Błędy Blokujące, Błędy Poważne, Błędy średnie, Błędy drobne. Łata programowa nie wprowadza błędów regresji Liczba błędów każdego typu zapisana w rejestrze błędów ustanawianym dla każdego rodzaju testów potwierdzających funkcjona1ność (testy wewnętrzne i akceptacyjne). Przekazywane oprogramowanie nie może zawierać błędów o wadze równej lub wyższej w hierarchii, niż błąd którego wystąpienie skutkuje dostawą oprogramowania (łaty programowej). Oznacza to przykładowo, że oprogramowanie przekazywane w ramach usuwania błędu średniego nie może posiadać błędów blokujących, poważnych lub średnich. Jeżeli łata programowa obejmuje kilka błędów o różnej wadze, przekazywane oprogramowanie nie może zawierać błędów o wadze równej lub wyższej w hierarchii, niż błąd o najwyższej wadze, który dana łata usuwa. Błędy regresji = Dopuszczalny poziom błędów- dla instalacji Instalacja wykonuje się zgodnie z procedurą instalacji Nie dopuszcza się odstępstw pomiędzy instrukcją a dostarczonym oprogramowaniem, dla: numeru wersji, oprogramowania, ilości plików i ich nazw. Cecha 2 - Bezpieczeństwo 12

13 2.1 Administrowanie Dane są zabezpieczone przed niepowołanym dostępem. Dostęp do aplikacji jest możliwy tylko dla zdefiniowanych użytkowników. Rodzaje użytkowników oraz poziom ich uprawnień określony jest w specyfikacji wymagań funkcjonalnych. Nieuprawnieni użytkownicy nie mogą korzystać z systemu. Dane są zabezpieczone przed utratą. Zapewniony jest audyt zmian w zakresie tych danych, które określono w specyfikacji wymagań. Zaimplementowane są narzędzia odtwarzania i archiwizacji (backup) danych. Sprawdzenie procedur konfiguracji oraz poprawności działania systemu w trakcie awarii zasilania, sprzętu itp. Sprawdzenie czy system rejestruje 100% zgodności. Informacje o użytkowniku wykonującym operacje na danych, określonych jako przeznaczone do śledzenia zmian w specyfikacji wymagań funkcjonalnych. Sprawdzenie poprawności działania narzędzi do odtwarzania i archiwizacji, zgodnie z przyjętymi procedurami. Dane wprowadzone do systemu przed awarią są dostępne i nie zmienione po odzyskaniu. 100% zgodności System po wykonaniu archiwizacji i odtworzeniu działa poprawnie. Architektura spełnia wymagania dotyczące bezpieczeństwa danych, wynikające ze specyfikacji wymagań technicznych. Cecha 3 - Użyteczność Realizacja wymagań dotyczących bezpieczeństwa, zgodność architektury i transmisji danych z polskim ustawodawstwem i wewnętrznymi uregulowaniami jednostki organizacyjnej w zakresie ochrony danych 100% zgodności 13

14 3.1 System współpracuje z innymi określonymi Systemami zewnętrznymi. Wykaz systemów i zakres współpracy określony w Specyfikacji wymagań funkcjonalnych. 3.2 Dane do systemu powinny być wprowadzane raz. 3.3 Interfejs programu został dostosowany do wymagań użytkowników. 3.4 Diagnostyka błędów oraz reakcji na sytuacje graniczne. 3.5 Spójność interfejsu GUI użytkownika. 3.6 Potwierdzanie wprowadzania / obróbki danych Wymiana określonych danych z systemami zewnętrznymi. (Testy) Sprawdzenie czy określony zestaw danych wprowadzany jest do systemu tylko raz. (Testy) Sprawdzenie czytelności i zrozumiałości etykiet, komunikatów systemowych. Sprawdzenie czytelności układu pól na formatkach. Sprawdzenie czytelności Raportów. Sprawdzenie czytelności komunikatów o błędach lub komunikatów walidacji wprowadzanych danych. Sprawdzenie czy interfejs GUI jest spójny pod względem koncepcji, syntaktyki, semantyki, formatu wprowadzania, stosowanych skrótów. Aktywne elementy graficzne systemu wizualnie potwierdzają wykonanie funkcji, która jest do nich przypisana. Wybrane dane są wyróżniane. System Możliwa wymiana w zakresie określonym w Specyfikacji wymagań funkcjonalnych. 100% zgodności. Obsługa systemu nie nastręcza kłopotów związanych z niezrozumieniem komunikatów, etykiet lub przeznaczenia pól prezentujących dane lub przeznaczonych do wprowadzania danych. Komunikaty są czytelne i zrozumiałe. Interfejs spełnia wymagania spójności w stopniu określonym w specyfikacji technicznej. 100% zgodności. 14

15 wyświetla widoczny pasek postępu wykonania operacji dla operacji zabierających więcej czasu niż 2 sekundy. Cecha 4 Wydajność i obciążalność 4.1 Wpływ liczby użytkowników pracujących w systemie na wydajność. Liczba użytkowników jednoczesnych jest wyspecyfikowana przez Zamawiającego i zaakceptowana przez Wykonawcę. Dla ustalonego i zaakceptowanego zakresu projektu zgodność z wymaganiami kontraktowymi późniejszymi zmianami. Pomiar dokonany będzie pod warunkiem określenia wpływu liczby użytkowników na wydajność systemu (ustalenia granicy akceptowanej wydajności systemu). Szczegóły zostaną określone w trakcie analizy. Użytkownicy nie mogą sic wzajemnie blokować, Cecha 5 Pielęgnowalność 5.1 System jest skalowalny i łatwy w rozbudowie. Pomiar czasu reakcji systemu po jego rozbudowie. Szczegóły zostaną określone w trakcie analizy. Cecha 6 Przenaszalność 6.1 Aplikacja zawiera narzędzia do instalacji lub określone są procedury instalacji. 6.2 Aplikacja zawiera narzędzia do deinstalacji lub określone są procedury deinstalacji. Istnieje stosowna aplikacja, zestaw aplikacji tub procedura. (Testy) Istnieje stosowna aplikacja, zestaw aplikacji lub procedura. (Testy) 100% zgodności z opisem instalacji lub opisem obsługi aplikacji instalacyjnej, zamieszczonej w podręczniku administratora. Rzeczywista instalacja aplikacji przebiega zgodnie z opisem w procedurze instalacji. 6.3 Możliwość wykonania instalacji w oparciu o procedurę instalacyjną. Czy procedura instalacyjna jest kompletna, napisana w sposób instalacji w oparciu Instalacja aplikacji zgodnie z punktami procedury instalacji, przebiega prawidłowo. Po 15

16 jasny i zrozumiały oraz adekwatna (można w oparciu o nią zainstalować system)? zakończeniu instalacji aplikacja nadaje się do użycia (realizuje pełną funkcjonalność zgodną z kryteriami jakości od 1 do 6). III. Procedura dostawy, akceptacji i odbioru dokumentacji 1. Przed realizacją procedury dostawy, akceptacji i odbioru dokumentacji muszą być wykonane u Wykonawcy następujące czynności wstępne poprzedzające dostawę dokumentacji: 1) Autor dokumentu zapisuje fakt zamknięcia dokumentu do przeglądu jakości w historii zmian dokumentu, określając datę zamknięcia oraz wersję dokumentu. Następnie przekazuje dokument Kierownikowi Jakości Wykonawcy. 2) Kierownik Jakości Wykonawcy weryfikuje lub poleca zweryfikować dokumentację poprzez wyznaczenie osoby (lub zespołu) dokonującego przeglądu w oparciu o następujące kryteria jakości: a) Format typograficzny dokumentu, układ dokumentacji oraz symbolikę poszczególnych rodzajów produktów dokumentacyjnych jest zgodny ze szczegółowymi wymaganiami i zasadami, które strony uzgodnią w ramach PJP, b) Treść dokumentacji jest spójna i zrozumiała dla użytkowników, c) Dokumentacja jest zgodna z wytworzoną aplikacją, d) Językiem przekazywanej dokumentacji będzie język polski, e) Format strony A4. 3) Kierownik Jakości Wykonawcy sporządza listę uwag do dokumentu (lub zbiera uwagi od zespołu zaangażowanego w przegląd), po czym przekazuje dokument wraz z uwagami do Kierownika Projektu Wykonawcy. 4) Kierownik Projektu Wykonawcy ustala z autorem dokumentu czas i tryb realizacji poprawek, ewentualnie nanosi zmiany w harmonogramie. 5) Autor realizując poprawki zmienia rewizję dokumentu na kolejną, o I większą od poprzedniej. Cykl walidacji zostaje zamknięty po zaakceptowaniu przez Kierownika Jakości Wykonawcy stanu dokumentu. 6) Kierownik Jakości Wykonawcy zapisuje adnotację o dokonanym przeglądzie i akceptacji dokumentu, podając datę przeglądu w metryce historii zmian oraz metryce dokumentu i dopuszcza tym samym produkt do przekazania Zamawiającemu. Na 3 dni przed dostawą produktu Wykonawca zobowiązany jest zgłosić Kierownikowi Projektu Zamawiającego, że dokumentacja jest gotowa do przeprowadzenia weryfikacji przez Zamawiającego. Zgłoszenie następuje w formie elektronicznej lub pisemnej. Dokumentacja jest dostarczana w formie elektronicznej oraz w jednym egzemplarzu w wersji papierowej do archiwum Systemu ZEFIR 2. Wykonawca dostarczy repozytoria projektowe 16

17 aplikacji w formacie stosowanych narzędzi zatwierdzonych w PJP. 2. Odbiór ilościowy polega na weryfikacji przez Zamawiającego, czy dostawa zawiera wszystkie wymagane elementy. Odbiór ilościowy produktów w postaci dokumentacji dokonywany jest dla każdej dostawy. Wykonawca przekazuje Kierownikowi Projektu Zamawiającego produkt wraz z Protokołem Dostawy. Kierownik Projektu Zamawiającego w terminie 2 dni roboczych od momentu dostawy weryfikuje kompletność dostawy zrealizowanej przez Wykonawcę. Weryfikacja obejmuje sprawdzenie prawidłowości wypełnienia Protokołu Dostawy i dostarczenia wszystkich produktów wyspecyfikowanych na tym protokole. Potwierdzeniem odbioru ilościowego dostawy jest podpisanie Protokołu Dostawy przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. Nie dopuszcza się dokonania odbioru ilościowego z uwagami. W przypadku stwierdzenia nieprawidłowości dostawa podlega bezwarunkowemu odrzuceniu, a ponowna dostawa powinna następnie w terminie nie dłuższym niż 7 dni roboczych od daty odrzucenia dostawy. 3. Odbiór jakościowy (merytoryczny) polega na zweryfikowaniu, czy produkt spełnia wymagania jakościowe określone przez Zamawiającego. Kierownik Projektu Zamawiającego w terminie 3 dni roboczych od podpisania Protokołu Dostawy powołuje Zespół Weryfikacyjny, wyznacza datę spotkania weryfikującego lub końcowy termin do zgłaszania uwag w trybie korespondencyjnym na podany przez niego adres poczty elektronicznej, oraz przekazuje członkom Zespołu produkt celem zgłoszenia ewentualnych uwag. Uwagi zgłaszane są w trakcie spotkania weryfikacyjnego lub w przypadku zastosowania trybu korespondencyjnego na wskazany przez Kierownika Projektu Zamawiającego adres poczty elektronicznej. Po zapoznaniu się z uwagami członków Zespołu Kierownik Projektu Zamawiającego podejmuje decyzje w kwestii odbioru jakościowego. Decyzja ta powinna zapaść w terminie 20 dni roboczych licząc od dnia przystąpienia do odbioru. W wypadku gdy termin ten nie jest możliwy do dotrzymania Kierownicy Projektów Zamawiającego i Wykonawcy mogą uzgodnić przedłużenie terminu odbioru. Wykonawca może uczestniczyć w pracach zespołu Weryfikacyjnego. Możliwe są następujące decyzje dotyczące odbioru jakościowego dokumentacji: a) Akceptacja bez uwag - jeśli dokumentacja spełnia kryteria jakości, które zostały podane powyżej w ust.1. W takim wypadku sporządzany jest Protokół Akceptacji Produktu, bez uwag z rekomendacją dokonania odbioru formalnego. b) Akceptacja z uwagami jeśli dostarczony produkt nie spełnia kryteriów jakości określonych przez Zamawiającego, jednakże brak decyzji o odbiorze może zagrozić funkcjonowaniu systemu lub nawet zablokowaniu jego dalszych prac. Sporządzany jest wtedy Protokół Akceptacji Produktu z uwagami. Uwagi mogą mieć formę załącznika do tego protokołu, które to Kierownik Projektu Zamawiającego przesyła do 17

18 Kierownika Projektu Wykonawcy. Protokół Akceptacji Produktu z uwagami nie jest równoznaczny z rekomendacją do odbioru końcowego, która może zostać udzielona tylko w odniesieniu do produktu spełniającego kryteria jakości. Akceptacja z uwagami oznacza, że Zamawiający będzie wykorzystywał dostarczoną dokumentację, do czasu ponownej dostawy produktu, który będzie uwzględniał uwagi wymienione w Protokole Akceptacji Produktu lub w załączniku do tego protokołu. c) Odrzucenie - jeśli dostarczony produkt nie spełnia założonych kryteriów jakości. W takim wypadku dostawa jest odrzucana i produkt uznaje się za niedostarczony. W przypadku odbioru jakościowego Produktu z uwagami albo odrzucenia Produktu przez Zamawiającego, Wykonawca zobowiązuje się w terminie 5 dni roboczych do dostarczenia poprawionego Produktu. Odbiór poprawionego Produktu następuje przy odpowiednim zastosowaniu punktu III niniejszej procedury. Zarówno w przypadku akceptacji z uwagami jak i odrzucenia dostawy, ponowna dostawa powoduje zmianę numeru wersji dokumentu. Potwierdzeniem dokonania odbioru jakościowego produktu jest podpisanie Protokołu Akceptacji Produktu bez uwag, przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. Za sporządzenie Protokołu Akceptacji Produktu odpowiedzialny jest Kierownik Projektu Zamawiającego. Po podpisaniu Protokołu Akceptacji Produktu (w 3 egzemplarzach) Kierownik Projektu Zamawiającego przekazuje go Kierownikowi Projektu Wykonawcy. 4. Odbiór formalny (końcowy) produktu - polega na stwierdzeniu przez Strony, że produkt, w tym każdy jego element będący przedmiotem dostawy, spełnia warunki określone w umowie i PJP. Jeżeli na etapie odbioru formalnego Kierownik Projektu Zamawiającego stwierdzi, iż w trakcie procedury odbioru produktu zostały popełnione nieprawidłowości merytoryczne lub formalne, które w jego ocenie skutkują koniecznością powtórzenia czynności dotkniętych wadą, przeprowadzenia czynności uzupełniających lub dodatkowych czynności weryfikacyjnych - przekazuje Kierownikowi Projektu Wykonawcy stosowną informację w tym zakresie i razem podejmują niezbędne działania zmierzające do usunięcia stwierdzonych nieprawidłowości. Po usunięciu nieprawidłowości Kierownik Projektu Zamawiającego niezwłocznie podpisuje Protokół Odbioru Produktu. W skrajnym przypadku, gdy stwierdzone nieprawidłowości dyskwalifikują przydatność dostarczonej dokumentacji, może on odmówić dokonania odbioru końcowego produktu zażądać ponownego przeprowadzenia całej trzystopniowej procedury odbiorczej. O fakcie tym, w terminie przewidzianym dla odbioru końcowego, informuje Kierownika Projektu Wykonawcy przekazując mu pisemnie swoją decyzję wraz uzasadnieniem. Od tej decyzji Kierownik Projektu Wykonawcy może złożyć pisemny protest do Kierownika Projektu Zamawiającego, który po zapoznaniu się ze sprawą w terminie 3 dni roboczych podejmuje 18

19 ostateczną decyzję w tym zakresie. Odbiór końcowy produktu zostaje potwierdzony Protokołem Odbioru Produktu zgodnym ze wzorem określonym w Załączniku nr 5 do Umowy, podpisywanym przez właściwego Kierownika Projektu Zamawiającego lub osobę przez niego upoważnioną i Kierownika Projektu Wykonawcy. Za sporządzenie Protokołu Odbioru Produktu odpowiedzialny jest Kierownik Projektu Zamawiającego. Po podpisaniu Protokołu Odbioru Produktu (w 3 egzemplarzach) Kierownik Projektu Zamawiającego przekazuje go Kierownikowi Projektu Wykonawcy. Każdy z dokumentów potwierdzających dokonanie odbioru ilościowego, jakościowego, końcowego a więc odpowiednio Protokół Dostawy, Protokół Akceptacji Produktu oraz Protokół Odbioru Produktu przekazywane są Wykonawcy w terminie 3 dni roboczych po dniu podpisania ich przez Kierownika Projektu Zamawiającego. Dokumentacja Format typograficzny dokumentu zgodny z PJP(Plan Jakości Projektu). Układ dokumentu zgodny z PJP (Plan Jakości Projektu). Symbolika poszczególnych rodzajów produktów dokumentacyjnych zgodna z PJP (Plan Jakości Projektu). Zawartość merytoryczna dokumentów jest zgodna z podaną w PJP (Plan Jakości Projektu). Językiem przekazywanej dokumentacji jest język polski. Strony posiadają format A4. IV. Procedura dostawy, akceptacji i odbioru kodów źródłowych 1. Wykonawca w terminie 10 dni roboczych po odbiorze i wdrożeniu ogólnopolskim Systemu ZEFIR 2 zobowiązuje się do dostarczenia do siedziby Zamawiającego kody źródłowe Systemu ZEFIR 2 wraz z opisem struktur katalogów kodów źródłowych oraz opisem standardu nazewnictwa plików źródłowych i wynikowych. Każdy plik kodu źródłowego musi posiadać nagłówek składający się z: nazwy pliku i daty powstania wersji. Opisane muszą być wszystkie definicje zmiennych i stałych, każda z procedur/metod zawierać musi opis nagłówkowy składający się z: listy i opisu argumentów, opisu wyniku oraz krótkiego opisu działania. Skomentowane muszą być kluczowe instrukcje sterujące warunki, wyniki. Kod źródłowy musi być zgodny z dostarczoną wersją wytworzonego oprogramowania.dodatkowo Wykonawca zobowiązuję się na każde żądanie Zamawiającego w terminie 10 dni roboczych od żądania dostarczyć do siedziby Zamawiającego wszystkie kolejne nowe wersje kodów źródłowych i skompilowanych plików związanych z utrzymaniem i rozwojem Systemu 19

20 ZEFIR 2 w okresie trwania umowy. Wykonawca zobowiązuje się dostarczyć: kody źródłowe, zgodne z kryteriami określonymi w Tabeli nr 3 Kryteria odbioru kodów źródłowych, specyfikację środowiska sprzętowo-systemowego wymaganego do przeprowadzenia procedury generacji kodu wynikowego, instrukcję generacji kodu wynikowego oraz instrukcję konfiguracji środowiska do wygenerowania kodów wynikowych, narzędzia do przygotowywania wersji instalacyjnych wytworzonego oprogramowania (wersji pełnej, aktualizacji, łat) wraz z dokumentacją użytkowania, narzędzia do instalacji wytworzonego oprogramowania wraz z dokumentacją instalacji. opis działania kodu źródłowego, wersję instalacyjną Systemu ZEFIR 2 zawierającą oprogramowanie wykonalne, na płytach CD-ROM lub DVD-ROM oraz oświadczenie Wykonawcy, że dostarczone przez niego kody źródłowe oprogramowania są kompletne tj. wszystkie, które zostały wykorzystane do dokonania zmiany w Systemie ZEFIR 2 oraz, że są to kody źródłowe, których użył do skompilowania, czyli do utworzenia oprogramowania wykonalnego. 2. Odbiór kodów źródłowych jest trójstopniowy, składa się z: Odbioru ilościowego, Odbioru jakościowego oraz Odbioru formalnego. 3. Potwierdzeniem dokonania odbioru ilościowego dostawy kodów źródłowych jest podpisanie Protokołu Dostawy stanowiący Załącznik nr 3 do Umowy przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. 4. Nie dopuszcza się dokonania odbioru ilościowego z uwagami. W przypadku stwierdzenia nieprawidłowości dostawa podlega bezwarunkowemu odrzuceniu, a ponowna dostawa powinna nastąpić w terminie nie dłuższym niż 7 dni roboczych od daty odrzucenia dostawy. 5. Potwierdzeniem dokonania odbioru jakościowego dostawy kodów źródłowych jest podpisanie Protokołu Akceptacji Produktu stanowiących Załącznik nr 4 do Umowy przez Kierownika Projektu Zamawiającego lub upoważnioną przez niego osobę. Odbiór jakościowy polega na zweryfikowaniu czy kody źródłowe spełniają wymagania jakościowe określone przez Zamawiającego w Tabeli nr 3 - Kryteria odbioru kodów źródłowych. 20

21 6. Na wniosek Zamawiającego Strony Umowy będą wykonywały wspólne przeglądy kodów źródłowych. Wynikiem przeglądu będzie raport, w którym strony uzgodnią tryb dalszego postępowania, tj. zidentyfikują elementy wymagające zmiany lub uzupełnienia. 7. Odbiór końcowy/formalny kodów źródłowych polega na potwierdzeniu przez Zamawiającego, że kody źródłowe będące przedmiotem dostawy, spełniają wymagania wynikające z Umowy. Odbiór końcowy kodów źródłowych zostaje potwierdzony Protokołem Odbioru Produktu bez zastrzeżeń, zgodnym ze wzorem, który określa Załącznik Nr 5 do Umowy. Protokół Odbioru Produktu jest podpisywany przez Kierownika Projektu Zamawiającego i Kierownika Projektu Wykonawcy. Podstawą do podpisania protokołu odbioru przez Zamawiającego, jest przedstawienie przez Wykonawcę, podpisanych protokołów akceptacji produktu. Odbiór formalny powinien nastąpić w terminie 2 dni roboczych od daty odbioru jakościowego bez uwag. 8. Skompilowane pliki muszą uwzględniać wszystkie wprowadzone zmiany przez Wykonawcę w Systemie ZEFIR W terminie uzgodnionym przez Strony, Wykonawca zaprezentuje Zamawiającemu proces generowania oprogramowania z dostarczonych kodów źródłowych, zgodnie z dostarczonymi ww. regułami i dokumentacją. Tabela nr 3 - Kryteria odbioru kodów źródłowych Kryteria odbioru kodów źródłowych Pliki opisujące strukturę dokumentów w formacie XML (tzw. XML Schema) zawarta w specyfikacji technicznej XML. Wszystkie parametry systemu, uzgodnione z Zamawiającym w specyfikacji technicznej, można modyfikować bez konieczności zmiany kodu źródłowego. Opis wszystkich parametrów, uzgodnionych z Zamawiającym znajduje się w specyfikacji technicznej. Wszystkie literały, uzgodnione z Zamawiającym w specyfikacji technicznej, można modyfikować bez konieczności zmiany kodu źródłowego, w szczególności: adresów komputerów i aplikacji, z którymi aplikacje Systemu ZEFIR 2 komunikują się, lokalizacji plików wczytywanych i zapisywanych przez aplikacje Systemu ZEFIR 2, nazw własnych (nie będących wewnętrznymi nazwami obiektów programowych) i stałych używanych w Systemie ZEFIR 2. Warunki spełnienia kryterium odbioru Bez odstępstw. Bez odstępstw. Parametry można zmodyfikować bez udziału Wykonawcy Literały można zmodyfikować bez udziału Wykonawcy. 21

22 Kompilacja dostarczonych przez Wykonawcę kodów źródłowych odbyła się bez błędów w środowisku opisanym przez Wykonawcę. Pliki uzyskane po kompilacji odpowiadają plikom z wersji zaakceptowanej, pod względem ilości, wielkości, typu i zawartości. Wszystkie operacje zmieniające zawartość danych w bazach danych będą wykonywane transakcyjnie; w kodzie źródłowym zostanie zaimplementowana obsługa ewentualnych błędów wykonania operacji na bazie danych. Kody źródłowe zostały skomentowane i sformatowane, a komentarze wyjaśniają użyty algorytm, a nie powielają kod algorytmu, tj.: Opisane są wszystkie definicje zmiennych i stałych Każda z metod zawiera opis nagłówkowy składający się z: Listy i opisu argumentów, Opisu wyniku, Krotki opis działania, Lista dokonanych zmian (kto, kiedy, co) Opisane są kluczowe instrukcje sterujące warunki, wyniki, Zachowana jest jednolitość nazw zmiennych. Dla nazw zmiennych wykorzystano j. angielski. Opisy i komentarze w j. polskim. Niedopuszczalne są sytuacje, gdy funkcja zwraca nieokreślony wyjątek (Exception). Wyjątki powinny być obsługiwane wewnątrz funkcji, a jeśli jest to niewskazane z przyczyn konstrukcyjnych programu, to lista możliwych do zwrócenia wyjątków musi być zadeklarowana i odpowiednio opisana. Dla oprogramowania pisanego w języku java należy stosować standard firmy Oracle opisany w dokumencie Klasy i metody powinny być opisane sposób pozwalający na wygenerowanie dokumentacji za pomocą narzędzia javadoc html Kody źródłowe są przekazane w postaci repozytorium źródeł zapewniającego kontrolę wersji. Wszelkie funkcje na bazie danych będą zaimplementowane w sposób taki, iż dołożenie jakiejkolwiek kolumny do dowolnej tabeli w bazie danych, zmiana kolejności kolumn w jakiejkolwiek tabeli w bazie Kompilacja przeszła bez błędów. Dopuszczalne różnice wynikające z charakterystyki narzędzia. Bez odstępstw. Dopuszczalne braki w komentarzach wynikające z zastosowania bibliotek zewnętrznych Bez odstępstw Bez odstępstw Bez odstępstw Bez odstępstw 22

23 danych, zmiana definicji wielkości kolumny tekstowej na większą ilość znaków lub zmiana definicji kolumny na przechowywanie większych wartości numerycznych nie będzie wpływała na działanie systemu. 23

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2 Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja

Bardziej szczegółowo

Procedury dostawy, akceptacji i odbioru produktów

Procedury dostawy, akceptacji i odbioru produktów Załącznik nr 17 do Umowy nr.. z dnia... Procedury dostawy, akceptacji i odbioru produktów 1 Spis treści 1 Wstęp... 3 1.1 Cel dokumentu... 3 1.2 Odbiorcy dokumentu... 3 1.3 Zakres dokumentu... 3 1.4 Definicje,

Bardziej szczegółowo

Procedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje:

Procedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje: 1. Niniejsza Procedura odbioru obejmuje: Załącznik nr 3 do Umowy nr... z dnia... zmodyfikowany w dniu 18.05.2015 r. Procedura Odbioru a) proces uzgadniania wykazu Produktów do odbioru; b) proces uzgadniania

Bardziej szczegółowo

Opis przedmiotu zamówienia

Opis przedmiotu zamówienia Załącznik nr 1 do SIWZ Załącznik nr 1 do Umowy nr... z dnia... 20... r. SYSTEM HERMES2 Rozbudowa Pilota Systemu HERMES2 Opis przedmiotu zamówienia Spis treści SPIS TREŚCI 1. Słownik przyjętych skrótów

Bardziej szczegółowo

Szczegółowy opis przedmiotu zamówienia

Szczegółowy opis przedmiotu zamówienia Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja

Bardziej szczegółowo

Opis przedmiotu zamówienia na zaprojektowanie, realizację, dostawę, instalację, wdrożenie i wsparcie utrzymania oraz rozwój Systemu ZEFIR 2

Opis przedmiotu zamówienia na zaprojektowanie, realizację, dostawę, instalację, wdrożenie i wsparcie utrzymania oraz rozwój Systemu ZEFIR 2 Załącznik nr 1 do SIWZ Załącznik nr 1 do Istotnych Postanowień Umowy Opis przedmiotu zamówienia na zaprojektowanie, realizację, dostawę, instalację, wdrożenie i wsparcie utrzymania oraz rozwój Systemu

Bardziej szczegółowo

Opis przedmiotu zamówienia

Opis przedmiotu zamówienia Załącznik nr 1 do SIWZ Załącznik nr 1 do Umowy nr... z dnia... 20... r. SYSTEM HERMES2 Opis przedmiotu zamówienia Spis treści SPIS TREŚCI 1. Słownik przyjętych skrótów i oznaczeń...4 2. Przedmiot zamówienia

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji na przedmiot Umowy i zobowiązuje

Bardziej szczegółowo

Nazwa Projektu. Plan testów. Wersja N.NN

Nazwa Projektu. Plan testów. Wersja N.NN Nazwa Projektu Plan testów Wersja N.NN Projekt realizowany jest w ramach Programu e-cło współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna

Bardziej szczegółowo

ISTOTNE POSTANOWIENIA UMOWY

ISTOTNE POSTANOWIENIA UMOWY Załącznik nr 1 do SIWZ 35-ILGW-253-150/2012 ISTOTNE POSTANOWIENIA UMOWY Al. Krasińskiego 11b, 31-111 Kraków tel.: +48 12 62 90 194 fax.: +48 12 62 90 189 e- mail: projekt.osoz2@kra.mofnet.gov.pl www.e-clo.gov.pl

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się

Bardziej szczegółowo

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ

Rozdział 3. ROZWÓJ APLIKACJI CENTRALNEJ Załącznik nr 2 do umowy nr 11/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU APLIKACJI CENTRALNEJ Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania realizacją umowy

Bardziej szczegółowo

Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji

Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji I. Zawartość Planu Jakości Projektu 1. Wstęp 1.1. Cel Planu Jakości Projektu 1.2. Zastosowanie

Bardziej szczegółowo

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Załącznik nr 2 do umowy nr 37/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

PROCEDURY AKCEPTACJI ORAZ ODBIORU PRZEDMIOTU UMOWY

PROCEDURY AKCEPTACJI ORAZ ODBIORU PRZEDMIOTU UMOWY Załącznik nr 4 do Umowy Nr... z dnia...r. znak sprawy: 53/DI/PN/2010 MINISTERSTWO PRACY I POLITYKI SPOŁECZNEJ ul. Nowogrodzka 1/3/5, 00-513 Warszawa www.mpips.gov.pl PROCEDURY AKCEPTACJI ORAZ ODBIORU PRZEDMIOTU

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT

Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT 1 I. Przedmiot zamówienia: Świadczenie usługi Asysty Technicznej dla systemu E-BPNT. II.

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W SI EKSMOON

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W SI EKSMOON Załącznik nr 3 do umowy nr 31/DI/PN/2015 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W SI EKSMOON Rozdział 1. ADMINISTROWANIE 1. Wykonawca zobowiązuje się do administrowania środowiskiem produkcyjnym

Bardziej szczegółowo

Opis Przedmiotu Zamówienia

Opis Przedmiotu Zamówienia Załącznik nr 1 do SIWZ/ załącznik nr 1 do umowy OP/UP/099/2011 Opis Przedmiotu Zamówienia 1. Przedmiot zamówienia 1.1. Przedmiotem zamówienia jest świadczenie usług konsultancko-developerskich dla systemu

Bardziej szczegółowo

ZAŁĄCZNIK nr WARUNKI GWARANCJI I. DEFINICJE... 2 II. ZASADY OGÓLNE... 3 III. POZIOMY SLA... 7. Izba Celna w Białymstoku. www.e-clo.gov.

ZAŁĄCZNIK nr WARUNKI GWARANCJI I. DEFINICJE... 2 II. ZASADY OGÓLNE... 3 III. POZIOMY SLA... 7. Izba Celna w Białymstoku. www.e-clo.gov. Izba Celna w Białymstoku ZAŁĄCZNIK nr WARUNKI GWARANCJI I. DEFINICJE... 2 II. ZASADY OGÓLNE... 3 III. POZIOMY SLA... 7 ul. Octowa 2, 15-399 Białystok tel.: +48 85 745 85 55 fax: +48 85 745 85 99 e-mail:

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

Bardziej szczegółowo

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO Załącznik nr 3 do Umowy nr.. z dnia r. Warunki gwarancji i serwisu gwarancyjnego WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO 1. Definicję pojęć: Celem opisania warunków świadczenia usług serwisowych definiuje

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji

Bardziej szczegółowo

PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY

PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY Załącznik nr 10 do SIWZ znak EZP/5511/2013 PROCEDURA WERYFIKACJI I OCENY DEKLAROWANYCH FUNKCJONALNOŚCI OPROGRAMOWANIA OFEROWANEGO PRZEZ WYKONAWCĘ NA ETAPIE OCENY OFERTY 1. Zamawiający przeprowadzi procedurę

Bardziej szczegółowo

ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA...

ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA... Załącznik nr 10 Warunki Gwarancji I. ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA... 7 I. Zapisy ogólne 1. Wykonawca udziela Zamawiającemu

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA. 1. Wynajem przez Wykonawcę na rzecz Zamawiającego zestawów urządzeń w skład, których wchodzą :

OPIS PRZEDMIOTU ZAMÓWIENIA. 1. Wynajem przez Wykonawcę na rzecz Zamawiającego zestawów urządzeń w skład, których wchodzą : Oznaczenie sprawy: ZA.2710.65.2013 Załącznik nr 6 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Przedmiotem niniejszego zamówienia jest : 1. Wynajem przez Wykonawcę na rzecz Zamawiającego zestawów urządzeń w skład,

Bardziej szczegółowo

Załącznik nr 2 do SIWZ

Załącznik nr 2 do SIWZ Załącznik nr 2 do SIWZ Opis Przedmiotu Zamówienia (zwany dalej OPZ), zawierający wymagania Zamawiającego do Umowy na świadczenie usług serwisowych systemu zapewniającego, przy wykorzystaniu interfejsu

Bardziej szczegółowo

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Załącznik Nr 1 Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Wersja 1.0 Na podstawie: Europejskiej Modelowej Umowy o EDI (w skrócie:

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Kod CPV: 72224000 1 Usługi doradcze w zakresie zarządzania projektem 85312320 8 Usługi doradztwa

ZAPYTANIE OFERTOWE. Kod CPV: 72224000 1 Usługi doradcze w zakresie zarządzania projektem 85312320 8 Usługi doradztwa ZAPYTANIE OFERTOWE Centrum Rozwoju Zasobów Ludzkich zaprasza do złożenia oferty cenowej z uwzględnieniem poniższych warunków: 1. Przedmiot zamówienia: Przedmiotem zamówienia jest opracowanie systemu i

Bardziej szczegółowo

Załącznik nr 2 do SIWZ

Załącznik nr 2 do SIWZ Załącznik nr 2 do SIWZ Opis Przedmiotu Zamówienia (zwany dalej OPZ) dotyczący postępowania na zakup usług profesjonalnego wsparcia użytkowników interfejsu ZSD3, będącego interfejsem pomiędzy systemem ZSRK,

Bardziej szczegółowo

WYJAŚNIENIA NR 2 TREŚCI SIWZ

WYJAŚNIENIA NR 2 TREŚCI SIWZ CPI-ZZP-2244-40-495/13 Warszawa, dnia 24 stycznia 2013 roku Wykonawcy, którzy pobrali SIWZ w postępowaniu nr 40-CPI-ZZP-2244/12 Działając na podstawie art. 38 ust. 1a, ust. 2 i ust. 4 w zw. z art. 12a

Bardziej szczegółowo

Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014

Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014 Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014 Zamawiający: Wyższa Szkoła Bankowa w Toruniu z siedzibą

Bardziej szczegółowo

WARUNKI I ZASADY SERWISU APLIKACJI (OPROGRAMOWANIA UśYTKOWEGO) KRAJOWEGO REJESTRU KARNEGO

WARUNKI I ZASADY SERWISU APLIKACJI (OPROGRAMOWANIA UśYTKOWEGO) KRAJOWEGO REJESTRU KARNEGO Załącznik nr 1 do umowy Nr... z dnia... na serwis aplikacji Krajowego Rejestru Karnego w roku 2008. WARUNKI I ZASADY SERWISU APLIKACJI (OPROGRAMOWANIA UśYTKOWEGO) KRAJOWEGO REJESTRU KARNEGO 1. Wstęp Niniejszy

Bardziej szczegółowo

PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH. załącznik do ZR 154/2014 z dnia 22 grudnia 2014 roku

PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH. załącznik do ZR 154/2014 z dnia 22 grudnia 2014 roku PROCEDURA OBSŁUGI INCYDENTÓW I WNIOSKÓW NA REALIZACJĘ USŁUG W SYSTEMACH INFORMATYCZNYCH załącznik do ZR 154/2014 Spis treści I. CEL I ZAKRES OBOWIĄZYWANIA INSTRUKCJI... 3 II. DEFINICJE I SKRÓTY... 3 III.

Bardziej szczegółowo

Projekt MCA. Spotkanie Przedsiębiorc. biorców w z Przedstawicielami Służby S

Projekt MCA. Spotkanie Przedsiębiorc. biorców w z Przedstawicielami Służby S Projekt MCA Spotkanie Przedsiębiorc biorców w z Przedstawicielami Służby S Celnej Zbigniew Juzoń Warszawa, 19 grudnia 2012 r. Kierownik Projektu MCA Izba Celna w Kielcach Projekt Program e-cło,, POIG.07.01.00-00

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa

Bardziej szczegółowo

ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA

ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA ZAŁĄCZNIK NR 1 DO SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Strona 1 z 7 Spis treści 1. Wprowadzenie... 3 2. Cel zamówienia... 3 3. Przedmiot zamówienia... 3 4. Etapy realizacji... 3 5. Wymagania... 4 5.1. Wymagania

Bardziej szczegółowo

25 lat. Generator wniosków o dofinansowanie ze środków krajowych. Katarzyna Jakubowska Główny specjalista DepartamentRozwoju Systemów Informatycznych

25 lat. Generator wniosków o dofinansowanie ze środków krajowych. Katarzyna Jakubowska Główny specjalista DepartamentRozwoju Systemów Informatycznych Narodowy Fundusz Ochrony Środowiska i Gospodarki Wodnej 25 lat Generator wniosków o dofinansowanie ze środków krajowych Katarzyna Jakubowska Główny specjalista DepartamentRozwoju Systemów Informatycznych

Bardziej szczegółowo

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r.

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r. 132 ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r. w sprawie wymogów dla systemów wyliczania utrzymywanych w podmiotach objętych obowiązkowym systemem gwarantowania Na podstawie art. 38j

Bardziej szczegółowo

Czy zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: tak, numer ogłoszenia

Czy zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: tak, numer ogłoszenia 1 Ogłoszenie powiązane: Ogłoszenie nr 9040-2014 z dnia 2014-01-09 r. Ogłoszenie o zamówieniu - Warszawa Przedmiotem zamówienia jest świadczenie usług wsparcia administracyjnego i merytorycznego w ramach

Bardziej szczegółowo

Polskie Sieci Elektroenergetyczne S.A. OPIS PRZEDMIOTU ZAMÓWIENIA SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA CZĘŚĆ II NA

Polskie Sieci Elektroenergetyczne S.A. OPIS PRZEDMIOTU ZAMÓWIENIA SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA CZĘŚĆ II NA Polskie Sieci Elektroenergetyczne S.A. OPIS PRZEDMIOTU ZAMÓWIENIA SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA CZĘŚĆ II NA Zamówienie niepubliczne Przetarg nieograniczony Konstancin - Jeziorna, listopad

Bardziej szczegółowo

Imię i nazwisko zamawiającego...

Imię i nazwisko zamawiającego... Zamówienie abonamentowej aktualizacji programów na rok 2016 w firmie W przypadku aktualizowania części (nie wszystkich) posiadanych stanowisk koniecznie proszę podać numery kluczy (zabezpieczeń) aktualizowanych

Bardziej szczegółowo

Wszystko na temat wzoru dokumentu elektronicznego

Wszystko na temat wzoru dokumentu elektronicznego Stowarzyszenie PEMI Wszystko na temat wzoru dokumentu elektronicznego Czym jest, kto go tworzy, kto publikuje, kto może z niego skorzystać? Mirosław Januszewski, Tomasz Rakoczy, Andrzej Matejko 2007-07-25

Bardziej szczegółowo

Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi

Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi Załącznik nr 3 do umowy Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi 1. a) Rozszerzenia funkcjonalności systemu (nie zmieniające generalnej struktury programu). Usługa umożliwia

Bardziej szczegółowo

Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa "MATAR" Bedzin Siemońska 11 Kod pocztowy 42-500

Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa MATAR Bedzin Siemońska 11 Kod pocztowy 42-500 Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa "MATAR" Bedzin Siemońska 11 Kod pocztowy 42-500 1. Podstawa formalna zapytania ofertowego Niniejsze Zapytaniem

Bardziej szczegółowo

Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach oprogramowania

Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach oprogramowania ZAŁĄCZNIK NR 3 do umowy z dnia r. Szczegółowe warunki i zasady świadczenia przez Wykonawcę usług serwisu gwarancyjnego. 1. Definicje Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach

Bardziej szczegółowo

Opis przedmiotu zamówienia na świadczenie usług doradztwa w projekcie euczelnia Opis przedmiotu zamówienia

Opis przedmiotu zamówienia na świadczenie usług doradztwa w projekcie euczelnia Opis przedmiotu zamówienia Załącznik nr 4 do SIWZ Załącznik nr 1 do umowy Opis przedmiotu zamówienia na świadczenie usług doradztwa w projekcie euczelnia Opis przedmiotu zamówienia Przedmiotem zamówienia są usługi doradztwa technicznego,

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

Załącznik Nr 6 do siwz. UMOWA (projekt)

Załącznik Nr 6 do siwz. UMOWA (projekt) Załącznik Nr 6 do siwz UMOWA (projekt) zawarta w dniu... r. pomiędzy Samodzielnym Publicznym Zakładem Opieki Zdrowotnej z siedzibą w Parczewie 21-200, ul. Kościelna 136, zarejestrowanym w Sądzie Rejonowym

Bardziej szczegółowo

Instrukcja użytkownika

Instrukcja użytkownika Generator Wniosków o Dofinansowanie dla Regionalnego Programu Operacyjnego Województwa Podlaskiego na lata 2007-2013 Instrukcja użytkownika Aplikacja współfinansowana ze środków Europejskiego Funduszu

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa pliku Tom 6 Opis oprogramowania, Część 2 Generator danych

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH W OŚRODKU KULTURY W DRAWSKU POMORSKIM

INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH W OŚRODKU KULTURY W DRAWSKU POMORSKIM Załącznik Nr 3 do zarządzenia Nr 5/2012 Dyrektora Ośrodka Kultury w Drawsku Pomorskim z dnia 1 marca 2012 r. INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH W

Bardziej szczegółowo

Podstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji.

Podstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji. Podstawowe zasady dotyczące potwierdzania warunków transakcji na Platformie konfirmacji. 1. Uczestnicy rozliczający KDPW_CCP przekazują do systemu kdpw_stream instrukcje konfirmacyjne do zestawienia za

Bardziej szczegółowo

Opis wymagań i program szkoleń dla użytkowników i administratorów

Opis wymagań i program szkoleń dla użytkowników i administratorów Załącznik nr 3 do OPZ Opis wymagań i program szkoleń dla użytkowników i administratorów Spis treści Wprowadzenie...2 1. Typ i zakres szkoleń...2 2. Grupy użytkowników...2 3. Warunki ogólne szkoleń...3

Bardziej szczegółowo

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0

ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 ECDL/ICDL Użytkowanie baz danych Moduł S1 Sylabus - wersja 5.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Użytkowanie baz danych. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 4 do SiWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji

Bardziej szczegółowo

Instrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy

Instrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy Instrukcja obsługi Zaplecza epk w zakresie zarządzania tłumaczeniami opisów procedur, publikacji oraz poradników przedsiębiorcy Spis treści: 1 WSTĘP... 3 2 DOSTĘP DO SYSTEMU... 3 3 OPIS OGÓLNY SEKCJI TŁUMACZENIA...

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA SYSTEMAMI INFORMATYCZNYMI W COLLEGIUM MAZOVIA INNOWACYJNEJ SZKOLE WYŻSZEJ

INSTRUKCJA ZARZĄDZANIA SYSTEMAMI INFORMATYCZNYMI W COLLEGIUM MAZOVIA INNOWACYJNEJ SZKOLE WYŻSZEJ Załącznik nr 3 do Zarządzenia nr 1/2013 Rektora Collegium Mazovia Innowacyjnej Szkoły Wyższej z dnia 31 stycznia 2013 r. INSTRUKCJA ZARZĄDZANIA SYSTEMAMI INFORMATYCZNYMI W COLLEGIUM MAZOVIA INNOWACYJNEJ

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA Załącznik nr 3 do umowy nr 16/DI/PN/2015 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA BŁĘDÓW I AWARII WORTALU PSZ Rozdział 1. ADMINISTROWANIE WORTALEM PSZ 1. Wykonawca zobowiązuje się do administrowania platformą

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA (zwany dalej: SOPZ )

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA (zwany dalej: SOPZ ) SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA (zwany dalej: SOPZ ) 1. Słownik pojęć W SOPZ następujące wyraŝenia i określenia będą miały znaczenie zgodnie z podanymi poniŝej definicjami: 1) narzędzie cały system

Bardziej szczegółowo

Ekonomia i finanse innowacyjny moduł programowy dla przedmiotu Podstawy przedsiębiorczości

Ekonomia i finanse innowacyjny moduł programowy dla przedmiotu Podstawy przedsiębiorczości Regulamin internetowej platformy edukacyjnej przygotowanej w ramach projektu Ekonomia i finanse innowacyjny moduł programowy dla przedmiotu Podstawy przedsiębiorczości 1 Postanowienia ogólne 1. Regulamin

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Instrukcja określająca zasady publikacji i aktualizacji danych w Biuletynie Informacji Publicznej Starostwa Powiatowego w Lublinie"

Instrukcja określająca zasady publikacji i aktualizacji danych w Biuletynie Informacji Publicznej Starostwa Powiatowego w Lublinie Starosty Lubelskiego z dnia 31 stycznia 2013 r. Instrukcja określająca zasady publikacji i aktualizacji danych w Biuletynie Informacji Publicznej Starostwa Powiatowego w Lublinie" 1 Postanowienia ogólne

Bardziej szczegółowo

Opis przedmiotu zamówienia

Opis przedmiotu zamówienia Zała cznik nr 4 Opis przedmiotu zamówienia Przedmiotem zamówienia jest usługa polegająca na dostawie i wdrożeniu Modułu płatności zintegrowanego systemu informatycznego klasy ERP w portalu ieczorna.pl

Bardziej szczegółowo

UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO. 2. Firmą z siedzibą w. przy ul., kod pocztowy..-..., REGON, NIP

UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO. 2. Firmą z siedzibą w. przy ul., kod pocztowy..-..., REGON, NIP UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO Zawarta w dnia. roku pomiędzy: 1. Firmą z siedzibą w. przy ul..., kod pocztowy.-..., REGON., NIP..,wpisaną do rejestru przedsiębiorców prowadzonego przez Sąd Rejonowy

Bardziej szczegółowo

INSTRUKCJA KROK PO KROKU Z UWZGLĘDNIENIEM ROLI

INSTRUKCJA KROK PO KROKU Z UWZGLĘDNIENIEM ROLI Instrukcja obsługi funkcjonalności Systemu Monitorowania Kształcenia Pracowników Medycznych (SMK) dla diagnostów laboratoryjnych i farmaceutów oraz podmiotów zaangażowanych w proces kształcenia ww. grup

Bardziej szczegółowo

którego nie stosuje się przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych na:

którego nie stosuje się przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych na: GŁÓWNY URZĄD GEODEZJI I KARTOGRAFII Warszawa, 2 października 2015 r. DEPARTAMENT NADZORU, KONTROLI I ORGANIZACJI SŁUŻBY GEODEZYJNEJ I KARTOGRAFICZNEJ NG-KiSZ.2611.6.2015 Do wszystkich Wykonawców Dotyczy:

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA

OPIS PRZEDMIOTU ZAMÓWIENIA Lubelskie Centrum Transferu Technologii Politechniki Lubelskiej ul. Nadbystrzycka 36, 20-618 Lublin Tel. 81 538 42 70, fax. 81 538 42 67; e-mail: lctt@pollub.pl OPIS PRZEDMIOTU ZAMÓWIENIA Do realizacji

Bardziej szczegółowo

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o. Grodzisk Wielkopolski, dnia 11.02.2013r. ZAMAWIAJĄCY z siedzibą w Grodzisku Wielkopolskim (62-065) przy ul. Szerokiej 10 realizując zamówienie w ramach projektu dofinansowanego z Programu Operacyjnego

Bardziej szczegółowo

GoBiz System platforma współpracy marektingowej

GoBiz System platforma współpracy marektingowej GoBiz System platforma współpracy marektingowej Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel platformy... 2 3. Główni odbiorcy systemu... 2 4. Przedmiot zamówienia...

Bardziej szczegółowo

Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE. Zamawiający:

Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE Zamawiający: ANETA GRYLA FIRMA HANDLOWO USŁUGOWA "CASMIR" 41-303 Dąbrowa Górnicza Ulica Bukowa 23 NIP : NIP 6291893246 1. Podstawa formalna zapytania

Bardziej szczegółowo

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert Sygnatura postępowania: BZP/31/DRI/2015 BGK BANK GOSPODARSTWA KRAJOWEGO Warszawa, 8 lipiec 2015 r. Zamawiający: Bank Gospodarstwa Krajowego Al. Jerozolimskie 7 00-955 Warszawa Biuro Zamówień Publicznych

Bardziej szczegółowo

Procedura Serwisowa. Procedura przyjmowania i obsługi zgłoszeń serwisowych dla Urządzeń

Procedura Serwisowa. Procedura przyjmowania i obsługi zgłoszeń serwisowych dla Urządzeń Procedura przyjmowania i obsługi zgłoszeń serwisowych dla Urządzeń CEL OGÓLNY Celem niniejszej procedury jest określenie sposobu postępowania, obsługi zgłoszeń oraz świadczenia serwisu przez wszystkie

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Opolskiego na lata 2007-2013 inwestujemy w

Bardziej szczegółowo

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

Bardziej szczegółowo

ZARZĄDZENIE NR 3. z dnia 29 maja 2015 r.

ZARZĄDZENIE NR 3. z dnia 29 maja 2015 r. KANCLERZ SZKOŁY GŁÓWNEJ HANDLOWEJ w Warszawie ADOIL/AZOWA-0161/ZK-3-198/15 ZARZĄDZENIE NR 3 z dnia 29 maja 2015 r. w sprawie zasad postępowania z dokumentacją i wykonywania czynności kancelaryjnych w Szkole

Bardziej szczegółowo

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel systemu... 2

Bardziej szczegółowo

Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk. Nip 848-172-84-22 ZAPYTANIE OFERTOWE

Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk. Nip 848-172-84-22 ZAPYTANIE OFERTOWE Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk Nip 848-172-84-22 ZAPYTANIE OFERTOWE Firma DOMSET Marcin Brochacki zwraca się z prośbą o przesłanie oferty cenowej

Bardziej szczegółowo

ZAPYTANIE OFERTOWE NR 1/2015/POIG82 Program Operacyjny Innowacyjna Gospodarka

ZAPYTANIE OFERTOWE NR 1/2015/POIG82 Program Operacyjny Innowacyjna Gospodarka Polanów, dnia 2 marca 2015 roku MACED sp. z o.o. ul. Bobolicka 18 76-010 Polanów Kraj: Polska Tel. 94-31-88-410 Nr KRS: 0000140490 NIP: 4990403778 REGON: 331367780 ZAPYTANIE OFERTOWE NR 1/2015/POIG82 Program

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH. Rozdział I Postanowienia wstępne.

INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH. Rozdział I Postanowienia wstępne. INSTRUKCJA ZARZĄDZANIA SYSTEMEM INFORMATYCZNYM SŁUŻĄCYM DO PRZETWARZANIA DANYCH OSOBOWYCH W GMINNYM ZESPOLE OBSŁUGI PLACÓWEK OŚWIATOWYCH W ŚWIERKLANACH Rozdział I Postanowienia wstępne. Na podstawie 3

Bardziej szczegółowo

OPIS WYMAGAŃ WOBEC PLATFORMY E-LEARNING ORAZ USŁUG UTRZYMANIA, USUWANIA BŁĘDÓW I AWARII DOTYCZĄCYCH PLATFORMY E-LEARNING

OPIS WYMAGAŃ WOBEC PLATFORMY E-LEARNING ORAZ USŁUG UTRZYMANIA, USUWANIA BŁĘDÓW I AWARII DOTYCZĄCYCH PLATFORMY E-LEARNING Załącznik nr 6 do umowy nr... z dnia... OPIS WYMAGAŃ WOBEC PLATFORMY E-LEARNING ORAZ USŁUG UTRZYMANIA, USUWANIA BŁĘDÓW I AWARII DOTYCZĄCYCH PLATFORMY E-LEARNING 1. Wymagania funkcjonalne dotyczące Platformy

Bardziej szczegółowo

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa 993200/UE/UE/1/2009/18/Z2/370/IN-462/2012 Warszawa, dnia 04 czerwca 2012 r. Informacja dla Wykonawców

Bardziej szczegółowo

Druk Poczty Polskiej Potwierdzenie Odbioru. Kody kreskowe mogą być przez System nadrukowane na ww. druki lub naklejone (naklejka z kodem kreskowym).

Druk Poczty Polskiej Potwierdzenie Odbioru. Kody kreskowe mogą być przez System nadrukowane na ww. druki lub naklejone (naklejka z kodem kreskowym). znak: NFA/2910-6-DK/08 Poznań, dnia 26 września 2008r. W związku pytaniami przesłanymi przez jednego z Wykonawców w dniu 23 września 2008 r. dotyczącymi przetargu nieograniczonego na zakup systemu obiegu

Bardziej szczegółowo

WYKONANIE OPROGRAMOWANIA DEDYKOWANEGO

WYKONANIE OPROGRAMOWANIA DEDYKOWANEGO Zapytanie ofertowe nr 1/2014 Wrocław, dn. 29.01.2014 Lemitor Ochrona Środowiska Sp. z o. o. ul. Jana Długosza 40, 51-162 Wrocław tel. recepcja: 713252590, fax: 713727902 e-mail: biuro@lemitor.com.pl NIP:

Bardziej szczegółowo

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie

Bardziej szczegółowo

Regulamin usług świadczonych drogą elektroniczną dla strony www.tauron-pe.pl

Regulamin usług świadczonych drogą elektroniczną dla strony www.tauron-pe.pl Regulamin usług świadczonych drogą elektroniczną dla strony www.tauron-pe.pl 2012-05-22 TAURON Obsługa Klienta Strona 2 z 10 Rozdział 1 Postanowienia ogólne 1 1. Niniejszy regulamin (dalej zwany Regulaminem)

Bardziej szczegółowo

Spis treści. 1. Utworzenie konta...3. 2. Dodanie zgłoszenia...5. 3. Realizacja zgłoszenia...7

Spis treści. 1. Utworzenie konta...3. 2. Dodanie zgłoszenia...5. 3. Realizacja zgłoszenia...7 0 Spis treści 1. Utworzenie konta...3 2. Dodanie zgłoszenia...5 3. Realizacja zgłoszenia...7 1 System wsparcia technicznego pozwala na szybką reakcję zespołu specjalistów oraz pełne udokumentowanie historii

Bardziej szczegółowo

Zapytanie ofertowe na: Zakup wartości niematerialnej i prawnej w postaci nowoczesnego systemu B2B wraz ze szkoleniem z obsługi ww.

Zapytanie ofertowe na: Zakup wartości niematerialnej i prawnej w postaci nowoczesnego systemu B2B wraz ze szkoleniem z obsługi ww. Warszawa, dnia 24.05.2012 r. Zapytanie ofertowe na: Zakup wartości niematerialnej i prawnej w postaci nowoczesnego systemu B2B wraz ze szkoleniem z obsługi ww. systemu Tytuł projektu: Automatyzacja procesów

Bardziej szczegółowo

ZAPYTANIA I WYJAŚNIENIA DO SIWZ

ZAPYTANIA I WYJAŚNIENIA DO SIWZ Projekt pn. Budowa użytecznych usług epuap oraz kreowanie świadomości mieszkańców w celu stworzenia Opole, 2014-11-24 AG.272.18.2014.HS Dotyczy: przetargu nieograniczonego pn. Dostawa licencji i wdrożenie

Bardziej szczegółowo

Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody.

Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody. Załącznik nr 1 Specyfikacja przedmiotu zamówienia Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody. Słowniczek pojęć Badanie

Bardziej szczegółowo

2007-2013 2014-2020. Wprowadzenie do systemów informatycznych wspierających wdrażanie programów operacyjnych w latach 2014-2020: SOWA i SL2014

2007-2013 2014-2020. Wprowadzenie do systemów informatycznych wspierających wdrażanie programów operacyjnych w latach 2014-2020: SOWA i SL2014 Wprowadzenie do systemów informatycznych wspierających wdrażanie programów operacyjnych w latach 2014-2020: SOWA i SL2014 Warszawa, dnia 25 czerwca 2015 r. 2007-2013 2014-2020 Generator Wniosków Aplikacyjnych

Bardziej szczegółowo

WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA

WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA Załącznik nr 24 do zarządzenia Dyrektora IRZiBŻ PAN w Olsztynie nr 118/2012 z dnia 30.04.2012r znak: ZP-PNK/D/2013/9/87 Olsztyn, dnia 17.10.2013 r. WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA

Bardziej szczegółowo