WZÓR UMOWY
Załącznik nr A
WZÓR UMOWY
Umowa nr …………….
zawarta w dniu r. w Łodzi
pomiędzy:
Skarbem Państwa – Izbą Celną w Łodzi ul. Xxxxxx 00, 00-000 Xxxx
NIP 727-01 354-702, REGON 000-00-00-00
zwaną dalej „Zamawiającym” w imieniu której działa
.................................................. - Dyrektor Izby Celnej w Łodzi
a
……………………………………………………………..
z siedzibą przy ul. ,
wpisanym do rejestru przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez
…………………………, , wpisanym do Centralnej Ewidencji Działalności
Gospodarczej, nr NIP: ………………….., nr REGON ,
reprezentowanym przez: …………………………………………………………………………………..
zwanym dalej „Wykonawcą”
Definicje pojęć i skrótów użytych w Umowie
Skrót | Opis |
Algorytm niedostępności | Wykorzystywany na potrzeby określenia poziomu niedostępności Systemu stosownie do postanowień § 8 ust. 7. Wskazaną w liczniku liczbę pełnych godzin niedostępności wylicza się w ten sposób, że sumuje się wszystkie minuty niedostępności Systemu w Etapie a następnie przelicza się pełne na godziny zaokrąglając w dół. Przykład: 3 Awarie po 52 minuty = 156 minut = 2 h 36 minut = 2 pełne godziny |
Akceptacja | Odbiór jakościowy produktu – ocena dostawy pod względem merytorycznym (jakościowym) przeprowadzona przez specjalistów z dziedziny, dla której wykonywany jest produkt. Stwierdzenie zgodności z kryteriami akceptacji produktu. Podpisanie Protokołu Akceptacji. |
Akceptacja z uwagami | Dostarczony produkt nie spełnia wszystkich uzgodnionych z Zamawiającym kryteriów jakości. Akceptacja z uwagami stanowi warunkowe przyjęcie produktu przy jednoczesnym zobowiązaniu Wykonawcy do dostarczenia produktu spełniającego wszystkie uzgodnione kryteria jakości w terminie 10 Dni roboczych. |
Analiza Ryzyka (moduł) | Moduł świadczący usługi analizy ryzyka na rzecz innych systemów administracji celnej. |
Biuletyn zmiany | Dokument załączany każdorazowo do dostawy oprogramowania opisujący zmiany/poprawki do dokumentacji technicznej i użytkowej Modułu, w zakresie bezpośrednio wynikającym z produktem będącym przedmiotem dostawy. W przypadku dostawy nowych funkcjonalności dokument ten powinien zawierać także instruktaż określający sposób obsługi tych funkcjonalności w Module. |
Błąd | Nieprawidłowość w funkcjonowaniu Systemu, polegająca w szczególności na tym, że: a) System nie pracuje prawidłowo w infrastrukturze teleinformatycznej określonej w Dokumentacji Systemu oraz nie jest skalowalny i rozwijalny; b) System nie stanowi kompletnego, zintegrowanego rozwiązania, spełniającego wymagania określone w Dokumentacji Systemu, z zapewnieniem funkcjonalności i wydajności tam określonej; c) System nie jest zgodny z Dokumentacją Systemu w innym zakresie niż określony w lit. a -b; Nieprawidłowości wynikające z błędu użytkownika w obsłudze Systemu. Błędy ze względu na ograniczenia w poprawnym działaniu Systemu są określane priorytetem od 1 do 4. |
Błąd - Priorytet 1 | Błąd uniemożliwiający działanie Systemu XXXXXX (wraz z podsystemem Moduł Czarna Skrzynka), lub o dużej uciążliwości, spowodowany błędami w oprogramowaniu, wadliwym funkcjonowaniem oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej. Błąd powoduje nie funkcjonowanie całego systemu, jednego z jego komponentów, uniemożliwia całkowicie wykonanie choćby jednej ważnej funkcji Systemu lub uniemożliwia pracę użytkowników, w szczególności poprzez |
Skrót | Opis |
zawieszanie się aplikacji, samoczynne zamykanie się aplikacji niezgodne z dokumentacją, brak możliwości obsługi procesów biznesowych, wadliwy zapis danych, brak możliwości korzystania z danych zapisanych w bazach danych poprzez obsługę aplikacji, niewłaściwy odczyt danych w czasie obsługi aplikacji. Jako błąd traktowane jest również co najmniej dwukrotny spadek wydajności systemu. Zakłada się przy tym, że błąd można ponownie odtworzyć, że występuje on w ostatnim nie zmienionym wydaniu oprogramowania i nie jest spowodowany niewłaściwą obsługą użytkownika, ani błędami systemu operacyjnego. Błąd powoduje powstawanie wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika i specyfikacji funkcjonalnej. | |
Błąd - Priorytet 2 | Błąd o dużej uciążliwości ujawniony w obszarze zastosowań oprogramowania, który uniemożliwia w sposób bezpośredni wykonanie funkcji programu. Zakłada się przy tym, że błąd można ponownie odtworzyć, że występuje on w ostatnim nie zmienionym wydaniu oprogramowania i nie jest spowodowany niewłaściwą obsługą użytkownika, ani błędami systemu operacyjnego. Błąd może zostać zakwalifikowany jako poważny, gdy realizowaną funkcję można obejść tak, aby otrzymać wyniki zgodne z opisanymi w instrukcji użytkownika i specyfikacji funkcjonalnej. |
Błąd - Priorytet 3 | Błąd o średniej uciążliwości, który nie stanowi zagrożenia wykonania funkcji Systemu XXXXXX wraz z podsystemem Moduł Czarna Skrzynka |
Błąd - Priorytet 4 | Błąd o niskiej uciążliwości, który nie stanowi zagrożenia wykonania funkcji programu i jest związany z interfejsem użytkownika, kolejnością wykonania operacji, rozmiarem, kolorem ekranu i czcionki, a także innej nie powodującej powstawania wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika. |
CCN/CSI | Common Communication Network/Common System Interface Wspólna Sieć Komunikacyjna/Wspólny Interfejs Systemów. |
COTS | Powszechnie dostępne oprogramowanie standardowe produkowane seryjnie lub gotowe do sprzedaży. |
CS/RD | Central Services/Reference Data - dane wspólnotowe jakie znajdują się w CS/RD to np. COL (Customs Office List) Baza danych CS/RD administrowana jest przez zespół centralny w Brukseli. Dostęp administracyjny do bazy danych zapewnia strona internetowa NCTS-CO. Krajowe administracje zasilają COL danymi i odpowiadają za aktualizację tych danych. |
Dzień roboczy | Dla potrzeb niniejszej Umowy to dzień niebędący sobotą albo niedzielą lub innym dniem ustawowo wolnym od pracy. |
DGTAXUD | Dyrekcja Generalna Komisji Europejskiej ds. Podatków i Unii Celnej. |
ECN | EDI/CSI Node. Aplikacja, której zadaniem jest wymiana komunikatów pomiędzy celnym systemem obsługi eksportu/tranzytu w danym kraju i jego odpowiednikami w pozostałych krajach. Jest tworzona w ramach europejskiego projektu AES/ECS i przekazywana zainteresowanym krajom. |
Skrót | Opis |
Incydent | Zdarzenie zgłoszone przez użytkownika do Help Desk, które nie jest częścią poprawnego działania systemów, które może powodować dla użytkownika przerwę w dostarczaniu usługi związanej z systemami, względnie obniżenie jej jakości. |
ISZTAR3 | Informacyjny System Zintegrowanej Taryfy Celnej |
NCTS | Nowy Skomputeryzowany System Tranzytowy |
OSOZ2 | Ogólnopolski System Obsługi Zabezpieczeń |
PDR | Podsystem Danych Referencyjnych |
PWK | Podsystem Wymiany Komunikatów |
Priorytet | Parametr wyznaczany w celu określenia wagi zgłaszanego błędu; jest kombinacją wpływu (miara określająca stopień wpływu błędu na użytkowników i działanie Systemu) i pilności (miara określająca wymagany czas rozwiązania błędu). Przyjęto następującą klasyfikację: - Priorytet 1 – Krytyczny; - Priorytet 2 – Wysoki; - Priorytet 3 – Średni; - Priorytet 4 – Niski. |
Podpis elektroniczny | Dane dołączone do danych lub ich przekształcenie kryptograficzne, które pozwalają udowodnić pochodzenie danych i zabezpieczyć je przed fałszerstwem (nieuprawnioną zmianą). |
Problem | Nieznana przyczyna jednego lub wielu incydentów. |
Produkt | Efekt świadczenia usług developerskich, czyli dostarczona przez Wykonawcę dokumentacja lub oprogramowanie przeznaczone do instalacji w środowisku testowym lub produkcyjnym. |
Strona | Zamawiający lub Wykonawca, w zależności od kontekstu. |
Strony | łącznie: Zamawiający i Wykonawca. |
Wsparcie utrzymania Systemu NCTS | Usługa wsparcia zewnętrznego dla Zespołu odpowiedzialnego za utrzymanie Systemu NCTS, świadczona przez Wykonawcę, w zakresie zgłoszonych błędów i incydentów/problemów dotyczących nieprawidłowości w funkcjonowaniu Systemu. |
XML | Extensible Markup Language, rozszerzalny język znaczników, uproszczony podzbiór SGML (standardowego uogólnionego języka znaczników wg standardu ISO 8879/86), opisujący schemat znakowania, który pozwala zaznaczyć logiczną strukturę dokumentów niezależnie od używanego systemu i sprzętu. |
§ 1.
PRZEDMIOT UMOWY
1. Wykonawca zobowiązuje się świadczyć wyspecjalizowane usługi oraz dostarczać produkty informatyczne zapewniające utrzymanie Nowego Skomputeryzowanego Systemu Tranzytowego NCTS, którego charakterystyka została przedstawiona w Załączniku nr 1 do Umowy, zwanego dalej Systemem w szczególności do:
1) aktualizacji dokumentacji powykonawczej Systemu;
2) świadczenia usługi zewnętrznego wsparcia utrzymania Systemu określonej w § 1 ust. 2 i 3, począwszy od dnia następnego po dniu zawarcia Umowy;
3) wprowadzania zmian do Systemu wynikających z konieczności bieżącej ich aktualizacji, w zakresie określonym w § 4 ust. 1;
4) realizacja zadania polegającego na przygotowaniu i realizacji koncepcji wraz z dokumentacją umożliwiającą przystosowanie Systemu NCTS do pełnienia roli archiwum przez okres minimum 5 lat oraz wyłączenia i zarchiwizowania systemu po okresie działania jako archiwum.
2. Wykonawca zobowiązuje się świadczyć usługę zewnętrznego wsparcia utrzymania Systemu, o której mowa w ust. 1 pkt 2 w zakresie istniejących już funkcjonalności aplikacji MCC, jak również w odniesieniu do nowych funkcjonalności Systemu wytworzonych w czasie trwania niniejszej Umowy.
3. Wykonawca zobowiązuje się świadczyć usługę zewnętrznego wsparcia utrzymania Systemu, o której mowa w § 1 ust. 1 pkt 2 wykonując w tym celu następujące czynności:
1) analizowanie, diagnozowanie przyczyn i rozwiązywanie zgłaszanych przez Zamawiającego błędów oraz usuwania ich skutków w zakresie funkcjonowania Systemu,
2) analizowanie, diagnozowanie przyczyn i rozwiązywanie zgłaszanych przez Zamawiającego incydentów/problemów oraz usuwania ich skutków w zakresie funkcjonowania Systemu,
3) udzielanie konsultacji Zespołowi odpowiedzialnemu za utrzymanie Systemu po stronie Zamawiającego, w zakresie:
a) wykrywania przyczyn powiązanych ze sobą incydentów,
b) tworzonych rozwiązań zmierzających do uniknięcia wszelkich przyszłych incydentów tego samego typu,
c) rozwiązywania problemów,
d) usuwania błędów,
e) eksploatacji,
4) prowadzenie, utrzymywanie i udostępnianie Zamawiającemu następujących rejestrów:
a) Rejestr Konsultacji zawierający co najmniej:
− wskazanie komponentu Systemu,
− zwięzły opis przedmiotu konsultacji,
− datę i godzinę zgłoszenia konsultacji do Wykonawcy,
− datę i godzinę udzielenia konsultacji,
− opis udzielonej odpowiedzi,
− potwierdzenie udzielenia konsultacji przez osobę, która o taką konsultację wystąpiła,
b) Rejestr Incydentów/Problemów zawierający, co najmniej:
− wskazanie obszaru Systemu, którego dotyczył incydent/problem,
− datę i godzinę zgłoszenia incydentu/problemu do Wykonawcy,
− zwięzły opis incydentu/problemu,
− opis przekazanego rozwiązania,
− datę i godzinę rozwiązania, które pozwoliło usunąć incydent/problem,
− datę i godzinę potwierdzenia zamknięcia incydentu/problemu,
c) Rejestr Błędów zawierający, co najmniej:
− wskazanie komponentu Systemu, którego dotyczył błąd,
− datę i godzinę zgłoszenia błędu do Wykonawcy,
− zwięzły opis błędu,
− datę i godzinę dostarczenia do Kierownika Projektu Zamawiającego rozwiązania (ostatecznego lub tymczasowego), które pozwoliło dokonać usunięcia błędu, wraz z Protokołem Xxxxxxx, którego wzór określono w Załączniku nr 2 do Umowy (jeżeli usunięcie błędu wiązało się z dostawą oprogramowania),
− rozliczenie czasu i czynności wykonanych przez Wykonawcę w przypadku, gdy praca Wykonawcy była wykonywana w siedzibie IC w Łodzi (lub w innym miejscu eksploatacji Systemu),
− datę i godzinę potwierdzenia zamknięcia błędu,
wraz z odpowiednim raportem z testów lub dokumentami potwierdzającymi wykonanie innych czynności będących podstawą zamknięcia zgłoszenia błędu.
d) Rejestr Zgłoszeń Gwarancyjnych zawierający, co najmniej:
− wskazanie komponentu Systemu, którego dotyczyło,
− zwięzły opis zgłoszenia gwarancyjnego,
− datę i godzinę zgłoszenia gwarancyjnego do Wykonawcy,
− datę i godzinę usunięcia błędu w ramach gwarancji,
− potwierdzenie przez osobę upoważnioną po stronie Zamawiającego zamknięcia zgłoszenia gwarancyjnego.
5) Dostarczenie do Kierownika Projektu Zamawiającego zaktualizowanej skonsolidowanej dokumentacji powykonawczej Systemu, wymienionej w Załączniku nr 3 do Umowy najpóźniej 10 Dni roboczych przed zakończeniem każdego z Etapów, przy czym do odbioru dokumentacji zastosowanie mają postanowienia § 5 oraz zasady odbioru i kryteria jakości dokumentacji określone w Załączniku nr 4 do Umowy.
4. Produkty będące efektem realizacji zadań, o których mowa w § 1 ust. 1 pkt 1 - 4 Wykonawca zobowiązany jest dostarczyć Kierownikowi Projektu Zamawiającego za pośrednictwem poczty elektronicznej lub w innej uzgodnionej formie.
5. Zadania, o których mowa w § 1 ust. 1 pkt 1 - 4 Wykonawca zobowiązany jest świadczyć w siedzibie Zamawiającego tj. Izba Celna w Łodzi ul. Xxxxxxxxxx 00 (zwanej dalej „siedzibą IC w Łodzi”) lub innej lokalizacji wskazanej przez Zamawiającego.
§ 2.
TERMIN REALIZACJI PRZEDMIOTU UMOWY
1. Szczegółowe zasady realizacji przedmiotu Umowy określa Harmonogram Realizowanych Zadań i Planowanych Płatności określony w Załączniku nr 5 Umowy.
2. Wykonawca zobowiązuje się zrealizować:
1) Etap I od dnia rozpoczęcia realizacji Umowy (tj. od daty o której mowa w § 1 ust. 1 pkt 2), przez okres 3 miesięcy,
2) Etap II od dnia następnego po dniu zakończenia I Etapu, przez okres 3 miesięcy;
3. W Etapie I Umowy, Wykonawca zobowiązany jest świadczyć usługę zewnętrznego wsparcia Systemu NCTS, realizować zadanie wprowadzania zmian w trybie wniosków zmiany, a ponadto zobowiązany będzie opracować koncepcję dla systemu NCTS, pełnienia przez niego roli archiwum przez okres minimum 5 lat.
4. W Etapie II Umowy, Wykonawca zobowiązany jest świadczyć usługę zewnętrznego wsparcia Systemu NCTS, realizować zadanie wprowadzania zmian w trybie wniosków zmiany oraz w przypadku podjęcia
przez Xxxxxxxxxxxxx decyzji o wdrożeniu koncepcji dostarczonej w Etapie I realizację przez Zamawiającego wdrożenia przyjętej koncepcji.
§ 3.
USŁUGA ZEWNĘTRZNEGO WSPARCIA UTRZYMANIA SYSTEMU NCTS
1. Wykonawca zobowiązuje się świadczyć usługę zewnętrznego wsparcia utrzymania w zakresie określonym w § 1 ust. 2 i ust.3.
2. W ramach realizacji obowiązku opisanego w § 1 ust. 3 pkt 1, w przypadku wystąpienia błędu Zamawiający przekaże Wykonawcy Zgłoszenie Błędu według wzoru określonego w Załączniku nr 6 do Umowy:
1) faksem na numer: , lub
2) pocztą elektroniczną, na adres: : …………
3. Wykonawca zobowiązuje się do przekazania Zamawiającemu potwierdzenia przyjęcia Zgłoszenia Błędu niezwłocznie, lecz nie później niż w czasie 15 minut od otrzymania zgłoszenia w takiej samej formie, w jakiej nastąpiło zgłoszenie przez Zamawiającego błędu.
4. Obowiązki Wykonawcy w zależności od priorytetu zgłoszonego błędu przedstawiają się następująco:
1) Błąd - Priorytet 1 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go i uruchomić System (w terminie 8 godzin od zgłoszenia, przy czym Strony dopuszczają zastosowanie przez Wykonawcę rozwiązania tymczasowego umożliwiającego prawidłowe działanie Systemu. W przypadku zastosowania rozwiązania tymczasowego Wykonawca zobowiązuje się usunąć Błąd - Priorytet 1 w terminie uzgodnionym z Zamawiającym, nie później jednak niż w ciągu 48 godzin od chwili jego zgłoszenia.
2) Błąd - Priorytet 2 - Wykonawca zobowiązuje się określić przyczynę błędu, usunąć go i uruchomić System w terminie 48 godzin od zgłoszenia, przy czym Strony dopuszczają zastosowanie przez Wykonawcę rozwiązania tymczasowego umożliwiającego prawidłowe działanie Systemu. W przypadku zastosowania rozwiązania tymczasowego Wykonawca zobowiązuje się usunąć Błąd - Priorytet 2 w terminie uzgodnionym z Zamawiającym, nie później jednak niż w ciągu 96 godzin od chwili jego zgłoszenia.
3) Błąd - Priorytet 3 - Wykonawca zobowiązuje się określić przyczynę błędu i usunąć go w terminie 7 dni od zgłoszenia.
4) Błąd - Priorytet 4 - Wykonawca zobowiązuje się określić przyczynę błędu i usunąć go w terminie 1 miesiąca od zgłoszenia.
5. Po zdiagnozowaniu i określeniu przyczyny błędu i zastosowaniu rozwiązania przekazanego przez Wykonawcę, Zamawiający, przy udziale Wykonawcy przeprowadzi testy i/lub inne czynności sprawdzające poprawność działania Systemu w środowisku testowym Zamawiającego (lub
produkcyjnym, w przypadku, gdy przeprowadzenie czynności sprawdzających lub testów w środowisku testowym jest niemożliwe lub niezasadne), co zostanie potwierdzone poprzez podpisanie przez Kierownika Projektu Zamawiającego i Kierownika Projektu Wykonawcy na formularzu Zgłoszenia Błędu w części „Potwierdzenie usunięcia wady”.
6. Jeżeli w ramach usuwania błędu Wykonawca przekazuje Zamawiającemu nową wersję oprogramowania, do dostaw i odbioru tego oprogramowania Strony stosują odpowiednio postanowienia § 5 Umowy.
7. W przypadku błędu Systemu spowodowanego wadliwym funkcjonowaniem oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej, Wykonawca jest zobowiązany do zdiagnozowania przyczyny błędu oraz do przywrócenia prawidłowego działania Systemu, po usunięciu błędu przez właściwego dostawcę danego oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej. Przy usuwaniu tego typu błędu przez Wykonawcę stosuje się odpowiednio zapisy ust. 4, z tym, że do czasu uruchomienia Systemu przez Wykonawcę nie wlicza się czasu, w jakim miało miejsce usuwanie błędu przez właściwego dostawcę danego oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej. Jeżeli natomiast błąd wystąpił w konfiguracji takiego oprogramowania systemowego, aplikacyjnego lub infrastruktury technicznej, a parametry konfiguracji zostały dostarczone przez Wykonawcę, jest on zobowiązany do usunięcia błędu na zasadach określonych w ust. 4 - 6.
8. Strony ustalają, iż w przypadku rozbieżności między Stronami, co do zakwalifikowania błędu
o określonym priorytecie, to Naczelnik Wydziału Izby Celnej w Łodzi nadzorującego utrzymanie Systemu NCTS będzie decydował o jego ostatecznej klasyfikacji.
9. W przypadku pojawienia się w Systemie incydentu/problemu w ramach realizacji obowiązku opisanego w § 1 ust. 3 pkt 2, którego Zamawiający w momencie wystąpienia nie jest w stanie zdefiniować jako błąd, Zamawiający wyśle do Wykonawcy Zgłoszenie Incydentu/Problemu, według wzoru określonego w Załączniku nr 7 do Umowy:
1) faksem na nr: , lub
2) pocztą elektroniczną na adres: …………………….
10. Wykonawca zobowiązuje się do przekazania Zamawiającemu potwierdzenia przyjęcia Zgłoszenia Incydentu/Problemu niezwłocznie, lecz nie później niż w czasie 15 minut od otrzymania zgłoszenia w takiej samej formie, w jakiej nastąpiło zgłoszenie przez Zamawiającego incydentu/problemu.
11. Wykonawca zobowiązuje się niezwłocznie, jednak nie później niż w terminie 2 Dni roboczych od daty przekazania zgłoszenia, zdiagnozować incydent/problem oraz przekazać Zamawiającemu opis rozwiązania incydentu/problemu (faksem lub pocztą elektroniczną), zawierający także źródło (przyczynę) jego zaistnienia.
12. Następnego Dnia roboczego po rozwiązaniu incydentu/problemu przez Wykonawcę, Xxxxxx dokonają odbioru polegającego na sprawdzeniu prawidłowości przekazanego rozwiązania.
13. Odbiór, o którym mowa w ust. 12, właściwy Kierownik Projektu Zamawiającego i Kierownik Projektu Wykonawcy potwierdzają na podpisanym formularzu Zgłoszenia Incydentu/Problemu w miejscu na to przeznaczonym.
14. Jeżeli w wyniku zgłoszenia incydentu/problemu okaże się, że jest on wynikiem wystąpienia w Systemie błędu, stosuje się procedury właściwe dla błędów, a w opisie rozwiązań incydentu/problemu w Rejestrze Incydentów/Problemów, Wykonawca wskazuje, że stwierdzono wystąpienie błędu.
15. W przypadku, o którym mowa w ust. 14, Wykonawca niezwłocznie, jednak nie później niż w terminie, o którym mowa w ust. 11, poinformuje Zamawiającego o wystąpieniu błędu.
16. Wykonawca zobowiązuje się wykonywać konsultacje, o których mowa w § 1 ust. 3 pkt 3, w Dni robocze w godzinach między 7-16, za pośrednictwem telefonu nr ………… (nr telefonu/telefonów Wykonawcy), a w przypadku braku możliwości skontaktowania się Stron przez telefon, lub udzielenia niewystarczających informacji przez Wykonawcę, za pośrednictwem poczty elektronicznej
………………….(adres poczty elektronicznej Wykonawcy).
17. Wykonawca zobowiązany jest do udzielenia konsultacji, o których mowa w ust. 16, niezwłocznie, jednakże w terminie nie dłuższym niż 4 godziny od momentu wystąpienia z prośbą o konsultację.
18. Udzielenie konsultacji przez Wykonawcę potwierdza w Rejestrze Konsultacji osoba, która o tę konsultację wystąpiła. Osobami uprawnionymi do zgłoszenia potrzeby konsultacji są osoby których dane Kierownik Projektu po stronie Zamawiającego przekaże Wykonawcy, w terminie najpóźniej 5 Dni roboczych od daty zawarcia Umowy.
19. Wykonawca zobowiązuje się sporządzić i dostarczyć Kierownikowi Projektu Zamawiającego, w terminie 3 Dni roboczych od daty zakończenia każdego z Etapów, podpisany przez Kierownika Projektu Wykonawcy Raport z Usługi Wsparcia zawierający wykaz wszystkich prac wykonanych w ramach tej usługi przez Wykonawcę w danym Etapie. Wzór Raportu z Usługi Wsparcia został określony w Załączniku nr 8 do Umowy.
20. Wykonawca zobowiązuje się uwzględnić w Raporcie z Usługi Wsparcia:
1) zestawienie wszystkich danych zawartych w Rejestrze Konsultacji;
2) zestawienie wszystkich danych zawartych w Rejestrze Incydentów/Problemów;
3) zestawienie wszystkich danych zawartych w Rejestrze Błędów;
4) zestawienie wszystkich danych zawartych w Rejestrze Zgłoszeń Gwarancyjnych
oraz oświadczenie Wykonawcy o zgodnym z umową aktualizowaniu w tym okresie Bazy Wiedzy.
21. Kierownik Projektu Zamawiającego w terminie do 3 Dni roboczych weryfikuje zgodność przedłożonego przez Wykonawcę Raportu z Usługi Wsparcia.
22. W przypadku stwierdzenia, iż Raport z Usługi Wsparcia zawiera nieprawidłowości, w szczególności, że:
1) usługa zewnętrznego wsparcia utrzymania Systemu nie została w pełni zrealizowana w danym Etapie, tzn. że nie została zrealizowana którakolwiek z czynności określonych w ust. 1, której termin realizacji upływał przed zakończeniem Etapu;
2) dane zawarte w poszczególnych zestawieniach są niepełne lub nieprawdziwe, a w szczególności nie odpowiadają rzeczywistemu zakresowi prac wykonanych przez Wykonawcę,
Kierownik Projektu Zamawiającego zwraca Raport z Usługi Wsparcia Wykonawcy wraz z uwagami.
23. Wykonawca zobowiązuje się usunąć przyczyny uwag w terminie 3 Dni roboczych i ponownie przedstawić Raport z Usługi Wsparcia Kierownik Projektu Zamawiającego, przy czym do ponownego odbioru Raportu znajdują zastosowanie postanowienia ust. 25-26.
24. W przypadku, gdy Kierownik Projektu Zamawiającego stwierdzi, że usługa opisana w Raporcie z Usługi Wsparcia została w danym etapie zrealizowana w sposób prawidłowy, podpisuje Raport z Usługi Wsparcia.
25. Podpisany przez Kierownik Projektu Zamawiającego Raport z Usługi Wsparcia potwierdza dokonanie odbioru usługi zewnętrznego wsparcia utrzymania Systemu w określonym Etapie.
26. Wykonawca zobowiązuje się świadczyć usługę zewnętrznego wsparcia utrzymania Systemu, w zakresie określonym w § 1 ust. 3 w Dni robocze w godzinach 7-16 lub innych uzgodnionych z Zamawiającym.
27. Wykonawca zobowiązuje się wykonywać usługę wsparcia utrzymania Systemu w zakresie określonym w § 1 ust. 3 w Izbie Celnej w Łodzi, oraz o ile wykonywanie obowiązków tego wymaga, także w innych lokalizacjach (na terenie całej Polski), w których jest eksploatowany System.
§ 4.
WPROWADZANIE ZMIAN
1. W ramach realizacji obowiązku określonego w § 1 ust. 1 pkt 3 Umowy Wykonawca zobowiązany jest do wprowadzenia zmian w limicie nie przekraczającym 50 osobodni (przy czym 1 osobodzień jest rozumiany jako wykonywanie prac przez 1 osobę przez 8 godzin). Strony ustalają, że wynagrodzenie nie będzie przysługiwało za niewykorzystane osobodni. Ilość, termin i zakres dokonywanych w Systemie zmian wynikać będzie w szczególności:
1) ze zmian prawa na poziomie wspólnotowym i krajowym, w zakresie dostosowania Systemu do wymagań Unijnego Kodeksu Celnego;
2) z wymagań wynikających ze współpracy Systemu z innymi systemami funkcjonującymi w administracji celnej;
3) z wymagań wynikających z potrzeb dostępu do danych systemu NCTS, archiwizacji danych, działania aplikacji MCC jako archiwum,
4) opracowania koncepcji przygotowania danych do przekazania do Archiwum Państwowego lub zniszczenia po pięcioletnim okresie działania systemu NCTS jako archiwum.
2. W przypadku zaistnienia okoliczności, skutkujących koniecznością dokonania zmian w komponentach Systemu, właściwy Kierownik Projektu Zamawiającego na formularzu Zgłoszenia Zmiany, określonym w Załączniku nr 9 do Umowy, przekazuje Wykonawcy opis zmiany wraz z proponowanym przez Zamawiającego sposobem jej realizacji. Po otrzymaniu Zgłoszenia Zmiany Kierownik Projektu Wykonawcy może w terminie 2 Dni roboczych od otrzymania ww. Zgłoszenia zaproponować pisemnie Kierownikowi Projektu Zamawiającego inny sposób realizacji zmiany. Po zapoznaniu się z opinią Kierownika Projektu Wykonawcy ostateczną decyzję w sprawie sposobu realizacji zmiany podejmuje Kierownik Projektu Zamawiającego.
3. Po końcowym ustaleniu sposobu realizacji zmiany, w terminie 5 Dni roboczych od przekazania Wykonawcy Zgłoszenia, Kierownik Projektu Zamawiającego wraz z Kierownikiem Projektu Wykonawcy uzgadniają w trybie roboczym pracochłonność i termin wykonania zmian.
4. W przypadku braku zgody Xxxxxxxxxxxxx na wskazaną przez Wykonawcę pracochłonność wykonania zmiany, Zamawiający odstępuje od realizacji tej zmiany, a jej realizację może zlecić firmie zewnętrznej.
5. Kierownik Projektu Zamawiającego z uwzględnieniem ustaleń dokonanych w trybie określonym w ust. 2 i 3 sporządza w 3 egzemplarzach Wniosek Zmiany, którego wzór został określony w Załączniku nr 10 do Umowy.
6. Podpisany przez Kierownika Projektu Zamawiającego Wniosek Zmiany jest następnie zatwierdzany, poprzez jego podpisanie, przez Zamawiającego i Wykonawcę. Po stronie Zamawiającego upoważnione do zatwierdzenia Wniosku Zmiany są osoby wymienione w Załączniku nr 11 Zespół Realizacyjny Zamawiającego. Wniosek Zmiany jako pierwszy zatwierdza Zamawiający i następnie przekazuje go Wykonawcy najpóźniej następnego Dnia roboczego po dniu podpisania. W przypadku, gdy osoba uprawniona do reprezentowania Zamawiającego odmówi zatwierdzenia przedłożonego Wniosku Zmiany Strony odstępują od realizacji czynności określonej we Wniosku Zmiany.
7. Termin realizacji, określony we Wniosku Zmiany liczony jest od daty podpisania go przez Zamawiającego i nie może on wykraczać poza termin realizacji I Etapu Umowy.
8. Wprowadzanie konkretnej zmiany do Przedmiotu Umowy jest realizowane przez Zamawiającego i obejmuje:
a) wprowadzenie zmiany do wersji testowej Systemu,
b) testowanie Systemu po dostarczeniu zmiany przez Wykonawcę
c) wdrożenie zmiany do wersji produkcyjnej Systemu.
9. Strony ustalają, iż wynik zrealizowania przez Wykonawcę wszystkich zmian opisanych w pojedynczym Wniosku Zmiany będzie odbierany jako jeden produkt, na zasadach określonych w § 5 Umowy.
Potwierdzeniem dokonania odbioru końcowego zmiany/zmian określonych we Wniosku Zmiany jest Protokół Odbioru Produktu, który stanowi Załącznik nr 12 do Umowy.
§ 5.
WARUNKI DOSTAW I ODBIORU
1. Strony ustalają, iż postanowienia ust. 2 - 6 niniejszego paragrafu znajdują zastosowanie do odbioru produktów Umowy powstałych:
1) w wyniku realizacji obowiązku, o którym mowa w § 1 ust. 1 pkt 4;
2) w wyniku wprowadzania zmian do Systemu, o których mowa § 1 ust. 1 pkt 3 w ramach realizacji Wniosku Zmiany zgodnie z § 4 Umowy;
3) w wyniku realizacji obowiązku, o którym mowa w § 1 ust. 3 pkt 5;
4) w wyniku usunięcia przez Wykonawcę błędu (także w ramach gwarancji), które pociągało za sobą konieczność dostawy nowej wersji oprogramowania (§ 3 ust. 6).
2. Wykonawca zobowiązuje się dostarczyć wszelkie Produkty wytworzone w ramach realizacji Umowy wraz z kodami źródłowymi oraz dokumentacją do Kierownika Projektu Zamawiającego, przy czym:
1) Wykonawca zobowiązuje się dostarczyć:
a) wersję instalacyjną oprogramowania Systemu na nośnikach CD, lub innych uzgodnionych z Kierownikiem Projektu Zamawiającego, oznaczonych nazwą Systemu, numerem wersji i datą dostawy,
b) instrukcję instalacji dostarczonego oprogramowania,
c) protokół z testów wewnętrznych Wykonawcy dostarczonego oprogramowania wraz z wykonanymi przez zespół testerów Wykonawcy scenariuszami testowymi lub szczegółowym opisem zakresu wykonanych testów w przypadku, gdy nie były one wykonywane w oparciu o scenariusze,
d) protokół z testów poinstalacyjnych realizowanych w środowisku testowym Wykonawcy,
e) protokół z testów iteracyjnych, o ile takie były przeprowadzane,
f) biuletyny zmiany do oprogramowania, oraz dokumentacji technicznej i użytkowej, w zakresie związanym z dostarczanym produktem;
2) Wykonawca zobowiązuje się dostarczyć dokumentację w formie elektronicznej na nośniku CD lub innym uzgodnionym z Kierownikiem Projektu Zamawiającego;
3) Wykonawca zobowiązuje się dostarczyć kody źródłowe oprogramowania na nośniku CD lub innym uzgodnionym z Kierownikiem Projektu Zamawiającego, w formatach odpowiednich dla języków oprogramowania, w których zostało oprogramowanie napisane.
3. W przypadku aktualizacji dokumentacji systemowej, o której mowa w § 5 ust. 1 pkt 1, Wykonawca zobowiązuje się dostarczyć dokumentację w formie elektronicznej na nośniku CD lub innym uzgodnionym z Kierownikiem Projektu Zamawiającego oraz w jednym egzemplarzu w wersji papierowej.
4. Na każdy odbiór Produktu dokonywany przez Strony składają się:
1) Odbiór ilościowy polegający na stwierdzeniu przez Xxxxxx, że dostawa, o której mowa w ust. 2 zawiera wszystkie wymagane elementy, co zostaje potwierdzone Protokołem Dostawy Produktu, zgodnym ze wzorem określonym w Załączniku nr 2 do Umowy, podpisanym przez Kierownika Projektu Zamawiającego oraz Kierownika Projektu Wykonawcy i Kierownika Jakości Wykonawcy;
2) Odbiór jakościowy:
a) W odniesieniu do dokumentacji polega na stwierdzeniu przez Strony, iż dokumentacja prawidłowo opisuje zmiany w Systemie, działanie Systemu po zmianie oraz zmiany w sposobie jego funkcjonowania, a ponadto, że spełnia wymagania jakościowe określone w Załączniku nr 4 do Umowy,
b) W odniesieniu do oprogramowania polega na stwierdzeniu przez Strony, że spełnia ono wymagania jakościowe określone w Załączniku nr 4 do Umowy, a także, że:
− oprogramowanie powstałe na skutek realizacji postanowień § 4, zostało wykonane zgodnie z wymaganiami określonymi przez Zamawiającego we Wniosku Zmiany, o którym mowa w § 4 ust. 5-9,
− oprogramowanie powstałe na skutek realizacji postanowień § 3 ust. 6 zostało wykonane zgodnie z architekturą Systemu i nie zmienia jego funkcjonalności, a także sposobu korzystania z niego,
c) W odniesieniu do kodów źródłowych polega na przeprowadzeniu przez Strony prób ich kompilacji i konsolidacji, a także na stwierdzeniu przez Strony, że kody źródłowe spełniają kryteria i wymogi określone w Załączniku nr 13 do Umowy, przy czym Zamawiający zastrzega sobie prawo zlecenia firmie zewnętrznej przeprowadzenia czynności związanych z odbiorem jakościowym kodów źródłowych lub okresowym audytem ich stanu. Wykonawca na żądanie Zamawiającego zobowiązany jest udostępnić narzędzie, przy pomocy którego dokonywał kompilacji i konsolidacji kodów wraz z instrukcją i niezbędnymi licencjami, umożliwiające Zamawiającemu ich kompilację i konsolidację,
zostaje potwierdzony Protokołem Akceptacji Produktu, zgodnym ze wzorem określonym w Załączniku nr 14 do Umowy. Protokół Akceptacji Produktu podpisywany jest przez Kierownika Projektu Zamawiającego i Kierownika Projektu Wykonawcy.
3) Odbiór końcowy polegający na stwierdzeniu przez Strony, że Produkt, w tym każdy jego element będący przedmiotem dostawy, spełnia warunki określone w Umowie oraz w przypadku produktu, o którym mowa w § 5 ust. 1 pkt 2, że spełnia on także wymagania określone we Wniosku Zmiany,
o którym mowa § 4 ust. 5-9.
Odbiór końcowy produktu zostaje potwierdzony Protokołem Odbioru Produktu, zgodnym ze wzorem określonym w Załączniku nr 12 do Umowy, podpisywanym przez Kierownika Projektu Zamawiającego i Kierownika Projektu Wykonawcy.
5. Szczegółowe zasady dotyczące procedury dostaw, akceptacji i odbioru Produktów wraz z zasadami przeprowadzenia testów określa Załącznik nr 4 do Umowy.
6. W przypadku akceptacji (odbioru jakościowego) Produktu z uwagami albo odrzucenia Produktu przez Zamawiającego, Wykonawca w terminie 10 Dni roboczych dostarczy poprawiony Produkt przy czym nie dotyczy to obsługi wad oprogramowania, które będą usuwane w terminach określonych w § 3.
7. Zamawiający oceniając, czy Produkt został dostarczony z zachowaniem terminu określonego w Umowie lub wynikającego z Wniosku Zmiany będzie brał pod uwagę datę nieodrzuconej dostawy Produktu. W przypadku gdy Produkt pierwotnie został zaakceptowany z uwagami, lecz jego ponowna dostawa została odrzucona, uznaje się, że także jego pierwotna dostawa została odrzucona i Produkt uznaje się za niedostarczony w terminie.
8. Strony dokonują odbioru usługi zewnętrznego wsparcia utrzymania Systemu po zakończeniu każdego Etapu na podstawie Raportu z Usługi Wsparcia, w stosunku do którego Kierownik Projektu Zamawiającego nie zgłosił uwag w trybie § 3 ust. 23 i po podpisaniu przez niego Raportu z Usługi Wsparcia - Załącznik nr 8 Umowy.
9. Obowiązki Wykonawcy wchodzące w zakres usługi zewnętrznego wsparcia utrzymania Systemu, określone w § 1 ust. 3 pkt 1-3, których termin realizacji wykracza poza ostatni dzień Etapu I, automatycznie przechodzą do Etapu II. Jednakże, jeżeli Wykonawca zrealizował wspomniane powyżej obowiązki jeszcze przed końcem ostatniego dnia danego Etapu, to powinny one zostać odebrane w ramach tego Etapu.
10. Odbiór Xxxxx XX musi obejmować wszystkie obowiązki wchodzące w zakres usługi zewnętrznego wsparcia utrzymania Systemu, określone w § 1 ust. 3 pkt 1-3, z tym, że dla obowiązków, których termin realizacji przypada na okres po zakończeniu tego Etapu, Wykonawca realizuje je w terminach określonych w § 3, jednak nie później niż 7 Dni roboczych po zakończeniu Etapu II.
11. Strony dokonują odbioru części przedmiotu Umowy, innego niż usługa zewnętrznego wsparcia utrzymania Systemu, na zakończenie każdego z dwóch Etapów, o których mowa w § 2 ust. 2.
12. Odbiór Etapu polega na końcowej weryfikacji przez Zamawiającego wykonania przez Wykonawcę wszystkich obowiązków wynikających z Umowy w Etapie, którego odbiór dotyczy. Odbiory Etapu są dokonywane na podstawie:
1) kompletu Protokołów Odbioru Produktów zmian określonych w § 1 ust. 1 pkt 3 zrealizowanych i odebranych w trakcie Etapu zrealizowanych w trybie określonym w § 4,
2) Protokołu Odbioru Produktu stanowiącego potwierdzenie zrealizowania przez Wykonawcę obowiązku opisanego w § 1 ust. 1 pkt 4 (przygotowaniu koncepcji wraz z pełną dokumentacją dotyczącą przygotowania systemu NCTS do pełnienia roli archiwum przez okres min. 5 lat - dot. tylko Etap I).
3) Protokołu Odbioru Produktu stanowiącego potwierdzenie zrealizowania przez Wykonawcę obowiązku opisanego w § 1 ust. 3 pkt 5 (aktualizacja dokumentacji).
4) Raportu z Usługi Wsparcia stanowiącego potwierdzenie zrealizowania przez Wykonawcę usługi zewnętrznego wsparcia utrzymania Systemu w danym Etapie.
13. Dokonanie odbioru, o którym mowa w ust. 11 zostaje potwierdzone Protokołem Odbioru Etapu podpisanym przez Kierownika Projektu Wykonawcy a po stronie Zamawiającego osoby wskazane w Załączniku nr 11. Wzór Protokołu Odbioru Etapu stanowi Załącznik nr 15 do Umowy. Protokół Odbioru Etapu sporządza i podpisuje jako pierwszy Kierownik Projektu Wykonawcy.
14. Strony ustalają, iż Protokół Odbioru Xxxxx XX będzie stanowił jednocześnie protokół odbioru końcowego dla Umowy. Protokół Odbioru Etapu II nie może zostać podpisany przed podpisaniem Raportu z Usługi Wsparcia dot. tego Etapu.
15. Po upływie gwarancji, o której mowa w § 11, w terminie 10 Dni roboczych zostanie przeprowadzony odbiór pogwarancyjny polegający na weryfikacji przez Strony wywiązania się Wykonawcy z zobowiązań gwarancyjnych. Odbiór ten zostanie udokumentowany w formie Protokołu Odbioru Pogwarancyjnego podpisywanego przez Naczelnika Wydziału Izby Celnej w Łodzi nadzorującego utrzymanie Systemu NCTS i Kierownika Projektu Wykonawcy. Wzór Protokołu Odbioru Pogwarancyjnego określony został w Załączniku nr 16 do Umowy.
16. Dane osób upoważnionych przez Zamawiającego do podpisywania Zgłoszenia i Wniosku Zmiany, dokumentów potwierdzających dokonanie odbioru usługi zewnętrznego wsparcia utrzymania Systemu, a także odbioru Produktów (ilościowego, jakościowego i końcowego) oraz odbioru Etapów i odbioru Pogwarancyjnego z uwzględnieniem sytuacji nieobecności osób, które zgodnie z postanowieniami § 3-5 powinny podpisać ww. dokumenty, zostały przedstawione w Załączniku nr 11 do Umowy.
17. Zamawiający może w każdej chwili zmienić osoby upoważnione do podpisywania dokumentów, po uprzednim pisemnym powiadomieniu Wykonawcy.
§ 6.
Zasady współdziałania pomiędzy Zamawiającym a Wykonawcą przy realizacji Przedmiotu Umowy
1. Do uzgodnień wynikających lub mogących wynikać w związku z wykonywaniem niniejszej Umowy oraz nadzoru nad jej realizacją, Zamawiający upoważnia …….., a w przypadku jego/jej nieobecności
…………………..
2. Zamawiający zobowiązuje się wykonywać obowiązki wynikające z niniejszej Umowy za pomocą osób wchodzących w skład Zespołu Realizacyjnego, wskazanych w Załączniku nr 11 do Umowy.
3. Do współpracy z Zamawiającym Wykonawca powoła, składający się z co najmniej 5 osób, Zespół Projektowy, w terminie 5 Dni roboczych od dnia zawarcia Umowy i wskaże pisemnie Zamawiającemu osoby odpowiedzialne za wykonanie zadań wraz z określeniem ich odpowiedzialności.
4. Wykonawca zobowiązuje się przy realizacji Przedmiotu Umowy do zatrudnienia w pełnym wymiarze czasu pracy 1 osobę bezrobotną, spełniającą przesłanki art. 2 ust. 1 pkt 2 ustawy z dnia 20 kwietnia 2004r. o promocji zatrudnienia i instytucjach rynku pracy (Dz. U. z 2015 r., poz. 149, z późn. zm.). Zatrudnienie będzie obejmować czas realizacji Umowy. W przypadku rozwiązania stosunku pracy przez osobę bezrobotną lub przez pracodawcę przed zakończeniem tego okresu Wykonawca będzie zobowiązany do zatrudnienia na to miejsce innej osoby bezrobotnej. Wykonawca przy wykonywaniu Przedmiotu Umowy, przedstawi Zamawiającemu dokumenty potwierdzające zatrudnienie osoby bezrobotnej. Zamawiający ma prawo w każdym okresie realizacji zamówienia zwrócić się do Wykonawcy o przedstawienie dokumentacji tj. zgłoszenia ofert pracy przedstawione urzędowi pracy, odpis skierowania bezrobotnych przez urząd pracy do pracodawcy oraz dokumenty potwierdzające zatrudnienie osoby bezrobotnej, natomiast Wykonawca ma obowiązek przedstawić je niezwłocznie Zamawiającemu. W przypadku niezatrudnienia przy realizacji Umowy wymaganej przez Zamawiającego osoby, Wykonawca będzie zobowiązany do zapłacenia Zamawiającemu kary umownej, określonej w § 12 ust. 14 Umowy.
5. Wykonawca zobowiązuje się wykonywać obowiązki wynikające z niniejszej Umowy za pomocą Zespołu Projektowego, w którego skład wchodzą osoby o kwalifikacjach i doświadczeniu opisanym w Załączniku nr 17 do Umowy. Także w tym załączniku Wykonawca wskaże dane osób upoważnionych do podpisywania dokumentów, o których mowa § 5 ust. 16.
6. Zamiana którejkolwiek z osób, o których mowa w ust. 5, na inną może nastąpić wyłącznie za zgodą Zamawiającego, przy czym nowa osoba musi posiadać kwalifikacje i doświadczenie, nie niższe niż kwalifikacje i doświadczenie osoby, którą zastępuje i zgodne z profilem funkcji, jaką będzie wypełniała.
Podobnie, rozszerzenie składu Zespołu Projektowego Wykonawcy o dodatkowe osoby może nastąpić wyłącznie za pisemną zgodą Zamawiającego.
7. Zmiana w składzie osobowym Zespołu Realizacyjnego Zamawiającego, jak i w składzie osobowym Zespołu Projektowego Wykonawcy nie wymaga formy Aneksu do Umowy.
8. Językiem stosowanym podczas realizacji Umowy jest język polski, przy czym:
1) dopuszcza się w komunikacji między Stronami stosowanie terminów w języku angielskim, jako uzupełniających;
2) Wykonawca zobowiązuje się sporządzać w języku polskim raporty, protokoły oraz wszelkie inne dokumenty wynikające z realizacji Umowy;
3) Zamawiający zastrzega sobie prawo do przedstawiania wymagań w innym języku obowiązującym w Unii Europejskiej;
4) w przypadku, gdy po stronie Wykonawcy w spotkaniach i uzgodnieniach z Zamawiającym występują osoby nieposługujące się biegle językiem polskim, Wykonawca zobowiązany jest w ramach otrzymywanego wynagrodzenia zapewnić komunikację pomiędzy Stronami w języku polskim (tłumaczenie symultaniczne).
9. W przypadku wystąpienia opóźnień w realizacji Umowy, z przyczyn leżących po stronie Wykonawcy, Wykonawca zobowiązuje się świadczyć usługę zewnętrznego wsparcia utrzymania Systemu, na zasadach określonych § 3, także po dniu, w którym upływa 7 miesięczny okres realizacji tej usługi przez okres odpowiadający długości opóźnienia powstałego z przyczyn leżących po stronie Wykonawcy.
10. Przedmiot Umowy uważa się za zrealizowany z chwilą dokonania przez Zamawiającego odbioru końcowego Umowy, o którym mowa w § 5 ust. 14.
11. Wykonawca zobowiązuje się wysyłać wszelką korespondencję, w tym sprawozdania i komunikaty związane z bieżącą realizacją prac, do Kierownika Projektu Zamawiającego, o ile Umowa nie stanowi inaczej.
12. Aktualne dane do korespondencji Kierownika Projektu Zamawiającego oraz innych osób upoważnionych przez Zamawiającego do podpisywania w jego imieniu dokumentów potwierdzających dokonanie odbiorów produktów (ilościowego, jakościowego i końcowego), Zgłoszeń Zmiany i Wniosków Zmiany oraz odbioru etapu i odbioru pogwarancyjnego, Zamawiający przekaże w formie pisemnej Wykonawcy w ciągu 5 Dni roboczych od dnia zawarcia Umowy. Zamawiający zobowiązuje się do niezwłocznego poinformowania Wykonawcy o każdej zmianie tych danych w trakcie realizacji Umowy.
13. Faktury dotyczące płatności Wykonawca będzie wysyłał na adres:
Izba Celna w Łodzi, ul. Xxxxxx 00
93-232 Łódź
14. Strony zobowiązują się do kierowania wszelkiej korespondencji wymagającej formy pisemnej na adresy stron:
a) Zamawiającego:
Izba Celna w Łodzi, ul. Xxxxxx 00
93-232 Łódź
b) Wykonawcy:
…………………………………..
a w przypadku zmiany ww. adresu, do niezwłocznego, pisemnego powiadomienia o tym fakcie drugiej Strony.
15. W przypadku braku powiadomienia, o którym mowa w ust. 14, wysłanie korespondencji na adres, o którym mowa w ust. 14, wywiera przewidziane prawem skutki prawne, w tym również skutek doręczenia.
16. Wykonawca zobowiązuje się poinformować Zamawiającego o zamiarze powierzenia realizacji części przedmiotu Umowy innym podwykonawcom ze wskazaniem zakresu prac.
§ 7.
OŚWIADCZENIA STRON
1. Zamawiający upoważnia Wykonawcę do wykonywania niezbędnych czynności związanych z realizacją przedmiotu Umowy.
2. Zamawiający zobowiązuje się do udostępnienia Wykonawcy w terminie do 3 Dni roboczych od daty zawarcia Umowy, materiałów i informacji niezbędnych do realizacji przedmiotu Umowy, które znajdują się w posiadaniu Zamawiającego, z zastrzeżeniem ustawy z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz. U. z 2010 r., Nr 182, poz. 1228 z późn. zm.) oraz ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j.: Dz. U. z 2015 r. poz. 2135).
3. Wykonawca zobowiązuje się do wykorzystania dokumentów, materiałów i informacji przekazanych przez Zamawiającego tylko i wyłącznie na potrzeby realizacji niniejszej Umowy.
4. Wykonawca zobowiązuje się, że w terminie 10 Dni roboczych od dnia zakończenia realizacji, rozwiązania, wygaśnięcia lub odstąpienia od Umowy, dokona wraz z podwykonawcami oraz osobami trzecimi uczestniczącymi w wykonaniu zamówienia trwałego usunięcia ze wszystkich posiadanych nośników: aplikacji, danych oraz udostępnionej przez Zamawiającego dokumentacji.
5. Wykonawca oświadcza, że:
1) wytwarzanie produktów w ramach niniejszej Umowy, w tym oprogramowania i dokumentacji,
2) korzystanie przez Xxxxxxxxxxxxx z produktów niniejszej Umowy oraz z praw autorskich, licencji, praw własności przemysłowej, intelektualnej, praw własności wzorów przemysłowych, itp. nabytych w związku z niniejszą Umową,
nie narusza przepisów prawa, prawem chronionych dóbr osobistych lub majątkowych osób trzecich, ani też praw na dobrach niematerialnych, w szczególności praw autorskich, praw pokrewnych, praw z rejestracji wzorów przemysłowych oraz praw ochronnych na znaki towarowe.
6. Wykonawca oświadcza, że wykonanie niniejszej Umowy nie będzie prowadzić do wypełnienia przesłanek czynu nieuczciwej konkurencji, w szczególności nie stanowi naruszenia tajemnicy przedsiębiorstwa osoby trzeciej.
7. Wykonawca oświadcza, że wszelkie dane i informacje uzyskane przez Zamawiającego w wyniku wykonania Umowy, nie są objęte tajemnicą przedsiębiorstwa Wykonawcy i jego kontrahentów.
8. W razie powstania w trakcie wykonywania Umowy lub po wykonaniu Umowy wszelkich roszczeń osób trzecich, Wykonawca oświadcza, że bierze na siebie wszelką odpowiedzialność za roszczenia osób trzecich z tytułu szkód materialnych lub na osobie, a wynikłych z wykonania Umowy przez Wykonawcę, jego Podwykonawców i ich pracowników.
9. Wykonawca zobowiązuje się nie ograniczać Zamawiającego w zgodnym z prawem korzystaniu z produktów powstałych w wyniku realizacji niniejszej Umowy.
10. Wykonawca zobowiązuje się do:
1) realizacji przedmiotu Umowy w zakresie i terminach w niej określonych, zgodnie z najlepszą wiedzą merytoryczną, najwyższą starannością, efektywnością, zgodnie z najlepszą praktyką oraz odpowiednimi przepisami. Ponadto zobowiązuje się do kontroli przestrzegania zobowiązania do poufności przez wszystkie osoby zaangażowane w realizację Przedmiotu Umowy;
2) bieżącego konsultowania z Zamawiającym zagadnień dotyczących realizacji Przedmiotu Umowy,
3) nie podejmowania jakichkolwiek działań, które mogłyby stać w sprzeczności z działaniami wykonywanymi na rzecz Zamawiającego na podstawie Umowy, a w szczególności prowadzić do powstania konfliktu interesów,
4) informowania Zamawiającego o wszystkich zdarzeniach mających lub mogących mieć wpływ na realizację Przedmiotu Umowy (w zakresie merytorycznym, jak i terminowym), w tym o wszczęciu wobec niego postępowania likwidacyjnego, upadłościowego lub naprawczego lub innego, lub o zaistnieniu innych istotnych zdarzeń.
11. Usługi objęte przedmiotem niniejszej Umowy, wymagające przetwarzania danych osobowych, świadczone będą przez Wykonawcę zgodnie z przepisami ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j.: Dz. U. z 2015r. poz. 2135).
12. Zamawiający, dla celów wykonania Umowy przez Wykonawcę, powierza niniejszym przetwarzanie danych osobowych, w stosunku do których jest administratorem, w celu wykonania zobowiązań wynikających z niniejszej Umowy, w zakresie danych osobowych przetwarzanych w ramach Systemu.
13. Wykonawca zobowiązuje się w szczególności:
1) zastosować środki techniczne i organizacyjne zapewniające ochronę przetwarzanych danych osobowych, w szczególności wynikające z przepisów rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. z 2004 r. nr 100, poz. 1024);
2) zabezpieczyć dane osobowe przed ich udostępnieniem osobom nieupoważnionym, zabraniem przez osobę nieuprawnioną, uszkodzeniem lub zniszczeniem;
3) dopuszczać do przetwarzania danych, w szczególności do obsługi systemu informatycznego przetwarzającego dane osobowe oraz do urządzeń wchodzących w jego skład, wyłącznie osoby przeszkolone z zakresu przepisów o ochronie danych osobowych, posiadające stosowne upoważnienie do przetwarzania danych osobowych;
4) zapewnić, aby osoby mające dostęp do przetwarzania danych osobowych zachowały te dane oraz sposoby ich zabezpieczenia w tajemnicy, przy czym obowiązek zachowania tajemnicy obowiązuje również po zakończeniu realizacji niniejszej Umowy oraz ustaniu zatrudnienia danej osoby przez Wykonawcę.
15. W celu uregulowania zasad realizacji Umowy w obszarze związanym z przetwarzaniem danych osobowych, Wykonawca zobowiązuje się do zawarcia w terminie 3 Dni roboczych od daty przekazania, Umowy powierzenia przetwarzania danych osobowych, której treść Zamawiający przekaże w terminie 1 miesiąca od dnia zawarcia Umowy.
§ 8.
WARTOŚĆ UMOWY I WARUNKI PŁATNOŚCI
1. Za prawidłowe wykonanie Przedmiotu Umowy Wykonawca otrzyma, zgodnie ze złożoną ofertą, łączne wynagrodzenie w wysokości maksymalnie …………. brutto (słownie: ……………. zł), obejmujące wszelkie obciążenia związane z realizacją Umowy oraz wynikające z przepisów prawa, w tym wynagrodzenie wynikające z przeniesienia praw autorskich w pełnym zakresie do produktów powstałych w trakcie realizacji Umowy na określonych w niniejszej Umowie polach eksploatacji, jak również wszystkie koszty, opłaty, wydatki Wykonawcy w tym koszty związane z prawami zależnymi, a także podatki, w tym podatek od towarów i usług (VAT), jeśli jest należny. Wynagrodzenie Wykonawcy obejmuje następujące elementy:
1) wynagrodzenie za realizację obowiązków Wykonawcy określonych w § 1 ust. 1 pkt 1 oraz 4, w stosunku do produktów powstałych na skutek wykonywania przez Wykonawcę tych obowiązków, obejmujące także wynagrodzenie za przeniesienie autorskich praw majątkowych wynosi …………..
(słownie zł);
2) ryczałtowe wynagrodzenie eksploatacyjne w wysokości …….. (słownie:………….) stanowiące wynagrodzenie za świadczenie usług zewnętrznego wsparcia utrzymania Systemu, o której mowa w
§ 1 ust. 1 pkt 2 za poszczególne Etapy będzie płacone przez Xxxxxxxxxxxxx w następujący sposób:
a) w odniesieniu do Etapu I, w kwocie …… (słownie:..……..) którą Zamawiający zapłaci po dokonaniu odbioru Etapu I, o którym mowa w § 5 ust. 12,
b) w odniesieniu do Etapu II w kwocie ………. (słownie:………), którą Zamawiający zapłaci po dokonaniu odbioru, o którym mowa w § 5 ust. 12
3) wynagrodzenie za realizację obowiązków Wykonawcy w ramach zadania Wprowadzania Zmian, o którym mowa w § 1 ust. 1 pkt 3, w stosunku do produktów powstałych na skutek wykonywania przez Wykonawcę tych obowiązków, obejmujące także wynagrodzenie za przeniesienie autorskich praw majątkowych maksymalnie wynosi …………… (słownie: zł), przy czym:
a) Zamawiający nie jest zobowiązany do wykorzystania ww. kwoty, a płatności będą dokonywane wyłącznie za faktycznie wykonane czynności zgodnie z Wnioskami Zmian,
b) wartość jednego osobodnia wykonywania obowiązków, o których mowa w § 4 ust. 1 wynosi
………… (słownie zł) i zawiera wszelkie koszty, w tym wymienione powyżej w
niniejszym ustępie,
c) dla każdego Wniosku Zmiany wynagrodzenie jest wyliczane poprzez pomnożenie wymiaru pracochłonności określonego w tym wniosku (przy czym liczba osobodni jest wyrażona liczbą rzeczywistą) przez wartość jednego osobodnia określoną w lit. b,
d) będzie płacone po zakończeniu Etapu tj. po dokonaniu odbioru, o którym mowa w § 5 ust. 12, za wszystkie produkty, o których mowa w § 5 ust. 1 pkt 2 w stosunku do których został dokonany odbiór końcowy, w tym Etapie,
2. Ryczałtowe wynagrodzenie eksploatacyjne, o którym mowa w ust. 1 pkt 2 będzie płacone przez Xxxxxxxxxxxxx, z ewentualnym uwzględnieniem potrąceń określonych poniżej w ust. 6.
3. Podstawą do wystawienia faktury VAT przez Wykonawcę będzie Protokół Odbioru Etapu, podpisany przez Strony na zakończenie Etapów I i II.
4. Wynagrodzenie, o którym mowa w ust. 1, będzie płacone przez Zamawiającego po spełnieniu następujących warunków:
1) dokonania odbioru, o którym mowa w § 5 ust. 12 – w odniesieniu do każdego z Etapów,
2) dostarczenia do siedziby Zamawiającego prawidłowo wystawionej faktury dotyczącej tego Etapu, której podstawą wystawienia był odbiór określony w pkt 1.
5. Wynagrodzenie, o którym mowa w ust. 1, będzie płacone przez Zamawiającego przelewami bankowymi na konto Wykonawcy wskazane w fakturze, w terminie 30 dni od daty dostarczenia do siedziby Zamawiającego prawidłowo wystawionej faktury.
6. Strony ustalają, iż łączne wynagrodzenie za wykonanie Przedmiotu Umowy oraz ryczałtowe
wynagrodzenie eksploatacyjne będą pomniejszane o
1 kwoty za każdy rozpoczęty dzień
92
niewykonywania obowiązków, o których mowa w § 3 ust. 1, wchodzących w zakres usługi zewnętrznego wsparcia utrzymania Systemu.
7. Pomniejszenie wysokości ryczałtowego wynagrodzenia eksploatacyjnego za dany Etap pozostaje bez wpływu na realizowanie przez Zamawiającego postanowień § 12 ust. 4 w zakresie naliczania kar umownych z tytułu niedotrzymania przez Wykonawcę terminu usunięcia Błędów o Priorytecie 1.
8. Za datę dokonania płatności Strony uznają datę obciążenia rachunku Zamawiającego.
9. W przypadku, gdy nastąpi zwiększenie bądź zmniejszenie stawki podatku od towarów i usług na podstawie odrębnych przepisów, które wejdą w życie po dniu zawarcia Umowy, a przed wykonaniem przez Wykonawcę obowiązku, po wykonaniu którego Wykonawca jest uprawniony do uzyskania wynagrodzenia, wynagrodzenie Wykonawcy ulega odpowiedniemu zwiększeniu bądź zmniejszeniu, jeżeli w wyniku zastosowania zmienionych stawek podatków, ulega zmianie kwota należnego podatku oraz wynagrodzenie Wykonawcy uwzględniające podatek od towarów i usług. Taka waloryzacja wynagrodzenia nie powoduje konieczności zawarcia aneksu do Umowy. Waloryzacja, o której mowa powyżej, dotyczy tej części Umowy, za wykonanie której faktury będą wystawiane po dacie wejścia w życie zmiany podatku od towarów i usług.
10. Wykonawcy nie przysługuje odrębne żądanie zwrotu poniesionych wydatków nieobjętych Umową.
§ 9.
PRZENIESIENIE AUTORSKICH PRAW MAJĄTKOWYCH
1. W ramach wynagrodzenia, o którym mowa w § 8 ust. 1 Umowy, Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do każdego z produktów oraz ich zmian wytworzonych w wyniku realizacji Umowy, a w szczególności do oprogramowania, w tym kodów źródłowych, dokumentacji i wszystkich innych dokumentów będących wynikiem realizacji niniejszej Umowy.
2. Autorskie prawa majątkowe do każdego z produktów oraz ich zmian powstałych w wyniku realizacji Umowy przechodzą na Zamawiającego z chwilą podpisania Protokołu Odbioru Produktu – dotyczy to także sytuacji, o której mowa w § 13 ust. 8, gdyż wypowiedzenie lub odstąpienie od Umowy nie zwalnia Stron z obowiązku podpisania Protokołu Odbioru Produktu w odniesieniu do produktów zaakceptowanych lub zaakceptowanych z uwagami.
3. Przeniesienie autorskich praw majątkowych na Zamawiającego, obejmuje wszelkie pola eksploatacji wskazane w art. 50 i 74 ust. 4 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2006 r. Nr 90, poz. 631, z późn. zm.), w tym następujące pola eksploatacji:
1) w odniesieniu do wszelkiej dokumentacji: wykorzystanie do realizacji zadań publicznych bez jakichkolwiek ograniczeń, odtwarzanie, utrwalanie i trwałe zwielokrotnianie całości lub części wszystkimi znanymi w chwili przenoszenia autorskich praw majątkowych technikami, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką cyfrową, przekazywanie, przechowywanie, wyświetlanie, wprowadzanie do pamięci komputera wraz z prawem do wykonywania modyfikacji, tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne zmiany, wprowadzanie do obrotu, użyczanie lub najem oryginału albo egzemplarzy, na których utwór utrwalono, rozpowszechnianie utworu przez publiczne wykonanie, wystawienie, wyświetlenie, odtworzenie oraz nadawanie i reemitowanie, publiczne udostępnienie utworu w taki sposób, aby każdy mógł mieć do niego dostęp w miejscu i czasie przez siebie wybranym, a także prawo wykonywania zależnego prawa autorskiego oraz prawo do udzielania zezwoleń na wykonywanie zależnego prawa autorskiego do ww. produktów i ich zmian na wszystkich ww. polach eksploatacji.
2) w odniesieniu do oprogramowania Systemu (w tym zmian lub rozbudowy): wykorzystanie do realizacji zadań publicznych bez jakichkolwiek ograniczeń; wprowadzanie i zapisywanie w pamięci komputerów; odtwarzanie; utrwalanie; przekazywanie; przechowywanie; wyświetlanie; stosowanie; instalowanie i deinstalowanie oprogramowania; sporządzanie kopii zapasowej (kopii bezpieczeństwa); trwałe lub czasowe zwielokrotnienie w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie, tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne zmiany, z zachowaniem praw osoby, która tych zmian dokonała, rozpowszechnianie, w tym użyczanie lub najem oraz publiczne udostępnienie w taki sposób, aby każdy mógł mieć do niego dostęp w miejscu i czasie przez siebie wybranym;
3) w odniesieniu do kodów źródłowych oprogramowania Systemu, w tym dostosowań COTS zrealizowanych przez Wykonawcę (rozumianych jako zbiory wartości parametrów i/lub kodu w języku oprogramowania przewidzianym przez xxxx XXXX jako rozwiązanie do jego dostosowania dla konkretnego klienta): na wszystkich polach eksploatacji określonych powyżej dla dokumentacji i oprogramowania Systemu oraz na następujących polach eksploatacji: modyfikacji kodów źródłowych, ich kompilacji, testowania, wdrożenia, używania wytworzonego w ten sposób wykonywalnego oprogramowania i przeprowadzania szkoleń w tym zakresie, wraz z prawem wykonywania zależnego prawa autorskiego oraz prawem do udzielania zezwoleń na wykonywanie zależnego prawa autorskiego do ww. produktów i ich zmian na wszystkich ww. polach eksploatacji.
4. Zamawiający może wykonywać majątkowe prawa autorskie bez jakichkolwiek ograniczeń nie zastrzeżonych wyraźnie w Umowie (w szczególności ograniczeń terytorialnych), samodzielnie lub może upoważnić do tego osoby trzecie.
5. W ramach wynagrodzenia określonego w § 8 ust. 1 Umowy, Wykonawca przenosi na Zamawiającego prawo do wykonywania zależnego prawa autorskiego.
6. Z chwilą przejścia majątkowych praw autorskich, własność nośników, na których utrwalono produkty i ich modyfikacje, przechodzi na Zamawiającego.
7. Zamawiający nie ponosi i nie będzie ponosić odpowiedzialności za naruszenie praw osób trzecich w związku z pracami wykonywanymi przez Wykonawcę. Cała odpowiedzialność w powyższym zakresie spoczywa na Wykonawcy.
8. Jeśli wykonane w ramach Umowy produkty faktycznie naruszać będą prawa osób trzecich, Wykonawca niezwłocznie przystąpi do ich zmodyfikowania w sposób, pozwalający na dalsze ich wykorzystywanie bez naruszania praw osób trzecich lub uzyska dla Zamawiającego, na swój koszt, licencję na część dotkniętą naruszeniem.
9. W przypadku wytoczenia powództwa przez osobę trzecią przeciwko Zamawiającemu, Wykonawca na wezwanie Xxxxxxxxxxxxx przystąpi do postępowania po jego stronie.
10. Wykonawca oświadcza, że w Systemie nie będą użyte żadne elementy, moduły, podsystemy, aplikacje, komponenty wobec których Wykonawca zachowuje odrębne wyłączne autorskie prawa majątkowe.
§ 10.
ZABEZPIECZENIE NALEŻYTEGO WYKONANIA UMOWY
1. Wykonawca oświadcza, iż przed zawarciem niniejszej Umowy wniósł skutecznie na rzecz Zamawiającego zabezpieczenie należytego wykonania Umowy, zwane dalej w Umowie zabezpieczeniem, w wysokości …% wynagrodzenia umownego, określonego w § 8 ust. 1 czyli kwotę: …………… (słownie: …………..zł) zdeponowane/wpłacone w formie ……...
2. Zabezpieczenie służy do pokrycia roszczeń Zamawiającego z tytułu niewykonania lub nienależytego wykonania Umowy.
3. Zamawiający zwolni zabezpieczenie:
1) w wysokości 70% kwoty zabezpieczenia - zostanie zwrócone przez Zamawiającego w terminie 30 dni od daty dokonania odbioru końcowego dla Umowy, o którym mowa w § 5 ust. 14 potwierdzającego wykonanie przez Wykonawcę całości przedmiotu Umowy;
2) wysokości 30% kwoty zabezpieczenia - zostanie zwrócone przez Zamawiającego w terminie 15 dni od upływu okresu rękojmi za wady, o ile nie zostanie zaliczone na poczet prawnie uzasadnionych roszczeń Zamawiającego.
4. Jeżeli z uwagi na przedłużenie terminu realizacji Umowy, niezależnie od przyczyn tego przedłużenia, zabezpieczenie wniesione w gwarancjach bankowych, ubezpieczeniowych lub w poręczeniach wygasłoby przed upływem przedłużonego terminu realizacji Umowy, Wykonawca na 7 Dni roboczych przed wygaśnięciem takiego zabezpieczenia przedstawia Zamawiającemu stosowny aneks lub nową gwarancję/poręczenie lub wpłaca odpowiednie zabezpieczenie w gotówce. Jeżeli Wykonawca nie wykona powyższego obowiązku Zamawiający może zażądać od gwaranta/poręczyciela wypłaty z gwarancji/poręczenia i zaliczyć uzyskaną w ten sposób kwotę na poczet zabezpieczenia.
5. Wykonawca oświadcza, że wyraża zgodę na bezpośrednie potrącenie przez Zamawiającego z zabezpieczenia należytego wykonania Umowy i rękojmi wszelkich należności powstałych w wyniku niewykonania lub nienależytego wykonania Umowy, a w szczególności kar umownych.
§ 11.
WARUNKI GWARANCJI JAKOŚCI I RĘKOJMI
1. Wykonawca udziela Zamawiającemu gwarancji na System, w ramach której zapewnia Zamawiającemu poprawną, tj. wolną od fizycznych i prawnych wad, pracę Systemu przez okres ……. miesięcy poczynając od dnia następnego po dniu podpisania Protokołu Odbioru Xxxxx XX.
2. W okresie gwarancji, o którym mowa w ust. 1, Wykonawca zobowiązuje się usuwać Błędy Systemu na zasadach określonych w § 3 ust. 1-8. W przypadku naruszenia zasad określonych odpowiednio w § 3 ust. 1-8, a w szczególności terminów, stosuje się postanowienia § 12 Umowy.
3. Dla Błędów, których termin usunięcia przypada na okres po zakończeniu okresu gwarancji, Wykonawca usuwa Błędy w terminach określonych w § 3 ust. 4, jednak nie później niż 10 Dni roboczych po zakończeniu okresu gwarancji.
4. Wykonawca zobowiązuje się wykonywać obowiązki w zakresie prowadzenia Rejestru Zgłoszeń Gwarancyjnych, o którym mowa w § 1 ust. 3 pkt 4 lit. d, w okresie, o którym mowa w ust. 3.
5. Strony ustalają, iż termin gwarancji ulega przedłużeniu o czas, w trakcie którego Zamawiający nie mógł w pełni korzystać z Systemu, z powodu wystąpienia Błędów o Priorytecie 1, oraz biegnie na nowo, w stosunku do produktów powstałych w wyniku wykonywania obowiązków gwarancyjnych.
6. W przypadku niewykonywania lub nienależytego wykonywania przez Wykonawcę obowiązków gwarancyjnych wynikających z niniejszej Umowy, pomimo pisemnego wezwania do ich wykonania lub zmiany sposobu ich wykonywania w wyznaczonym terminie, Zamawiający uprawniony jest do zlecenia wykonania obowiązków gwarancyjnych innemu podmiotowi na koszt Wykonawcy, bez utraty gwarancji.
7. Uprawnienia z tytułu rękojmi na poprawną, tj. wolną od fizycznych i prawnych wad, pracę wszystkich produktów w postaci oprogramowania, dostarczonych i wdrożonych przez Wykonawcę w ramach Umowy, w tym również na nośniki oprogramowania przysługują Zamawiającemu przez okres 2 lat od momentu podpisania Protokołu Odbioru Produktu dotyczącego oprogramowania. Powyższe zasady stosuje się odpowiednio do sytuacji, o której mowa w § 13 ust. 8, gdyż wypowiedzenie lub odstąpienie od Umowy nie zwalnia Stron z obowiązku podpisania Protokołu Odbioru Produktu w odniesieniu do produktów zaakceptowanych lub zaakceptowanych z uwagami.
8. Zamawiający jest uprawniony do wykonywania uprawnień z tytułu rękojmi za wady fizyczne i prawne przedmiotu Umowy, niezależnie od uprawnień wynikających z gwarancji i odwrotnie.
9. W przypadku wystąpienia wady nośnika z oprogramowaniem w okresie, o którym mowa w ust. 7, Wykonawca zobowiązuje się dostarczyć nowy, wolny od wad nośnik wraz z oprogramowaniem, w terminie 7 dni od dnia zgłoszenia wady.
§ 12.
KARY UMOWNE
1. W przypadku wypowiedzenia/rozwiązania/odstąpienia od Umowy przez Zamawiającego z przyczyn leżących po stronie Wykonawcy, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 20% wartości wynagrodzenia brutto, o którym mowa w § 8 ust. 1 Umowy, przy czym w przypadku gdy dotyczy to części Umowy, podstawą naliczenia kary umownej jest odpowiednia wartość wynagrodzenia za tą część Umowy.
2. W przypadku wypowiedzenia/rozwiązania/odstąpienia od Umowy przez Wykonawcę z przyczyn leżących po jego stronie, Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 20% wartości wynagrodzenia brutto, o którym mowa w § 8 ust. 1 Umowy, przy czym w przypadku gdy dotyczy to części Umowy, podstawą naliczenia kary umownej jest odpowiednia wartość wynagrodzenia za tą część Umowy.
3. Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 5.000 zł. brutto w przypadku stwierdzenia przez Zamawiającego niewykonywania lub nieprawidłowego wykonywania przez Wykonawcę obowiązku określonego w:
1) § 6 ust. 8 pkt 2, za każdy dokument, który został dostarczony z naruszeniem obowiązku;
2) § 6 ust. 8 pkt 4, za każde naruszenie obowiązku;
3) § 7 ust. 4, za każdy nośnik, w odniesieniu, do którego stwierdzono naruszenie obowiązku.
4. W przypadku niedotrzymania któregokolwiek z terminów, o których mowa w § 3 ust. 4 pkt 1 Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,1% wartości wynagrodzenia brutto Umowy za każdą rozpoczętą godzinę opóźnienia, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
5. W przypadku niedotrzymania któregokolwiek z terminów, o których mowa w § 3 ust. 4 pkt. 2 Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,05% wartości wynagrodzenia brutto Umowy za każdą rozpoczętą godzinę opóźnienia, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
6. W przypadku niedotrzymania któregokolwiek z terminów, o których mowa w § 3 ust. 4 pkt 3, § 3 ust. 17 Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,025% wartości wynagrodzenia brutto Umowy za każdą rozpoczętą godzinę opóźnienia, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
7. W przypadku niedotrzymania któregokolwiek z terminów, o których mowa w § 3 ust. 3, ust. 10 Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,01% wartości wynagrodzenia brutto Umowy za każdą rozpoczętą godzinę opóźnienia, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
8. W przypadku niezrealizowania obowiązku dostawy zaktualizowanej dokumentacji na koniec każdego z Etapów (§ 1 ust. 1 pkt 1) Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,01% wartości wynagrodzenia brutto Umowy za każdy rozpoczęty dzień opóźnienia liczonego od daty wskazanej w § 1 ust. 3 pkt 5, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
9. W przypadku niedotrzymania, z przyczyn zawinionych przez Wykonawcę, któregokolwiek z terminów określonych w § 3 ust. 11, ust. 15, § 5 ust. 6, § 11 ust. 2 i 3, oraz wszystkich określonych w Załączniku nr 4 do Umowy terminów związanych z procedurą odbioru produktów, Wykonawca zobowiązuje się zapłacić Zamawiającemu karę umowną w wysokości 0,05% wartości Umowy brutto za każdy rozpoczęty dzień roboczy od upływu każdego niedotrzymanego terminu.
10. W przypadku niedotrzymania, z przyczyn zawinionych przez Wykonawcę, któregokolwiek z terminów określonych w § 3 ust. 4 pkt 4, § 11 ust. 9 Wykonawca zobowiązuje się zapłacić Zamawiającemu karę umowną w wysokości 0,025% wartości Umowy brutto za każdy rozpoczęty dzień kalendarzowy od upływu każdego niedotrzymanego terminu.
11. W przypadku niedotrzymania, z przyczyn zawinionych przez Wykonawcę, któregokolwiek z terminów określonych w § 3 ust. 23 i ust. 27 Wykonawca zobowiązuje się zapłacić Zamawiającemu karę umowną w wysokości 0,075% wartości Umowy brutto za każdy rozpoczęty dzień roboczy od upływu każdego niedotrzymanego terminu.
12. W przypadku stwierdzenia przez Zamawiającego niewykonywania lub nieprawidłowego wykonywania przez Wykonawcę obowiązku określonego w § 11 ust. 4 rozszerzającego ten obowiązek także na okres obowiązywania gwarancji, Wykonawca zobowiązuje się zapłacić Zamawiającemu karę umowną w wysokości 0,05% wartości Umowy brutto za każdy rozpoczęty dzień każdego z niewykonywanych obowiązków lub wykonywanych w sposób nieprawidłowy.
13. W przypadku niedotrzymania terminu określonego § 14 ust. 12, a także terminu realizacji każdego z produktów i usług wymienionych w Załączniku nr 5 do Umowy, a także terminu realizacji Wniosku Zmiany (określonego we Wniosku Zmiany), Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 0,05% wartości brutto Umowy za każdy rozpoczęty dzień opóźnienia, chyba że przyczyna opóźnienia leży po stronie Zamawiającego.
14. W przypadku niezatrudnienia przy realizacji zamówienia przez Wykonawcę 1 osoby bezrobotnej (§ 6 ust. 4 Umowy), Wykonawca będzie zobowiązany do zapłacenia kary umownej w wysokości 2500,00 zł brutto, chyba że wykaże, że przedstawił zgłoszenie ofert pracy urzędowi pracy, a niezatrudnienie osoby bezrobotnej nastąpiło z przyczyn nieleżących po jego stronie. Za przyczynę nieleżącą po stronie Wykonawcy będzie uznawany brak osób bezrobotnych zdolnych do wykonywania zamówienia lub odmowa podjęcia pracy przez taką osobę bezrobotną.
15. Kary umowne przewidziane w niniejszym paragrafie obowiązują niezależnie od siebie, z tym zastrzeżeniem, że w przypadku odstąpienia od Umowy, możliwe jest naliczenie wyłącznie kary przewidzianej na wypadek odstąpienia od Umowy.
16. Obowiązek zapłaty przez Wykonawcę kar umownych z tytułu niewykonania lub nienależytego wykonania Umowy, nie wyłącza prawa Zamawiającego do dochodzenia odszkodowania przewyższającego ustalone powyżej kary umowne na zasadach ogólnych.
17. Kary umowne będą w pierwszej kolejności potrącane z wynagrodzenia należnego Wykonawcy, na co Wykonawca wyraża zgodę i do czego upoważnia Zamawiającego bez potrzeby uzyskiwania pisemnego potwierdzenia.
§ 13.
ODSTĄPIENIE OD UMOWY
1. Zamawiający może rozwiązać za wypowiedzeniem lub odstąpić od części lub całości Umowy w przypadkach określonych w przepisach obowiązującego prawa, w szczególności Kodeksu cywilnego oraz w przypadkach określonych w Umowie.
2. Zamawiający może odstąpić od części lub całości Umowy z przyczyn leżących po stronie Wykonawcy, gdy:
1) w realizacji jakiegokolwiek obowiązku określonego w Umowie, powstaną opóźnienia przekraczające 1 miesiąc,
2) Wykonawca nienależycie wykonuje Umowę, i po upływie 7 dni od pisemnego wezwania przez Zamawiającego do należytego wykonania Umowy oraz usunięcia skutków naruszeń, Wykonawca nie zastosuje się do wezwania.
3. Zamawiający może odstąpić od Umowy w razie zaistnienia istotnej zmiany okoliczności powodującej, że wykonanie Umowy nie leży w interesie publicznym, czego nie można było przewidzieć w chwili zawarcia Umowy. W tym przypadku Wykonawca może żądać wyłącznie wynagrodzenia należnego z tytułu należytego wykonania części Umowy.
4. Prawo odstąpienia Zamawiający może wykonać w terminie 30 dni od powzięcia wiadomości o okolicznościach, o których mowa powyżej w niniejszym paragrafie.
5. Odstąpienie od Umowy następuje w formie pisemnej pod rygorem nieważności i wymaga uzasadnienia.
6. Prawo do wypowiedzenia Umowy przez Wykonawcę ograniczone jest do zdarzeń określonych w § 8, gdy Zamawiający nie płaci Wykonawcy wynagrodzenia w terminie 30 dni, a opóźnienie w wypłacie wynagrodzenia przekracza 30 dni.
7. W przypadku wypowiedzenia lub odstąpienia od Umowy, w trybie określonym w niniejszym paragrafie Wykonawcy należy się wynagrodzenie proporcjonalne do zakresu wykonania Przedmiotu Umowy, o ile wykonany zakres przedmiotu Umowy będzie miał dla Zamawiającego znaczenie. Oprócz Produktów już odebranych końcowo Zamawiający za zrealizowany Przedmiot Umowy może uznać także te Produkty dostarczone przed datą rozwiązania Umowy, które w ramach odbioru jakościowego zostaną/zostały zaakceptowane albo zaakceptowane z uwagami.
8. W przypadku rozwiązania za wypowiedzeniem lub odstąpienia od Umowy przez Zamawiającego, w sytuacjach, o których mowa w niniejszym paragrafie:
1) Strony zobowiązują się w terminie 7 dni od dnia wypowiedzenia lub odstąpienia od Umowy do sporządzenia Protokołu Odbioru Etapu który będzie stwierdzać stan realizacji przedmiotu Umowy do dnia rozwiązania lub odstąpienia od Umowy oraz wysokość wynagrodzenia należnego Wykonawcy;
2) Strony dokonują rozliczenia w oparciu o odpowiednie stosowanie postanowień Umowy, w szczególności w zakresie procedur odbioru, podstaw wystawiania faktur, terminów płatności.
§ 14.
ZACHOWANIE POUFNOŚCI
1. Wykonawca zobowiązuje się do zachowania w poufności wszelkich informacji i danych otrzymanych i uzyskanych od Zamawiającego w związku z wykonaniem zobowiązań wynikających z Umowy, niezależnie od formy pozyskania tych informacji i ich źródła (dalej „informacje”). W szczególności dotyczy to wszelkich informacji technicznych, technologicznych, prawnych i organizacyjnych dotyczących systemów i sieci informatycznych / teleinformatycznych, w szczególności ich zabezpieczenia.
2. Wykonawca zobowiązuje się do wykorzystania informacji jedynie w celach określonych ustaleniami Umowy oraz wynikających z bezwzględnie obowiązujących uregulowań prawnych.
3. Wykonawca zobowiązuje się do ujawnienia informacji jedynie tym osobom, którym będą one niezbędne do wykonywania powierzonych im czynności służbowych i tylko w zakresie, w jakim odbiorca informacji musi mieć do nich dostęp dla celów realizacji zadania wynikającego z tytułu realizacji Umowy.
4. Wykonawca zobowiązuje się do nie kopiowania, nie powielania, ani w jakikolwiek inny sposób nie rozpowszechniania jakiejkolwiek części określonych informacji z wyjątkiem uzasadnionej potrzeby do celów związanych z realizacją Umowy, po uprzednim uzyskaniu pisemnej zgody od Zamawiającego, którego informacja lub źródło informacji dotyczy. Wszelkie takie kopie lub reprodukcje będą własnością Zamawiającego.
5. Strony zobowiązują się do przestrzegania przy wykonywaniu Umowy wszystkich postanowień zawartych w obowiązujących przepisach prawnych związanych z ochroną danych osobowych, a także z ochroną informacji niejawnych oraz ochroną tajemnicy skarbowej.
6. Wykonawca zobowiązuje się zapoznać i przestrzegać przepisy regulujące zasady postępowania z dokumentami lub danymi Zamawiającego w zakresie niezbędnym do realizacji Przedmiotu Umowy, które obowiązują u Zamawiającego.
7. W przypadkach konieczności udostępnienia Wykonawcy informacji niejawnych, Wykonawca zapewni ze swojej strony udział w realizacji Umowy osób posiadających odpowiednie poświadczenie bezpieczeństwa, wydane zgodnie z ustawą z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz. U. z 2010 r. Nr 182, poz. 1228 z późn. zm.).
8. Obowiązek określony w ust. 1 niniejszego paragrafu nie dotyczy informacji powszechnie znanych oraz udostępniania informacji na podstawie bezwzględnie obowiązujących przepisów prawa, a w szczególności na żądanie sądu, prokuratury, organów podatkowych lub organów kontrolnych, a także informacji dostępnych publicznie, o których mowa w Ustawie o dostępie do informacji publicznej z dnia 6 września 2001 r. (Dz. U. z 2015 r., Nr 2058 z późn. zm.).
9. Nie będą uważane za chronione informacje, które:
a) wcześniej stały się informacją publiczną w okolicznościach nie będących wynikiem czynu bezprawnego lub naruszającego Umowę przez którąkolwiek ze Stron,
b) były zatwierdzone do rozpowszechniania na podstawie uprzedniej pisemnej zgody Strony, której dotyczą,
c) zostały przekazane Xxxxxxx otrzymującej przez osobę trzecią nie będącą Stroną Umowy zgodnie z prawem i bez ograniczeń.
10. Wykonawca ponosi odpowiedzialność za zachowanie w poufności informacji przez swoich pracowników, Podwykonawców i wszelkie inne osoby, którymi będzie się posługiwać przy wykonywaniu Umowy.
11. Wykonawca zobowiązuje się do podjęcia wszelkich niezbędnych kroków dla zapewnienia, że żaden pracownik Wykonawcy lub inna osoba, o których mowa w ust. 10, otrzymujący powyższe informacje, informacje chronione oraz informacje stanowiące tajemnicę organizacji, nie ujawni tych informacji, ani ich źródła, zarówno w całości, jak i w części osobom lub podmiotom trzecim bez uzyskania uprzednio wyraźnej pisemnej zgody Zamawiającego, którego informacja lub źródło informacji dotyczy.
12. Wykonawca zobowiązuje się do przekazania Zamawiającemu w ciągu 3 Dni roboczych od dnia zawarcia umowy, wykazu pracowników lub osób trzecich biorących udział w realizacji Umowy po stronie Wykonawcy wraz z oświadczeniem o ochronie informacji, według wzoru, który określa Załącznik nr 18 do Umowy.
13. Wykonawca zobowiązuje się do niezwłocznego przekazania wykazu oraz oświadczenia, o którym mowa w ust. 12, w przypadku zmian personalnych pracowników lub osób trzecich biorących udział w realizacji Przedmiotu Umowy.
14. Obowiązek zachowania w poufności informacji przez Wykonawcę obowiązuje także po ustaniu Umowy.
15. Wykonawca odpowiada za szkodę wyrządzoną Zamawiającemu przez ujawnienie, przekazanie, wykorzystanie, zbycie lub oferowanie do zbycia informacji otrzymanych od Zamawiającego, wbrew postanowieniom Umowy. Zobowiązanie to wiąże Wykonawcę również po wykonaniu Przedmiotu
Umowy, jej rozwiązaniu, wygaśnięciu lub odstąpieniu, bez względu na przyczynę i podlega wygaśnięciu według zasad określonych w przepisach dotyczących ochrony informacji niejawnych.
§ 15.
ZMIANY UMOWY
1. Wszelkie zmiany i uzupełnienia niniejszej Umowy wymagają formy pisemnej pod rygorem nieważności i zgody obu Stron.
2. Zmiany Umowy w rozumieniu ust. 1 nie stanowi w szczególności zmiana nazw/określeń Stron, siedziby Stron, numerów kont bankowych Stron, jak również zmiana w składzie osobowym Zespołu Realizacyjnego Zamawiającego, jak i w składzie osobowym Zespołu Projektowego Wykonawcy oraz zmiana w zakresie osób upoważnionych do podpisywania dokumentów wskazanych w Załączniku nr 11 i Załączniku nr 17 do Umowy.
3. Strony przewidują możliwość dokonania zmian postanowień niniejszej Umowy w niżej wymienionych przypadkach:
a) nastąpi zmiana powszechnie obowiązujących przepisów prawa w zakresie mającym wpływ na realizację Przedmiotu Umowy, chyba że zmiana taka znana była w chwili składania oferty;
b) niezbędna jest zmiana sposobu wykonania zobowiązania, o ile zmiana taka jest korzystna dla Zamawiającego, z wyjątkiem sytuacji, gdy zmiana ta ingeruje w treść oferty lub jest istotna, lub o ile zmiana taka jest konieczna w celu prawidłowego wykonania Przedmiotu Umowy;
c) niezbędna jest zmiana terminu realizacji Umowy w przypadku zaistnienia okoliczności lub zdarzeń uniemożliwiających realizację Umowy w wyznaczonym terminie, na które Strony nie miały wpływu;
d) zmiany miejsc dostaw, użytkowania, wykonywania świadczeń gwarancyjnych, świadczenia Usług stanowiących Przedmiot Umowy, oraz zmian adresów tych miejsc w wyniku zmian organizacyjnych i/lub zmian adresów Zamawiającego, jednostek nadzorowanych przez Zamawiającego, innych jednostek, na rzecz których, w imieniu których i/lub wspólnie z którymi Zamawiający udzielił zamówienia;
e) nastąpi zmiana wysokości minimalnego wynagrodzenia za pracę ustalonego na podstawie art. 2 ust. 3-5 ustawy z dnia 10 października 2002 r. o minimalnym wynagrodzeniu za pracę, jeżeli zmiany te będą miały wpływ na koszty wykonania zamówienia przez Wykonawcę,
f) nastąpi zmiana zasad podlegania ubezpieczeniom społecznym lub ubezpieczeniu zdrowotnemu lub wysokości stawki składki na ubezpieczenia społeczne lub zdrowotne, jeżeli zmiany te będą miały wpływ na koszty wykonania zamówienia przez Wykonawcę.
4. Jeżeli w trakcie realizacji Umowy nastąpi:
1) zmiana wysokości minimalnego wynagrodzenia za pracę,
2) zmiana zasad podlegania ubezpieczeniom społecznym lub ubezpieczeniu zdrowotnemu lub wysokości stawki składki na ubezpieczenia społeczne lub zdrowotne
Strony dokonają zmiany wysokości wynagrodzenia, o ile Wykonawca wystąpi do Zamawiającego pisemnie i przedstawi kalkulację uzasadniającą faktyczny wpływ zmian wskazanych w pkt 1 lub 2 powyżej na koszty wykonania zamówienia. Zamawiający zastrzega sobie prawo weryfikacji kalkulacji przedstawionej przez Wykonawcę oraz zgłoszenia uwag w przypadku uznania, że Wykonawca nie wykazał rzeczywistego wpływu zmian wskazanych w pkt 1 lub 2 na koszty wykonania zamówienia. W takiej sytuacji Wykonawca zobowiązany będzie do uwzględnienia uwag Zamawiającego oraz uzupełnienia bądź korekty przedstawionej kalkulacji.
5. Zmiany do Umowy mogą dotyczyć wszystkich postanowień Umowy, z tym że nie mogą spowodować wzrostu łącznego wynagrodzenia za wykonanie Przedmiotu Umowy, o którym mowa w § 8 ust. 1 Umowy, z zastrzeżeniem postanowień ust. 3 lit. e i f oraz § 8 ust. 13, oraz nie mogą stanowić podstawy do zmian Umowy sprzecznych z przepisami prawa.
6. Strony zobowiązane są do informowania się wzajemnie o okolicznościach uzasadniających konieczność dokonania zmiany Umowy.
§ 16.
Zasady lojalności
1. W okresie obowiązywania Umowy i w okresie 1 roku po jej wykonaniu, rozwiązaniu, wygaśnięciu lub odstąpieniu od niej przez którąkolwiek ze Stron, Wykonawca, jak i jakiekolwiek związane z nim i zależne od niego podmioty, a także Podwykonawca oraz jakikolwiek podmiot związany z Podwykonawcą i od niego zależny, nie będą zabiegali o zatrudnienie, ani bezpośrednio lub pośrednio zatrudniali na podstawie umowy o pracę, jak również umów cywilnoprawnych (w szczególności umowy o dzieło, umowy zlecenie) pracowników Zamawiającego, którzy współpracowali z Wykonawcą przy realizacji przedmiotu Umowy.
2. Zamawiający w okresie obowiązywania Umowy i w okresie 1 roku po jej wykonaniu, rozwiązaniu, wygaśnięciu lub odstąpieniu od niej przez którąkolwiek ze Stron, nie będzie zabiegał o zatrudnienie, ani bezpośrednio lub pośrednio zatrudniał na podstawie umowy o pracę, jak również umów cywilnoprawnych (w szczególności umowy o dzieło, umowy zlecenie) pracowników Wykonawcy, którzy współpracowali z Zamawiającym przy realizacji przedmiotu Umowy.
3. Xxxxxx, która naruszy zobowiązanie określone w niniejszym paragrafie, zapłaci tytułem kary umownej kwotę 25 000 zł brutto, za każdego zatrudnionego pracownika.
§ 17.
Postanowienia końcowe
1. W sprawach nieuregulowanych Umową zastosowanie mają odpowiednie przepisy prawa, w szczególności Kodeksu cywilnego, ustawy Prawo zamówień publicznych, ustawy o prawie autorskim i prawach pokrewnych oraz ustawy o ochronie danych osobowych.
2. W przypadku rozbieżności interpretacyjnych pomiędzy postanowieniami Umowy, a treścią załączników i innych dokumentów stanowiących integralną część Umowy lub wytworzonych przez Strony, pierwszeństwo mają postanowienia umowne.
3. Wykonawca nie może przenieść na osobę trzecią praw i obowiązków wynikających z Umowy, w całości lub w części.
4. Umowa podlega prawu polskiemu i zgodnie z nim powinna być interpretowana.
5. Strony Umowy podejmą w dobrej wierze wysiłek w celu rozwiązania wszelkich sporów powstałych pomiędzy Stronami, które wynikły w związku z realizacją Umowy i/lub jej interpretacją. O ile rozwiązanie sporu nie powiedzie się, zostanie on poddany pod rozstrzygnięcie sądu powszechnego właściwego rzeczowo dla siedziby Zamawiającego.
6. Umowę sporządzono w czterech jednobrzmiących egzemplarzach, w tym trzy egzemplarze dla Zamawiającego i jeden dla Wykonawcy.
7. Załączniki stanowiące integralną część Umowy:
1) Załącznik nr 1 „Szczegółowy Opis Systemu”.
2) Załącznik nr 2 „Protokół Dostawy Produktu”.
3) Załącznik nr 3 „Dokumentacja Systemu”
4) Załącznik nr 4 „Procedury dostawy, akceptacji i odbioru produktów oraz zarządzanie realizacją przedmiotu Umowy”.
5) Załącznik nr 5 „Ramowy Harmonogram Realizowanych Zadań i Planowanych Płatności”.
6) Załącznik nr 6 „Zgłoszenie Błędu/Gwarancyjne”.
7) Załącznik nr 7 „Zgłoszenie Incydentu/Problemu”.
8) Załącznik nr 8 „Raport z Usługi Wsparcia”.
9) Załącznik nr 9 „Zgłoszenie Zmiany”.
10) Załącznik nr 10 „Wniosek Zmiany”.
11) Załącznik nr 11 „Zespół Realizacyjny Zamawiającego”.
12) Załącznik nr 12 „Protokół Odbioru Produktu”.
13) Załącznik nr 13 „Kryteria jakości dla kodów źródłowych”.
14) Załącznik nr 14 „Protokół Akceptacji Produktu”.
15) Załącznik nr 15 „Protokół Odbioru Etapu”.
16) Załącznik nr 16 „Protokół Odbioru Pogwarancyjnego”.
17) Załącznik nr 17 „Zespół Projektowy Wykonawcy”.
18) Załącznik nr 18 „Oświadczenie o Ochronie Informacji”. 19)
Zamawiający ……………………………………………..... (imię i nazwisko, podpis) | Wykonawca ……………………………………………... (imię i nazwisko, xxxxxx) |
Załącznik nr 1 do umowy nr ... z dnia 2016r.
Tabela używanych skrótów.
Skrót | Opis |
Analiza ryzyka | Proces analizy dokumentów w systemie NCTS, mający na celu stwierdzenie, czy dokument spełnia warunki wyboru do kontroli. Analiza ryzyka opiera się o zestaw definiowanych profili. |
CCN/CSI | Common Communication Network/Common System Interface Wspólna Sieć Komunikacyjna/Wspólny Interfejs Systemów |
CN | Kod Nomenklatury Scalonej (Combined Nomenclature ). Tutaj oznacza 8 –znakowy kod towarowy w eksporcie i 10-znakowy kod TARIC w imporcie (8 znaków CN + 2 znaki kodu TARIC) |
Dokument XML | Plik XML przesyłany elektronicznie do SYSTEMU XXXXXX lub tworzony w tym systemie, zawierający dane dokumentu, zgodny ze schematem zdefiniowanym w specyfikacji elektronicznych zgłoszeń celnych lub zgłoszeń podsystemu INTRASTAT. |
Dyrektywa | Informacja przypisana do dokumentu, utworzona w procesie analizy ryzyka, stwierdzająca, że dokument zakwalifikowano do kontroli. |
FTP | Protokół transmisji plików (ang. File Transfer Protocol), który umożliwia przesyłanie plików z i na serwer poprzez sieć TCP/IP. |
Funkcja programu | Zestaw jednostkowych operacji wykonywanych przez program |
GUI | Graphical User Interface – Graficzny Interfejs Użytkownika. Typowymi elementami GUI są okna, rozwijane menu, przyciski, paski przewijania, ikony i zakładki. Użytkownik korzysta z interfejsu za pomocą myszy i klawiatury, klikając na graficzne reprezentacje poleceń zamiast wpisywać z klawiatury komendy. |
S.C. | Protokół używany w sieci WWW normalizujący sposób komunikowania się komputerów ze sobą (ang. Hypertext Transfer Protocol). |
HELP-DESK | Wsparcie merytoryczne i techniczne dla wszystkich jednostek organizacyjnych S.C. eksploatujących system NCTS |
IC | Izba Celna |
Internet | Ogólnoświatowa sieć komputerowa. |
Isztar3 | Informacyjny system zintegrowanej taryfy celnej |
OC | Oddział Celny |
NCTS | Nowy Skomputeryzowany System Tranzytowy |
On - line | Połączenie (np. w sieci Internet) umożliwiające przekazywanie danych w czasie rzeczywistym. |
Operacja | Wykonanie kroku w oprogramowaniu. |
Oprogramowanie aplikacyjne | Oprogramowanie wchodzące w skład wdrożonego systemu NCTS, wykonane na zamówienie administracji celnej lub zmodyfikowane przez Wykonawcę w ramach Umowy na podstawie specyfikacji wymagań funkcjonalnych uzgodnionych przez Strony, które będzie przedmiotem utrzymania i rozwoju systemu. |
Oprogramowanie standardowe | Całość systemu informatycznego realizowanego w ramach projektu NCTS. |
Oprogramowanie systemowe | System operacyjny po stronie serwera lub stacji roboczej. |
Skrót | Opis |
OSOZ | Ogólnopolski System Obsługi Zabezpieczeń |
SC | Polska Służba Celna. |
PDR | Podsystem Danych Referencyjnych |
PKI | Infrastruktura klucza publicznego |
Plan Jakości Projektu (PJP) | (ang. Project Quality Plan) – dokument o charakterze zarządczym, szczegółowo określający mechanizmy zarządzania i prowadzenia danego przedsięwzięcia, w tym procedury i sposoby realizacji zadań i czynności projektowych, a także relacje między Zamawiającym a Wykonawcą w trakcie trwania projektu. |
Podmiot zewnętrzny | Podmiot gospodarczy (inny niż Wykonawca) wyłoniony w trybie zamówienia publicznego w celu wykonania zadań (np. audyt kodów źródłowych) zleconych przez Zamawiającego. |
Profil analizy ryzyka | Xxxxxxxx definiujący, jakie pola dokumentu i pod jakim kątem mają zostać sprawdzone celem wyboru dokumentu do kontroli. W wyniku działania algorytmu dokumentowi może być przypisana dyrektywa. |
Protokół Odbioru | Dokument zawierający określenie produktu/usługi przedstawianych do odbioru oraz warunki tego odbioru, podpisywany przez Kierownika Projektu Wykonawcy i Zamawiającego, wystawiany na podstawie wewnętrznego Protokołu Akceptacji Zamawiającego. |
PWK | Podsystem Wymiany Komunikatów |
SAD | Jednolity Dokument Administracyjny, ang. Single Administrative Document |
SMTP | Protokół komunikacyjny opisujący sposób przekazywania poczty elektronicznej w internecie (ang. Simple Mail Transfer Protocol). |
Specyfikacja funkcjonalna | Dokument definiujący wymagania dla systemu/podsystemu. |
Specyfikacja techniczna | Dokument opisujący architekturę oraz strukturę baz danych systemu/podsystemu. |
Strona internetowa | Widoczna za pomocą przeglądarki internetowej strona witryny WWW, zapisana w formacie HTML lub podobnym. |
System Kontroli Wersji | System służący do śledzenia i identyfikacji zmian w kodzie źródłowym systemu (nazwa stosowanego przez Wykonawcę systemu zostanie podana w PJP). |
SQL | Język zapytań używany do tworzenia, modyfikowania baz danych oraz do umieszczania i pobierania danych z baz danych (ang. Structured Query Language). |
TCP/IP | Pakiet najbardziej rozpowszechnionych protokołów komunikacyjnych (ang. Transmission Control Protocol/Internet Protocol). |
Testy GUI | Testy interfejsu użytkownika |
UC | Urząd Celny. |
UE | Unia Europejska |
UML | Zunifikowany Język Modelowania, ang. Unified Modeling Language. |
Urząd Celny | Jednostka organizacyjna administracji celnej, w której mogą zostać dokonane czynności przewidziane w przepisach prawa celnego. |
Użytkownik wewnętrzny | Każdy funkcjonariusz lub pracownik S.C. zatrudniony w jednostkach resortu finansów posiadający uprawnienia do korzystania z aplikacji MCC. |
Walidacja | Proces analizy dokumentów w systemie, mający na celu stwierdzenie, czy dokument jest poprawny pod względem struktury oraz pod względem formalnym. |
Skrót | Opis |
WAN | Rozległa sieć telekomunikacyjna Polskiej Administracji Celnej i Podatkowej. |
Wersja produkcyjna systemu NCTS | Tryb pracy systemu, w którym są wprowadzane i przetwarzane przez system rzeczywiste dane podawane w zgłoszeniach przez podmioty gospodarcze z uwzględnieniem aktualnych danych referencyjnych. |
Wersja testowa systemu NCTS | Tryb pracy systemu, w którym są wprowadzane i przetwarzane przez system testowy wcześniej przygotowane dane testowe. |
WWW | Sposób dystrybucji informacji w sieci Internet (ang. World Wide Web). |
XML | Extensible Markup Language, rozszerzalny język znaczników, uproszczony podzbiór SGML (standardowego uogólnionego języka znaczników wg standardu ISO 8879/86), opisujący schemat znakowania, który pozwala zaznaczyć logiczną strukturę dokumentów niezależnie od używanego systemu i sprzętu. |
ZMPD | Zrzeszenie Międzynarodowych Przewoźników Drogowych |
System NCTS
System NCTS dedykowany jest do obsługi wspólnotowej/wspólnej procedury tranzytowej oraz procedury TIR realizowanych na podstawie Wspólnotowego Kodeksu Celnego (WKC) [5] i jego przepisów wykonawczych, Konwencji o Wspólnej Procedurze Tranzytowej (WPT) [6] oraz Konwencji TIR. Obowiązek stosowania systemu NCTS we wspólnotowej/wspólnej procedury tranzytowej datuje się od dnia 1 lipca 2005 r. Od dnia 1 stycznia 2009 obowiązek ten został rozszerzony na procedurę TIR w ramach obszaru UE.
System NCTS zapewnia wymianę informacji o operacji tranzytowej w czasie rzeczywistym w formie komunikatów wymienianych między uczestnikami procedury w trzech obszarach:
• pomiędzy krajowymi podmiotami gospodarczymi a krajową administracją celną ("obszar zewnętrzny"),
• pomiędzy krajowymi urzędami celnymi ("obszar krajowy"),
• pomiędzy poszczególnymi administracjami celnymi oraz administracjami celnymi a Komisją Europejską ("obszar wspólny").
Rys historyczny
NCTS jest systemem o zasięgu paneuropejskim. Stosowany jest w państwach członkowskich UE oraz w krajach EFTA. Każdy kraj uczestniczący w Projekcie Komputeryzacji Tranzytu prowadzonym przez DG Taxud KE realizował wdrożenie systemu NCTS we własnym zakresie, zgodnie z architekturą techniczną i funkcjonalną opracowaną przez Komisję Europejską.
Polska wykorzystała przy budowie systemu zestaw standardowych aplikacji MCC/ECN, opracowanych na zlecenie DG Taxud (Centrally Developed Transit Applications) i udostępnionych państwom członkowskim jako jeden z wariantów budowy systemu krajowego (wariant drugi dotyczył zbudowania systemu całkowicie własnymi zasobami). Od czasu wdrożenia polski system NCTS był wielokrotnie aktualizowany oraz uzupełniany i rozszerzany o dodatkowe funkcjonalności wynikające ze zmian legislacyjnych i funkcjonalnych określonych przez DG Taxud we współpracy z państwami członkowskimi.
Przedsięwzięcie zostało podzielone na 3 fazy. System NCTS został uruchomiony w Polsce w dniu 18 lutego 2004 roku, a jego rozszerzenie operacyjne na obszarze całego kraju zakończyło się w dniu 31 grudnia 2005 roku. Obecnie do systemu NCTS podłączone są wszystkie krajowe placówki celne obsługujące procedurę tranzytu.
Komisja Europejska podjęła decyzję o zaprzestaniu od dnia 30 czerwca 2008 r. dalszego wspierania i utrzymywania standardowych aplikacji MCC/ECN i przekazaniu pełnej odpowiedzialności za utrzymanie operacyjne systemu NCTS zgodnie z założeniami określonymi na poziomie UE.
Zakres informacyjny i funkcjonalność.
Procedura tranzytowa pozwala na zawieszenie należności celnych, podatkowych i innych opłat ciążących na towarach na czas przewozu towarów. System NCTS obsługuje całą operację tranzytową od jej rozpoczęcia (wprowadzenie do systemu danych zgłoszenia tranzytowego), aż do jej zakończenia i zamknięcia. Operacja tranzytowa jest monitorowana na każdym etapie realizacji procedury, tj. w urzędzie wyjścia, tranzytowym, przeznaczenia, zamknięcia oraz poszukiwania i poboru należności.
W sytuacji, gdy operacja tranzytowa nie zostanie zakończona w określonym czasie, w systemie NCTS prowadzona jest procedura poszukiwawcza. Jednocześnie blokowana jest gwarancja w celu zabezpieczenia kwot należności. Rezultatem przeprowadzenia procedury poszukiwawczej jest ostatecznie zamknięcie operacji lub rozpoczęcie procedury poboru długu.
System NCTS obsługuje operacje w procedurze zwykłej, tj. gdy towar przedstawiany jest w urzędzie celnym, jak również operacje realizowane w systemie uproszczeń. Procedura tranzytu uproszczona rozpoczyna się i/lub kończy w siedzibie przedsiębiorców posiadających pozwolenia administracji celnej na wykonywanie określonych czynności związanych z procedurą tranzytu (upoważniony nadawca/upoważniony odbiorca).
System NCTS monitoruje ponadto przebieg operacji tranzytowych pod osłoną karnetu TIR w standardowym zakresie z uwzględnieniem elementów związanych ze specyfiką konwencji TIR (np. typ gwarancji, informacja o rozładunku).
Dla potrzeb dokonywania unijnej analizy ryzyka pod kątem bezpieczeństwa i ochrony, system NCTS umożliwia opcjonalne uzupełnienie zgłoszenia tranzytowego przez zgłaszającego danymi bezpieczeństwa zgodnie z przyjętymi przepisami wspólnotowymi (tzw. „Security and Safety”).
W systemie NCTS dane dotyczące operacji tranzytowych przekazywane są pomiędzy urzędami celnymi w krajach UE i krajach EFTA oraz pomiędzy urzędami celnymi a przedsiębiorcami – za pośrednictwem ściśle zdefiniowanych komunikatów elektronicznych. Pełna lista komunikatów wymienianych w systemie NCTS oraz ich zawartość określona jest w dokumencie FTSS [14], [18] i DDNTA [15],[16]. Komunikaty wymieniane są w czasie rzeczywistym, co umożliwia natychmiastowy dostęp do informacji o przebiegu operacji tranzytowej na każdym etapie jej realizacji, po wprowadzeniu do systemu unikalnego numeru ewidencyjnego operacji tranzytowej MRN.
SCH1. Uproszczona architektura systemu NCTS – schemat poglądowy
1.1. Z punktu widzenia użytkownika System NCTS działa w architekturze centralnej.
1.2. Wszystkie komponenty sprzętowo-programowe systemu NCTS są zlokalizowane w Centrum Informatycznym Izby Celnej w Łodzi.
1.3. Większość procesów systemu NCTS jest obsługiwana przez oprogramowanie MCC dostosowaną do potrzeb Polskiej Administracji Celnej. Oprogramowanie zaprojektowane w architekturze klient- serwer:
• MCC Serwer- aplikacji zainstalowanej na głównym serwerze w Centrum Krajowym,
• MCC Klient - aplikacji zainstalowanej na stacjach roboczych w Oddziałach i Urzędach Celnych.
Aplikacje MCC Klient komunikują się z aplikacją MCC Serwer za pomocą komunikatów wysyłanych przy użyciu monitora transakcyjnego BEA TUXEDO. Wszystkie dane gromadzone są w relacyjnej bazie danych ORACLE na głównym serwerze w Centrum Krajowym, na którym zainstalowane są również:
• aplikacja ECN wraz z translatorem pomiędzy formatami XML, standardowym dla aplikacji MCC oraz EDIFACT, używanym w sieci CCN/CSI w obszarze wspólnym,
• kompilator IBM C/C++ niezbędny podczas instalacji aplikacji.
SCH2. – Architektura oprogramowania systemu NCTS w Polsce
1.4. Aplikacja MCC
Aplikacja MCC została napisana w architekturze klient-serwer. Na serwerze umiejscowionym w Centrum Krajowym zainstalowana jest część serwerowa aplikacji MCC (MCC Serwer), a na stacjach roboczych w jednostkach administracji celnej klienci aplikacji MCC (MCC Klient).
Komunikacja klientów MCC z serwerem aplikacji MCC odbywa się poprzez zdefiniowane komunikaty w formacie XML przesyłane przy użyciu mechanizmu kolejkowego monitora transakcyjnego BEA TUXEDO. Przy wykorzystaniu tego mechanizmu wszystkie komunikaty przesyłane od klienta lub z serwera trafiają do kolejek monitora TUXEDO, a odpowiednie serwisy monitora przesyłają je do właściwych adresatów.
1.5. Aplikacja ECN
ECN jest węzłem komunikacyjnym łączącym aplikacje pracujące w różnych obszarach systemu NCTS. Komunikacja wewnątrz systemu NCTS odbywa się przy wykorzystaniu komunikatów tekstowych według standardu XML i EDIFACT. Dla celów systemu NCTS zdefiniowanych zostało kilkadziesiąt specjalnych typów komunikatów tekstowych (IE), które przenoszą informację pomiędzy różnymi aplikacjami krajowymi podczas ich normalnej pracy.
Rozmieszczenie aplikacji ECN wewnątrz struktury systemu NCTS przedstawia rysunek nr 3.
Gateway CCN/CSI
Aplikacja ECN
Aplikacja MCC
LAN
Aplikacja ECN
Gateway CCN/CSI
Aplikacja MCC
LAN
Sieć CCN/CSI
64 Kbps
max
64 Kbps
max
Obszar "A" Obszar "B"
SCH3. – Rozmieszczenie aplikacji ECN wewnątrz struktury systemu NCTS
1.6. Architektura podsystemów uzupełniających
Krajowy system NCTS został uzupełniony o dodatkowe podsystemy:
• Podsystem danych referencyjnych PDR,
• Podsystem wymiany komunikatów PWK.
Oba te podsystemy są zainstalowane w oddzielnej od głównego systemu infrastrukturze
1.7. Podsystem danych referencyjnych PDR
Podsystem danych referencyjnych PDR jest źródłem krajowych danych referencyjnych dla systemu NCTS w Polsce. Może on zasilać w dane referencyjne inne systemy celne.
Rejestracja danych referencyjnych w PDR odbywa się bezpośrednio w placówkach odpowiedzialnych za te dane, a dostęp do PDR jest możliwy z dowolnej placówki celnej.
1.8. Podsystem wymiany komunikatów PWK
Podsystem wymiany komunikatów PWK służy do wymiany danych pomiędzy systemem NCTS a podmiotami gospodarczymi lub zewnętrznymi systemami, na przykład OSOZ, EORI, EOS.
Wygaszanie systemu NCTS
W marcu 2016 roku system NCTS został zastąpiony nowym systemem NCTS2. Głównym założeniem wygaszania systemu NCTS opartego na aplikacjach standardowych dostarczanych przez Komisje Europejską jest kończenia obsługi operacji tranzytowych rozpoczętych w systemie NCTS bez migracji danych do nowego systemu NCTS2. Zamykanie operacji tranzytowych będzie sukcesywnie dokonywane w systemie NCTS, gdzie finalnie wszystkie dokumenty będą musiały być dostępne dla użytkowników wewnętrznych w formie archiwum.
Wygaszanie systemu jest realizowane w niżej opisany sposób:
1.) Faza pierwsza
działanie Systemu NCTS z komponentami SISC przed uruchomieniem Systemu NCTS2.
2.) Faza druga
faza pilotowa NCTS2 3.) Faza trzecia
faza produkcyjna NCTS2
a) Etap 1
Roczny okres zapewnienia poprawnej obsługi rozpoczętych w systemie NCTS operacji tranzytowych.
b) Etap 2
5-letni okres dostępu do przeglądania danych operacji tranzytowych systemu NCTS
Jednym z zadań Wykonawcy jest zapewnienie prawidłowego przebiegu Fazy trzeciej wygaszania systemu oraz przygotowanie aplikacji MCC i pozostałych komponentów dla potrzeb prawidłowego działania archiwum.
SCH3. – Architektura Systemu NCTS - Faza trzecia – faza produkcyjna NCTS2 – Etap 2.
Załącznik nr 2 do umowy nr ... z dnia 2016r.
Protokół Dostawy Produktu
Wykonawca: | Zamawiający: | ||||
Protokół Dostawy Produktu nr … | |||||
System NCTS, Umowa nr ... | |||||
Nr pisma | Data dostawy | Miejsce dostawy | |||
Funkcja | Podpis | Data | |||
Kierownik Xxxxxxx Wykonawcy (imię i nazwisko) | |||||
Xxxxxxxxx Projektu Wykonawcy (imię i nazwisko) | |||||
Kierownik Projektu Zamawiającego (imię i nazwisko) (odbiór ilościowy produktu) | |||||
Lp. | Produkt */Typ | Nośnik *** | Liczba szt. | Opis ** | |
Nr wersji poprzedniej *** | |||||
Nr wersji dostarczanej *** | |||||
Dokumenty dołączone i odnośne | |||||
Odbiór ilościowy produktu | |||||
Odbiór ilościowy produktu | Odrzucenie ilościowe produktu | ||||
Uzasadnienie odrzucenia ilościowego produktu: **** | |||||
* Podać oznaczenie produktu zgodnie z ustalonym oznakowaniem
** Podać cechy produktu jednoznacznie charakteryzujące produkt, w tym odnośnik do §, ust., pkt Umowy, nazwa, nr wersji, nr kolejny, data wydania.
*** Dotyczy oprogramowania
**** Wypełnić w przypadku odrzucenia
Dokumentacja referencyjna
Załącznik nr 3 do umowy nr ... z dnia 2016r.
Dokumentacja Systemu
L.p. | Nazwa | Oznaczenie | Wersja |
1. | FUNCTIONAL TRANSIT SYSTEM SPECIFICATION | FTSS-4 0-e-2008 | 4.0e |
2. | Design Document for Common Operations and Methods – Main Document | DDCOM-Main Document | 14.10 |
3. | Design Document for National Transit Application (DDNTA) | CUD-SC01-DDNTA-v19.40 | 19.40 |
4. | Scope of NCTS Phase4 | NCTS P4-Scope Document- v19.10-SfA | 19.10 |
5. | FTSS Corrigendum 2009 | FTSS-CORR-2013 | |
6. | List of amendments on message IE015 and all relevant messages (IE001, IE017, IE018, IE043) | NCTS/TIR | KE 2009.04.09 |
7. | eCustoms Technical Architecture Specification | 1.00 | |
8. | Business Continuity Plan | Lipiec 2009 | |
9. | SLA for Availability and Continuity of Customs Trans-European Systems between National Administrations and DG TAXUD | ITS-ISLA-eCUST-TES- ACM | 4.2.0-EN |
10. | Terms of Collaboration for the Customs Trans- European Systems | ITS-ITOC-eCUST-TES | 3.1.0-EN |
11. | Scope Document Common Volume | CUD-SC05-SDCOM | 5.00-EN |
12. | eCustoms Security System Specifications | 0.10-EN | |
13. | Security Policy Document | TSS-SEC-POL | 3.05-EN |
14. | Acceptance & Certification Specifications for NCTS Phase 4 | NCTSP4-ACS | 9.10-EN |
15. | Start-Up Guide For Ncts Phase 4 | CUD-SC01-NCTS P4-SUG | 1.20-EN |
16. | Conformance Test Organization Document | ITS-IRPT-CTO-002-NCTS | 1.03 |
17. | Conformance Test Organization Document for NCTS KEL v0.23 | ITS-IRPT-CTO-002-NCTS KELv0.23 (Part2) | 1.70 |
18. | Conformance Test Protocol for NCTS Phase 4 | NCTSP4 CTP | 3.60 |
19. | System Requirements Definition – ECN | ECN-SRD-System Requirements Definition- v4.60 | 4.40 |
20. | System Requirements Definition – MCC | MCC-SRD-System Requirements Definition- v4.60 | 4.60 |
21. | Real time SafeTIR (RTS) Web-Services-Interface Specification | RTS | 1.0 |
Dokumentacja powykonawcza.
L p. | Tytuł dokumentu | Nazwa pliku | Wersja 2015 | Data |
1 | NCTS 3.2. Architektura techniczna systemu NCTS dla fazy 3.2 | NCTS4-ARTECH-3.02.pdf | 4.0 | |
2 | NCTS 3.2. Podręcznik administratora Podsystemu Wymiany Komunikatów | NCTS4-ADM-PWK 2.03.pdf | 4.02 | 17.02.2015 |
3 | NCTS 3.2. Podręcznik Administratora MCC faza 4 | NCTS4-AMN-3.04.pdf | 4.01 | 17.02.2015 |
4 | NCTS 3.2. Podręcznik użytkownika – Część I. Informacje ogólne | NCTS4-UMN-Cz1-2.04.doc | 4.01 | 17.02.2015 |
5 | NCTS 3.2. Podręcznik użytkownika – Część II. Urząd wyjścia | NCTS4-UMN-Cz2-2.04.doc | 4.03 | 17.02.2015 |
6 | NCTS 3.2. Podręcznik użytkownika – Część III. Urząd przeznaczenia | NCTS4-UMN-Cz2-2.04.doc | 4.03 | |
7 | NCTS 3.2. Podręcznik użytkownika – Część IV. Urząd tranzytowy | NCTS4-UMN-Cz2-2.04.doc | 4.03 | |
8 | NCTS 3.2. Podręcznik użytkownika – Część V. Role Urzędu wyjścia: Urząd zamknięcia i Urząd poszukiwania/poboru | NCTS4-UMN-Cz2-2.04.doc | 4.03 | |
9 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna | NCTS4-SPEC-2.06.pdf | 4.05 | 17.02.2015 |
10 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja I – rozszerzenie dla fazy NCTS 3.2 | NCTS4-SPEC-S1-2.06.pdf | 4.05 | |
11 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja II: Główne procesy funkcjonalne | NCTS4-SPEC-S2-2.06.pdf | 4.05 | 17.02.2015 |
12 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja III – Obsługa gwarancji | NCTS4-SPEC-S3-2.06.pdf | 4.05 | |
13 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja IV: Procesy funkcjonalne dla usług centrowych | NCTS4-SPEC-S4-2.06.pdf | 4.05 | |
14 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja V: Procesy funkcjonalne dotyczące administrowania systemem | NCTS4-SPEC-S5-2.06.pdf | 4.05 | |
15 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna – Sekcja IX: Obsługa szczególnych przypadków | NCTS4-SPEC-S9-2.06.pdf | 4.05 | |
16 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna. Załącznik A3: Kody proceduralne | NCTS4-SPEC-ZA3-2.06.pdf | 4.05 | |
17 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna. Załącznik B: Logiczny model danych/ Funkcjonalna struktura komunikatów | NCTS4-SPEC-ZB-2.06.pdf | 4.05 | |
18 | NCTS 3.2. Wyspecjalizowane usługi informatyczne dla potrzeb wsparcia, rozwoju i utrzymania systemu NCTS. Specyfikacja funkcjonalna. Załącznik D: Szczegółowy wykaz szczególnych przypadków | NCTS4-SPEC-ZD-2.06.pdf | 4.05 |
Załącznik nr 4 do umowy nr ... z dnia 2016r.
Procedury dostawy, akceptacji i odbioru produktów oraz zarządzanie realizacją przedmiotu Umowy
I. Definicje
Pojęcie | Określenie znaczenia |
Błąd | Działanie aplikacji, które jest niezgodne z ustalonym. |
Błąd regresji | Błędne działanie lub inne problemy z elementami oprogramowania wcześniej odebranymi. |
Testy iteracyjne - TI. | Organizowane i przygotowywane przez Wykonawcę testy komponentów oprogramowania (modułów) z udziałem użytkownika końcowego. Wykonanie TI ma zapewnić użytkownikom końcowym możliwość oceny funkcjonalności przygotowanego oprogramowania, wykrycia błędów w oprogramowaniu na wczesnym etapie i zgłoszenia uwag, zmian i uzupełnień do założonej funkcjonalności. |
Testy akceptacyjne - TA | Przygotowane i przeprowadzone przez Zamawiającego testy wytworzonego systemu informatycznego. Wykonanie TA ma potwierdzić, że system jest przygotowany do pracy, spełnia założone kryteria jakości, w tym jego funkcjonalność jest zgodna z wymaganiami użytkowników i nie zawiera błędów uniemożliwiających jego użycie. |
Test poinstalacyjny | Test potwierdzający, że instalacja jest kompletna. |
Użytkownik końcowy | Osoba po stronie Zamawiającego wykorzystująca w rzeczywistości daną funkcjonalność Systemu |
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.
Wszystkie dostarczone produkty powinny być wyraźnie i jednoznacznie zidentyfikowane.
Sporządzony, zgodnie z szablonem będącym Załącznikiem nr 2 do Umowy, Protokół Dostawy Produktu zawiera:
nazwę Wykonawcy, nazwę Zamawiającego,
numer protokołu, nazwę Systemu, numer Umowy, datę i miejsce dostawy,
określenie dostarczonego produktu (typ, nazwa, numer wersji i inne informacje jednoznacznie identyfikujące produkt),
data dostawy,
format, liczbę kopii.
Każdy Protokół Dostawy Produktu jest podpisywany przez Kierownika Projektu Wykonawcy oraz Kierownika Jakości Wykonawcy lub w przypadku ich nieobecności, przez osoby upoważnione po stronie Wykonawcy wskazane w Załączniku nr 17.
Odbiór dostarczanych produktów jest przeprowadzany trójstopniowo, składa się z: odbioru ilościowego, odbioru jakościowego (merytorycznie) oraz odbioru końcowego (formalnego).
Każdy z dokumentów potwierdzających dokonanie odbioru ilościowego, jakościowego i formalnego, a więc odpowiednio Protokół Dostawy Produktu, Protokół Akceptacji Produktu (Załącznik nr 14) oraz Protokół Odbioru Produktu (Załącznik nr 12) przekazywane są Wykonawcy w terminie 3 Dni roboczych po dniu podpisania.
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 iteracyjne z udziałem użytkownika końcowego. Testy iteracyjne 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 iteracyjne oprócz Raportu z testów wewnętrznych do dostawy produktu należy dołączyć Raport z testów iteracyjnych.
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 Kierownika 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 Kierownika Projektu Zamawiającego, oznaczonych nazwą systemu/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 iteracyjnych, o ile takie były przeprowadzane,
- biuletyny zmiany do dokumentacji technicznej i użytkowej, w zakresie związanym z dostarczanym produktem
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.
3. Odbiór jakościowy (merytoryczny) polega na zweryfikowaniu, czy produkt spełnia wymagania jakościowe określone przez Zamawiającego poniżej w Tabeli nr 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 Zamawiającego w terminie 5 Dni roboczych od dnia podpisania Protokołu Dostawy przygotowuje Plan Testów Akceptacyjnych, który następnie przekazuje Kierownikowi Projektu Wykonawcy. Wykonawca może w ciągu 2 Dni roboczych od otrzymania Planu wprowadzić swoje uwagi do dokumentu i przekazać je pisemnie Zamawiającemu. Dla uwag nie zrealizowanych Zamawiający 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 od daty podpisania Protokołu Dostawy.
Podstawą do podjęcia decyzji w kwestii odbioru jakościowego oprogramowania jest Raport z testów akceptacyjnych. Raport ten sporządzany jest w 3 egzemplarzach. Dwa z nich przekazywane są Kierownikowi Projektu Wykonawcy w oryginale. Raport z testów jest dodatkowo przesyłany do Kierownika Projektu Wykonawcy za pomocą poczty elektronicznej. 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 są zostały zamieszczone poniżej w Tabeli nr 1.
W takim wypadku sporządzany jest Protokół Akceptacji Produktu, bez uwag z rekomendacją dokonania odbioru formalnego. Jeżeli dostarczone oprogramowanie zawiera wady o dopuszczalnym w kryteriach jakości poziomie, stwierdzone wady powinny zostać usunięte w terminach i przy zastosowaniu procedur dotyczących 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 Kierownika 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.
Xxxx, 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 § 3 Umowy.
c) Odrzucenie - jeśli dostarczony produkt nie spełnia założonych kryteriów jakości, a w szczególności, że 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 odrzucenia produktu lub jego akceptacji z uwagami, termin nowej dostawy nie może przekroczyć 10 Dni roboczych od przekazania Wykonawcy Protokołu Akceptacji Produktu z decyzją o odrzuceniu dostawy lub akceptacji z uwagami.
Jeśli produkt jest dostarczany po raz kolejny, z uwzględnieniem uwag wynikających z wcześniejszej akceptacji z uwagami, Zamawiający dokona odbioru jakościowego w terminie 5 Dni roboczych od daty ponownej dostawy.
Jeśli dostawa produktu została odrzucona do ponownej dostawy tego produktu stosuje się procedurę i terminy analogiczne jak w sytuacji pierwszej dostawy tego produktu.
Potwierdzeniem dokonania odbioru jakościowego produktu jest podpisanie Protokołu Akceptacji Produktu bez uwag, przez Kierownika Projektu Zamawiającego lub upoważnioną 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 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 oraz w przypadku produktu związanego z realizacją obszaru zmiennego Umowy, że spełnia on także wymagania określone we Wniosku Zmiany.
Odbiór końcowy produktu dokonywany jest przez Zamawiającego w terminie 3 dni roboczych od daty przekazania Wykonawcy Protokołu Akceptacji Produktu.
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, 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 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 Xxxxxxxxxx Projektu Wykonawcy przekazując mu pisemnie swoją decyzję wraz uzasadnieniem. Od tej decyzji Kierownik Projektu Wykonawcy może złożyć pisemny protest do osoby wymienionej w § 6 ust. 1, która 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 12, podpisywanym przez 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 i końcowego a więc odpowiednio Protokół Dostawy, Protokół Akceptacji Produktu oraz Protokół Odbioru Produktu przekazywane są Wykonawcy najpóźniej następnego dnia roboczego po dniu podpisania.
Tabela nr 1
Nr | Opis kryterium | Co należy mierzyć (techniki pomiaru) | Warunki spełnienia kryterium |
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łąd –Priorytet 1, Błąd –Priorytet 2, Błąd –Priorytet 3, | Liczba błędów każdego typu zapisana w rejestrze błędów, ustanawianym dla każdego rodzaju testów potwierdzających funkcjonalność (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łąd –Priorytet 1= 0, | |
Nr | Opis kryterium | Co należy mierzyć (techniki pomiaru) | Warunki spełnienia kryterium |
Błąd –Priorytet 4. | Błąd –Priorytet 2= 1, Błędy o Priorytecie 3 i 4 = 10, | ||
1.3 | Dopuszczalny poziom błędów dla nowej wersji oprogramowania dostarczanej w wyniku usuwania wady Systemu (tzw. łata programowa patch) | ||
Zdefiniowano klasyfikację błędów w systemie. Dopuszczane są następujące wagi błędów: Błąd –Priorytet 1, Błąd –Priorytet 2, Błąd –Priorytet 3, Błąd –Priorytet 4. | Liczba błędów każdego typu zapisana w rejestrze błędów, ustanawianym dla każdego rodzaju testów potwierdzających funkcjonalność (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 o priorytecie 3 nie może posiadać błędów o priorytetach 1, 2, 3. Jeżeli łata programowa obejmuje kilka wad o różnej wadze, przekazywane oprogramowanie nie może zawierać błędów o wadze równej lub wyższej w hierarchii, niż wada o najwyżej wadze, którą dana łata usuwa. | |
Łata programowa nie wprowadza błędów regresji | |||
Błędy regresji = 0 | |||
1.4 | 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 | |||
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 | Nieuprawnieni użytkownicy nie mogą korzystać z systemu. | |
Nr | Opis kryterium | Co należy mierzyć (techniki pomiaru) | Warunki spełnienia kryterium |
użytkowników oraz poziom ich uprawnień określony jest w specyfikacji wymagań funkcjonalnych. | |||
Dane są zabezpieczone przed utratą. | Sprawdzenie procedur konfiguracji oraz poprawności działania systemu w trakcie awarii zasilania, sprzętu itp. | Dane wprowadzone do systemu przed awarią są dostępne i nie zmienione po odzyskaniu. | |
Zapewniony jest audyt zmian w zakresie tych danych, które określono w specyfikacji wymagań. | Sprawdzenie czy system rejestruje informacje o użytkowniku wykonującym operacje na danych, określonych jako przeznaczone do śledzenia zmian w specyfikacji wymagań funkcjonalnych. | 100% zgodności. | |
Zaimplementowane są narzędzia odtwarzania i archiwizacji (backup) danych. | Sprawdzenie poprawności działania narzędzi do odtwarzania i archiwizacji, zgodnie z przyjętymi procedurami. | System po wykonaniu archiwizacji i odtworzeniu działa poprawnie. | |
Architektura spełnia wymagania dotyczące bezpieczeństwa danych, wynikające ze specyfikacji wymagań technicznych. | 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. | |
Cecha 3 – Użyteczność | |||
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. | Wymiana określonych danych z systemami zewnętrznymi. (Testy) | Możliwa wymiana w zakresie określonym w Specyfikacji wymagań funkcjonalnych. |
3.2 | Dane do systemu powinny być wprowadzane raz. | Sprawdzenie czy określony zestaw danych wprowadzany jest do systemu tylko raz. (Testy) | 100% zgodności. |
3.3 | Interfejs programu został dostosowany do wymagań użytkowników. | 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. | 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. |
3.4 | Diagnostyka błędów oraz reakcji na sytuacje graniczne. | Sprawdzenie czytelności komunikatów o błędach lub komunikatów walidacji | Komunikaty są czytelne i zrozumiałe. |
Nr | Opis kryterium | Co należy mierzyć (techniki pomiaru) | Warunki spełnienia kryterium |
wprowadzanych danych. | |||
3.5 | Spójność interfejsu GUI użytkownika. | Sprawdzenie czy interfejs GUI jest spójny pod względem koncepcji, syntaktyki, semantyki, formatu wprowadzania i prezentacji danych, stosowanych skrótów. | Interfejs spełnia wymagania spójności w stopniu określonym w specyfikacji technicznej. |
3.5 | Potwierdzanie wprowadzania / obróbki danych | Aktywne elementy graficzne systemu wizualnie potwierdzają wykonanie funkcji, która jest do nich przypisana. Wybrane dane są wyróżniane. System wyświetla widoczny pasek postępu wykonania operacji dla operacji zabierających więcej czasu niż 2 sekundy. | 100% zgodności |
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 i 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ą się 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. | 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. |
6.2 | Aplikacja zawiera narzędzia do deinstalacji lub określone są procedury deinstalacji. | Istnieje stosowna aplikacja, zestaw aplikacji lub procedura. (Testy) | 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 jasny i zrozumiały oraz adekwatna (można w oparciu o nią zainstalować system). | Instalacja aplikacji zgodnie z punktami procedury instalacji, przebiega prawidłowo. Po zakończeniu instalacji aplikacja nadaje się do użycia (realizuje pełną funkcjonalność zgodną z kryteriami jakości od 1 do 6). |
5. TESTY
W ramach Przedmiotu Umowy Wykonawca zobowiązany jest do przeprowadzenia następujących typów testów:
5.1. Testy wewnętrzne - przeprowadzane przez Wykonawcę przed dostawą Zamawiającemu oprogramowania - w siedzibie, na sprzęcie i w środowisku testowym przygotowanym przez Wykonawcę według przygotowanych przez niego scenariuszy testów. Zamawiający na prośbę Wykonawcy może dostarczyć dane testowe do wykonania tych testów. Celem testów wewnętrznych jest stwierdzenie, że aplikacja dostarczana Zamawiającemu spełnia założone kryteria jakości. Wynikiem testów wewnętrznych jest raport z testów wewnętrznych dołączany do Protokołu Dostawy.
5.2. Testy iteracyjne - organizowane i przygotowywane przez Wykonawcę testy komponentów oprogramowania (modułów) z udziałem użytkownika końcowego. Wykonawca jest odpowiedzialny za:
a) przygotowanie danych testowych,
b) przygotowanie scenariuszy testów,
c) przygotowanie środowiska testowego,
d) instalację aplikacji,
e) ładowanie danych testowych.
Wykonanie testów iteracyjnych ma zapewnić użytkownikom końcowym możliwość oceny funkcjonalności przygotowanego oprogramowania, wykrycia błędów w oprogramowaniu na wczesnym etapie i zgłoszenie uwag, zmian oraz uzupełnień do założonej funkcjonalności.
Testy iteracyjne składają się z następujących rodzajów testów funkcjonalnych:
5.2.1. Testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu. Podczas analizy wyników testów nie jest badany wewnętrzny sposób realizacji funkcji systemu. Testy weryfikują implementację funkcjonalności z podaną w specyfikacji. Dane wejściowe i oczekiwane wyniki przygotowywane są na podstawie specyfikacji. Podczas testów system jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane dane wejściowej sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi;
5.2.2. Testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu (modułu), które mają na celu sprawdzenie, czy aplikacja działa zgodnie z uzgodnioną specyfikacją wymagań dla poszczególnych modułów. Upewnienie się, że każda funkcja umożliwia realizację wszystkich dopuszczalnych akcji sytuacji, oraz uniemożliwia realizację każdej akcji i sytuacji zabronionej;
5.2.3. Testy GUI - sprawdzenie nawigacji w systemie, sprawdzenie poprawności tłumaczenia interfejsu oraz tłumaczenia i podłączenia powiązań help-u z formatkami programu,
5.2.4. Testy administracji i kontroli procedur administracji,
5.3. Testy akceptacyjne - przygotowane i przeprowadzone przez Zamawiającego testy wytworzonego oprogramowania. Testy są przeprowadzane przez Zamawiającego przy udziale Wykonawcy. Do wykonania testów akceptacyjnych zostanie wykorzystana aplikacja STTA i scenariusze testowe zawarte w dokumentacji DG TAXUD. Testy te wykonywane są u Zamawiającego, na jego sprzęcie i przez jego zespół testowy, w obecności przedstawicieli Wykonawcy. Przed rozpoczęciem testów Wykonawca przeprowadzi szkolenie dla zespołu testowego. Zamawiający jest odpowiedzialny za przygotowanie planu testów, danych testowych i scenariuszy testów. Wykonawca odpowiada za:
a) dostarczenie arkuszy testowych,
b) przygotowanie środowiska testowego,
c) instalację aplikacji,
d) ładowanie danych testowych.
Wykonanie testów akceptacyjnych ma potwierdzić, że system spełnia założone kryteria jakości, w tym że jego funkcjonalność jest zgodna z wymaganiami biznesowymi użytkowników i nie zawiera błędów uniemożliwiających jego użycie. Wynikiem testów akceptacyjnych jest raport z testów, który jest podstawą sporządzenia Protokołu Akceptacji Produktu lub Usługi. Testy akceptacyjne będą składały się z następujących typów testów:
5.4. Testy funkcjonalne:
a) testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu. Podczas analizy wyników testów nie jest badany wewnętrzny sposób realizacji funkcji systemu. Testy weryfikują implementację funkcjonalności z podaną w specyfikacji. Dane wejściowe i oczekiwane wyniki przygotowywane są na podstawie specyfikacji. Podczas testów system jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane dane wejściowej sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi,
b) testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu (modułu), które mają na celu sprawdzenie, czy aplikacja działa zgodnie z uzgodnioną specyfikacją wymagań dla poszczególnych modułów. Upewnienie się, że każda funkcja umożliwia realizację wszystkich dopuszczalnych akcji sytuacji, oraz uniemożliwia realizację każdej akcji i sytuacji zabronionej,
c) testy GUI - sprawdzenie nawigacji w systemie, sprawdzenie poprawności tłumaczenia interfejsu oraz tłumaczenia i podłączenia powiązań helpu z formatkami programu,
d) testy administracji i kontroli procedur administracji,
5.5. Testy integracyjne:
a) testy instalacji i uzyskanej konfiguracji – testy polegają na sprawdzeniu kompletności instalacji, zgodności przebiegu procesu instalacji z instrukcją, dokumentacją oraz poprawności uzyskanej konfiguracji,
b) testy komunikacji między modułami - testy poprawności powiązań między modułami. Celem testu jest wykazanie, że poszczególne moduły systemu prawidłowo ze sobą współpracują i na tej podstawie dalsze testy sprawdzają, czy funkcjonalność systemu wymagająca zaangażowania wielu modułów jest również realizowana prawidłowo.
5.6. Testy wydajnościowe i bezpieczeństwa:
a) testy wydajności - dotyczą wydajności działania systemu w różnych warunkach jego obciążenia. Testy weryfikują, czy system jest w stanie w oczekiwanym czasie obsłużyć/wykonać oczekiwaną ilość danych/funkcji. Testy wymagają pomiarów czasu wykonania poszczególnych funkcji, jak również mogą dotyczyć zweryfikowania przepustowości kanałów przeznaczonych do obsługi danych (np. kolejek, łączy sieciowych, portów itp.). W celu uzyskania właściwej oceny należy zasymulować
w miarę możliwości rzeczywiste warunki pracy systemu w jego rzeczywistym środowisku, wraz z symulowanym obciążeniem rzeczywistym kanałów transmisji danych,
b) testy obciążenia znamionowego - celem testu jest zweryfikowanie zachowania się systemu w typowych warunkach, potwierdzając tym samym prawidłową, stabilną pracę systemu, z wydajnością nie mniejszą od oczekiwanej, zdefiniowaną w dokumentacji technicznej,
c) testy przeciążenia – celem testu jest zweryfikowanie zachowania się systemu w nietypowych warunkach. Test ma potwierdzić, że system zachowuje się stabilniej nie doprowadza do utraty danych (niespójności bazy itp.) pomimo degradacji systemu,
d) testy stabilności - kontrola stabilnej pracy systemu przez określony czas, np. 24 godziny,
e) testy bezpieczeństwa – w tym bezpieczeństwo dostępu do danych i zabezpieczenia danych przed utratą, administracja użytkownikami i bazą danych, zakres dostępu do funkcji i danych, reakcja na nieoczekiwane dane, reakcja na podmianę komponentów, bibliotek systemu, itp.,
f) testy regresywne – wykonywane po wprowadzeniu zmian do systemu i mające na celu sprawdzenie, czy nowo wprowadzone poprawki nie mają wpływu na wcześniej zrealizowane funkcje systemu.
5.7. Testy krajowe (w razie potrzeby i stosownie do wymagań DG TAXUD):
5.7.1. Wykonawca zobowiązany będzie do przeprowadzenia testów krajowych (zwanych Mode 1),
5.7.2. do przeprowadzenia testów zostanie powołany zespół mieszany składający się ze specjalistów Wykonawcy i Zamawiającego,
5.7.3. testy zostaną przeprowadzone przy zastosowaniu aplikacji testującej STTA dla odpowiedniej fazy zgodnie z warunkami, scenariuszami i procedurami testowymi zawartymi w dokumentacji testowej nowej wersji oprogramowania,
5.7.4. testy zostaną przeprowadzone w środowisku planowanym dla rzeczywistej pracy systemu NCTS na sprzęcie i oprogramowaniu zainstalowanym u Zamawiającego,
5.7.5. uzyskanie zatwierdzenia testów krajowych z CZP systemu NCTS w Brukseli; testowane środowisko i zainstalowany system będzie służyć do rzeczywistej eksploatacji systemu NCTS.
5.8. Testy międzynarodowe (tzw. testy zgodności, conformance testing):
5.8.1. Wykonawca, w razie potrzeby i zgodnie do wymaganiami DG TAXUD, przeprowadzi testy zgodności systemu NCTS w celu weryfikacji kompatybilności systemu polskiego NCTS z systemem NCTS w Brukseli,
5.8.2. do przeprowadzenia testów zostanie powołany zespół mieszany składający się ze specjalistów Zamawiającego i Wykonawcy,
5.8.3. testy zostaną przeprowadzone przy użyciu aplikacji testującej TTA zgodnie z warunkami, scenariuszami i procedurami testowymi zawartymi w dokumentacji testowej dla fazy 4 (zgodność z aktualną listą KEL); testy będą przeprowadzone na rzeczywistej instalacji systemu,
5.8.4. wymagane jest uzyskanie zatwierdzenia testów przez CZP systemu NCTS w Brukseli.
5.9. Raport z testów.
Wyniki z przeprowadzonych testów będą zapisywane w raporcie z testów według poniższego wzoru:
Raport z testów
Wykonawca: . . . . . . . . . . . | Zamawiający: Ministerstwo Finansów | |
Umowa: . . . . . . . . . . . | ||
RAPORT Z TESTÓW
Niniejszy raport został sporządzony w dniu i zaakceptowany przez komisję w składzie:
ze strony Wykonawcy | ze strony Zamawiającego |
1. Czas trwania testów, skład zespołu testowego
• Testy zostały przeprowadzone w dniu . . . . . . . . . . . w godzinach od . . . . . . . . . . . do przez:
o o
2. Konfiguracja Sprzętu i Oprogramowania:
o
3. Konfiguracja i wersja aplikacji
•
4. Charakterystyka zgłoszonych problemów testowych i braków funkcjonalnych
•
5. Lista wykonanych scenariuszy testowych
•
6. Ocena przebiegu testów akceptacyjnych
•
7. Wynik testów aplikacji – lista błędów wraz z ich wagami z odniesieniem do scenariuszy testowych
•
8. Podsumowanie spełnienia kryteriów testowanego oprogramowania i rekomendacja.
•
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 Xxxxxxx 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, opisane poniżej w części dot. zarządzania realizacją przedmiotu Umowy,
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 1 większą od poprzedniej. Cykl walidacji zostaje zamknięty po zaakceptowaniu przez Kierownika Xxxxxxx 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.
Dokumentacja jest dostarczana w formie elektronicznej oraz w jednym egzemplarzu w wersji papierowej do archiwum podsystemu. Wykonawca dostarczy repozytoria projektowe aplikacji w formacie stosowanych narzędzi Enterprise Architect (zapewni Zamawiającemu Viewer do przeglądania produktów tego programowania).
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ą 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.
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 1 Dnia roboczego od podpisania Protokołu Dostawy powołuje do życia 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 decyzję w
kwestii odbioru jakościowego. Decyzja ta powinna zapaść w terminie 16 Dni roboczych od daty podpisania Protokołu Dostawy.
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 zablokować jego dalszą 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 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 nie dostarczony.
W przypadku odrzucenia produktu lub jego akceptacji z uwagami, termin nowej dostawy nie może przekroczyć 10 Dni roboczych od przekazania Wykonawcy Protokołu Akceptacji Produktu z decyzją o odrzuceniu dostawy lub akceptacji z uwagami.
Jeśli produkt jest dostarczany po raz kolejny, z uwzględnieniem uwag wynikających z wcześniejszej akceptacji z uwagami, Zamawiający dokona odbioru jakościowego w terminie 5 Dni roboczych od daty ponownej dostawy.
Jeśli dostawa produktu została odrzucona do ponownej dostawy tego produktu stosuje się procedurę i terminy analogiczne jak w sytuacji pierwszej dostawy tego produktu.
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 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.
Odbiór końcowy produktu dokonywany jest przez Zamawiającego w terminie 3 Dni roboczych od daty przekazania Wykonawcy Protokołu Akceptacji Produktu.
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 i zażądać ponownego przeprowadzenia całej trzystopniowej procedury odbiorczej. O fakcie tym, w terminie przewidzianym dla odbioru końcowego, informuje Xxxxxxxxxx Projektu Wykonawcy przekazując mu pisemnie swoją decyzję wraz uzasadnieniem. Od tej decyzji Kierownik Projektu Wykonawcy może złożyć pisemny protest do osoby wymienionej w § 6 ust. 1, która 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 12 do Umowy, podpisywanym przez 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 i końcowego a więc odpowiednio Protokół Dostawy, Protokół Akceptacji Produktu oraz Protokół Odbioru Produktu przekazywane są Wykonawcy najpóźniej następnego Dnia roboczego po dniu podpisania ich przez Kierownika Projektu Zamawiającego.
IV. Zarządzanie Realizacją Przedmiotu Umowy
Definicje użyte w tej części Załącznika nr 4
Termin | Definicja |
Centralny Zespół Projektowy (CZP) | Zespół ekspertów, powołany przy DG TAXUD, składający się z informatyków i specjalistów ds. proceduralno-prawnych, wywodzących się z DG TAXUD i firm zewnętrznych, kierujący pracami nad wdrożeniem systemu NCTS we wszystkich państwach uczestniczących w projekcie komputeryzacji tranzytu. CZP podejmuje wszystkie kluczowe decyzje, ustala plany i nadzoruje ich prawidłową realizację |
Termin | Definicja |
Dni Robocze | Dni od poniedziałku do piątku, oprócz świąt oraz dni ustawowo wolnych od pracy |
Godziny Robocze | Godziny od 8.00 do 16.00, przypadające w Dniach Roboczych |
KP Wykonawcy | Kierownik Projektu Wykonawcy |
KP Zamawiającego | Kierownik Projektu Zamawiającego |
Merytoryczne Centrum Kompetencyjne NCTS | 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ą). |
Zarządzania Realizacja Przedmiotu Umowy ZRPU | Dokument o charakterze zarządczym, szczegółowo określający mechanizmy zarządzania i prowadzenia Zamówienia, w tym procedury i sposoby realizacji zadań i czynności projektowych, a także relacje między Zamawiającym a Wykonawcą w trakcie trwania realizacji Zamówienia. |
Produkt | Opracowane, wytworzone i dostarczone przez Wykonawcę oprogramowanie środowska systemu NCTS i dokumentacja wymieniona w umowie . |
Projekt | Jeżeli jednoznacznie nie wymieniono innego projektu, chodzi o projekt NCTS. |
Ryzyko | Zdarzenie lub sytuacja określone jako możliwe do wystąpienia w terminie późniejszym., którego skutki mogą mieć wpływ na przebieg projektu. |
SP Wykonawcy | Sekretarz Projektu Wykonawcy |
System | Tutaj system NCTS |
Umowa zawarta pomiędzy Zamawiającym i Wykonawcą obejmujaca zaprojektowanie, zbudowanie, uruchomienie, testowanie, wdrożenie i gwarantowanie prawidłowego funkcjonowania wszystkich środowisk systemu NCTS | |
Wdrożenie | Zespół czynności niezbędnych dio uruchomienia systemu NCTS w placówkach na terenie kraju. |
Wniosek Zmiany | Dokument o ustalonym sformalizowanym wzorze, służący do zgłaszania i zatwierdzania zmian do zakresu lub przedmiotu projektu. Podpisanie Wniosku Zmian przez upoważnionych przedstawicieli obu stron umowy stanowi podstawę wdrożenia zmiany. |
Wykonawca | XXX.xxx S.A. |
Zamawiający | Skarb Państwa, Ministerstwo Finansów |
Zespół Projektowy Zamawiającego | Zespół pracowników Zamawiającego działający w strukturze Ministerstwa Finansów. |
Zespół Projektowy Wykonawcy | Zespół pracowników Wykonawcy oddelegowany do pracy przy niniejszym projekcie. |
Cel dokumentu Zarządzanie Realizacją Przedmiotu Umowy
ZRPU stanowi dokument o charakterze zarządczym, szczegółowo określający mechanizmy zarządzania i prowadzenia Zamówienia, w tym procedury i sposoby realizacji zadań i czynności projektowych, a także relacje między Zamawiającym a Wykonawcą w trakcie trwania Umowy w celu zapewnienia właściwego poziomu jakości działań i czynności projektowych, które mają w efekcie doprowadzić do wytworzenia produktów spełniających kryteria jakości określone w SIWZ i w Umowie. Celami ZRPU są:
ustalenie pomiędzy Zamawiającym i Wykonawcą jednolitego sposobu rozumienia i przestrzegania zasad współpracy i reguł zarządzania projektem (cel główny),
określenie roli i zakresów odpowiedzialności umożliwiających efektywną realizację zadań w obliczu złożoności projektu i towarzyszących mu zagrożeń,
ustalenie sposobów identyfikacji i raportowania o wystąpieniu problemów i konieczności wprowadzenia zmian, klarowne zdefiniowanie trybu prowadzenia przeglądów, audytów, metod pomiaru postępu prac oraz zakresów
odpowiedzialności ,
dostarczenie organowi zajmującemu się utrzymaniem jakości informacji, które pozwolą mu zorganizować działania z zakresu zapewnienia i kontroli jakości obejmujące przepływ informacji, działania weryfikacyjne, itd.,
zaznajomienie wszystkich uczestników projektu z procedurami, zasadami i właściwymi metodami stosowanymi w trakcie projektu.
Zastosowanie
Dokument ma zastosowanie w czasie trwania projektu oraz w okresie obsługi gwarancyjnej.
.
Procedury zarządzania projektem
W trakcie realizacji projektu, przez cały czas jego trwania będą obowiązywały następujące procedury, określające wzajemną współpracę Zamawiającego i Wykonawcy:
Procedura spotkań roboczych,
Pomiar i monitorowanie postępu prac,
Procedura zarządzania problemami wraz z eskalacją problemów, Procedura zarządzania konfiguracja,
Procedura zarządzania zmianą
Procedury akceptacji i odbioru produktów (określone w umowie), Procedura kontroli jakości,
Procedura zarządzania ryzykiem.
Standardy komunikacyjne
Zasady porozumiewania się stron
Językiem komunikacji w mowie i piśmie w zakresie realizacji niniejszego zamówienia będzie język polski. W sytuacji, gdy zamówienie będą realizować osoby nie posługujące się językiem polskim Wykonawca zapewni tłumaczenie ustne i pisemne na język polski w ramach wartości niniejszej umowy. Dokumentacja projektowa będzie sporządzana w języku polskim, przy czym dopuszcza się język angielski w dokumentacji generowanej automatycznie przy użyciu oprogramowania wspomagającego projektowanie systemów informatycznych oraz w oprogramowaniu COTS. Dokumentacja dotycząca systemu NCTS powstająca i dostarcza przez DG Taxud przy Komisji Europejskiej nie będzie wymagać tłumaczenia.
Niezależnie od postanowień Umowy zobowiązującej do przedstawienia określonych dokumentów w formie pisemnej wszelkie oficjalne zawiadomienia, zapytania lub informacje odnoszące się lub wynikające z wykonywania Umowy, wymagają formy pisemnej.
Pisma Stron zawierać muszą tytuł Umowy i jej numer referencyjny, być oznaczone zgodnie z zasadami oznaczania dokumentacji/pism określonymi w umowie oraz muszą być wysyłane pocztą, pocztą elektroniczną lub doręczone osobiście. Za datę otrzymania korespondencji Strony uznają:
- dzień otrzymania korespondencji pocztą przez adresata (za potwierdzeniem odbioru);
- dzień otrzymania przez nadawcę potwierdzenia otrzymania wiadomości przesłanej pocztą elektroniczną;
- dzień wysłania korespondencji faksem;
- dzień dostarczenia korespondencji osobiście.
Oficjalny kanał komunikacyjny pomiędzy Zespołami odbywa się za pośrednictwem Kierowników Projektu, co nie wyklucza możliwości utrzymywania kontaktów roboczych dotyczących zakresu prowadzonych przez siebie prac przez członków Zespołów Projektowych bez pośrednictwa Kierowników Projektu. Robocza korespondencja powinna być jednak każdorazowo przekazywana do wiadomości Kierownikom Projektu.
Komunikacja elektroniczna
Gdy tylko jest to możliwe, do komunikowania się, tj. przesyłania bieżącej korespondencji projektowej i dokumentacji zarządczej należy wykorzystywać środki elektroniczne, w szczególności pocztę elektroniczną. Produkty projektu muszą byc dostarczane zgodnie z procedurami okreslonymi w Umowie.
Korespondencja przekazywana pocztą elektroniczną pomiędzy Wykonawcą i Zamawiającym będzie adresowana do Kierowników Projektu ze strony Zamawiającego i Wykonawcy na następujące adresy:
Dla Zamawiającego: xxxxx@xxxx-xxxxxxx.xxxxxx.xxx.xx Dla Wykonawcy:
Wymiana korespondencji elektronicznej podlega następującym zasadom:
Temat i treść wiadomości poczty elektronicznej nie są formalnymi dokumentami w projekcie. Dokument sporządzony na odpowiednim formularzu lub w określonym w Umowie formacie wysyłany jest jako załącznik. Treść wiadomości służy do nieformalnej komunikacji pomiędzy uczestnikami projektu.
Nazwy plików będących załącznikami powinny być umieszczone w treści korespondencji. Załączniki większe niż 150 KB powinny być przesyłane w formie skompresowanej.
Procedura spotkań roboczych
Cel
Celem procedury jest zdefiniowanie działań mających na celu organizację, przeprowadzenie oraz podsumowanie spotkań projektowych.
Przedmiot i zakres stosowania
Zakres zastosowania odnosi się do całego czasu trwania projektu. Procedura dotyczy wszystkich spotkań, poza przeglądami postępu prac.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
KP Wykonawcy | Zwołanie i przygotowanie spotkania. Przygotowanie notatki ze spotkania. |
KP Zamawiającego | Zwołanie i przygotowanie spotkania. Akceptacja notatki ze spotkania sporządzonej przez Wykonawcę. |
SP Wykonawcy | Archiwizacja notatek ze spotkań. |
Tryb postępowania
Lp. | Czynność |
1 | Zwołanie spotkania KP Wykonawcy lub Zamawiającego przesyła informację o konieczności odbycia spotkania, podając: temat spotkania, szczegółowe pytania, proponowane terminy spotkań. Informacja powinna być przesłana z wyprzedzeniem 7 dni roboczych. Z uwagi na character prac projektowych i ujawniąjące się potrzeby przeprowadzania uzgodnień roboczych możliwa jest organizacja spotkań ad hoc. |
2 | Organizacja spotkania KP strony otrzymującej propozycję spotkania organizuje właściwych członków zespołu i innych konsultantów w możliwie najkrótszym czasie i najpóźniej w ciągu 2 dni roboczych od dnia otrzymaniu informacji o spotkaniu i uzgadnia z KP drugiej strony termin spotkania. |
3 | Notatka ze spotkania Po spotkaniu w ciągu 2 dni roboczych Wykonawca sporządza notatkę ze spotkania. KP samodzielnie sporządza notatkę bądź wyznacza osobę za to odpowiedzialną. Notatka zgodna jest z szablonem, zamieszczonym w rozdziale 8. Notatka ze spotkania przesyłana jest do KP Zamawiającego. |
4 | Akceptacja notatki ze spotkania W ciągu 2 dni roboczych od dnia otrzymania notatki KP Zamawiającego akceptuje ją lub przekazuje Wykonawcy listę uwag. KP Zamawiającego może wyznaczyć osoby odpowiedzialne za zaopiniowanie notatki. Brak uwag w terminie 2 dni roboczych od otrzymania notatki oznacza akceptację notatki. |
5 | Korekta notatki Po otrzymaniu listy uwag Wykonawca wnosi poprawki do notatki i odsyła ją ponownie do akceptacji. |
6 | Archiwizacja notatki |
Lp. | Czynność |
Zaakceptowana notatka wprowadzona zostaje do archiwum. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Notatka ze spotkania | Sekretarz Projektu Wykonawcy | Archiwum projektu | 3 lata |
Pomiar i monitorowanie postępu prac
Przegląd postępu prac
Cel
Celem procedury jest określenie mechanizmów informowania o stanie realizacji prac projektowych. Opisano środki, przy użyciu których Kierownik Projektu Wykonawcy przekazuje uczestnikom projektu informacje o postępie prac.
Przedmiot i zakres stosowania
Czynności wynikające z tej procedury są stosowane przez cały czas realizacji projektu. Przedmiotem procedury są działania kontrolne podejmowane w trakcie projektu, umożliwiające śledzenie postępu prac oraz wykrywanie niezgodności z ustalonym trybem postępowania, a także niezgodności ze specyfikacjami technicznymi stanowiącymi wymagania projektowe.
Lista dokumentów przeznaczonych do śledzenia lub kontroli postępu prac
Raporty Postępu Prac (RPP). Harmonogram realizacji projektu.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Tworzenie raportu z postępu prac dla Kierownika Projektu Zamawiającego. Sporządzenie notatki ze spotkania postępu prac (SPP). |
Kierownik Projektu Zamawiającego | Jest odpowiedzialny za zwołanie spotkania postępu prac. |
Tryb postępowania
Lp. | Czynność |
1 | Ustalone dla projektu podstawowe środki i informowania o postępach prac Raport z postępu prac – Wzór Nr. 28. |
2 | Częstotliwość tworzenia raportów z postępu prac Przed SPP Wykonawca przygotowuje zbiorczy RPP obejmujący cały okres między spotkaniami. Na zakończenie projektu jako załącznik do Protokołu Odbioru Końcowego Wykonawca przygotuje zbiorczy RPP dla całego projektu. |
3 | Termin spotkań postępu prac Ustalają dwustronnie Kierownicy Projektów, przy czym inicjatywa zwoływania SPP przysługuje Kierownikowi Projektu Zamawiającego. SPP odbywać się będą nie rzadziej niż raz w miesiącu. |
4 | Sposób zwoływania spotkań postępu prac oraz przygotowanie „Raportu z postępu prac” i termin jego dostarczenia Na cztery dni robocze przed SPP KP Zamawiającego przesyła KP Wykonawcy pisemne zaproszenie na spotkanie postępu prac (SPP). Na 3 dni robocze przed spotkaniem Kierownik Projektu Wykonawcy przesyła Kierownikowi Projektu Zamawiającego „Raport z postępu prac” z niezbędnymi załącznikami oraz proponowaną agendę spotkania. Raport z postępu prac Kierownik Projektu Wykonawcy przekazuje Sekretarzowi Projektu celem wprowadzenia do archiwum. Raport z postępu prac składa się z wypełnionego formularza (wg wzoru podanego w szablonie „Raport z postępu prac”) oraz ewentualnych załączników. |
5 | Uczestnicy spotkań postępu prac Spotkania postępu prac prowadzone są przez kierownictwo projektu ze strony Wykonawcy i Zamawiającego. W spotkaniach udział |
bierze: Kierownik Projektu Zamawiającego i Kierownik Projektu Wykonawcy. Ewentualnie, jeśli jest to potrzebne udział biorą także Kierownicy Jakości Zamawiającego i Wykonawcy oraz dodatkowo eksperci Zamawiającego i Wykonawcy. W spotkaniach udział mogą również brać członkowie Rady Projektu i członkowie zespołów wykonawczych w zależności od tematyki. | |
6 | Przebieg spotkania postępu prac sprawdzenie stanu realizacji zadań projektowych, wg RPP, wyznaczenie nowych zadań do realizacji, ustalenie priorytetów, analiza ryzyka w projekcie, kontrola wykonania planu projektu i jego ewentualna korekta, ustalenie i akceptacja szczegółowego harmonogramu na kolejny okres. |
7 | Dokumentacja ze spotkań Do 2 dni roboczych po zakończeniu SPP, Kierownik Projektu Wykonawcy przesyła do Kierownika Projektu Zamawiającego notatkę ze spotkania do akceptacji ze zaktualizowanym Rejestrem Ryzyk. |
8 | Akceptacja wyników spotkań Brak uwag w ciągu 2 dni roboczych od dostarczenia notatki oznacza jej akceptację. Kierownik Projektu Wykonawcy zaakceptowaną notatkę przekazuje Sekretarzowi projektu celem wprowadzenia do archiwum. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Raport z Postępu Prac | Sekretarz Projektu | archiwum | ✓ 3 lata |
Notatka ze spotkania postępu prac | Sekretarz Projektu | archiwum | 3 lata |
Zarządzanie zagadnieniami projektowymi i eskalacja zagadnień projektowych (problemów)
Cel
Ustalenie właściwego sposobu postępowania w celu rejestracji, wyjaśnienia problemu, ustalenia osoby odpowiedzialnej za wprowadzenie rozwiązania i kontroli wprowadzenia rozwiązania.
Procedura obejmuje także tryb przekazywania problemów na wyższy poziom zarządzania w przypadku, gdy na poziomie Kierowników Projektu problem nie może zostać rozwiązany. Wszystkie formalne uzgodnienia projektowe powinny zapadać pomiędzy Kierownikami Projektu ze strony Zamawiającego i Wykonawcy. W przypadku zaistnienia problemów lub sytuacji, gdy Kierownicy nie mogą dojść do porozumienia, każdy z nich może przekazać sprawę na wyższy poziom zarządzania projektem.
Przedmiot i zakres stosowania
Przedmiotem procedury są czynności wszystkich osób zaangażowanych w prace nad projektem, które mogą potencjalnie występować w roli zgłaszającego problemy, oraz czynności osób odpowiedzialnych za rozwiązywanie tych problemów. Zakres stosowania procedury rozciąga się na cały okres prowadzenia prac projektowych.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Odniesienie się do poszczególnych zgłoszeń problemów. Zorganizowanie sprawnie działającego obiegu dokumentów w sekwencji: zgłoszenie problemu – rejestracja zgłoszenia – rozwiązanie problemu lub jego eskalacja - zamknięcie problemu – rejestracja zamknięcia – powiadomienie zainteresowanych. Zgłoszenie problemu do Dyrektora Projektu. |
Sekretarz Projektu Wykonawcy | Obsługa Rejestru Zgłoszeń w zakresie rejestracji zgłoszeń problemów i utrzymania rejestru. Okresowa kontrola skuteczności działania mechanizmu rejestracji zgłaszanych problemów. |
Wszyscy pracownicy zaangażowani w projekcie po stronie Wykonawcy i Zamawiającego | Zgłaszanie problemów. |
Kierownik Projektu Zamawiającego | Przekazanie problemu do Przewodniczącego Rady Projektu. |
Rola | Odpowiedzialność |
Przewodniczący Rady Projektu | Zwołanie spotkania. Rozstrzygnięcie o dalszych losach zgłoszonego problemu. |
Dyrektor Projektu | Zwołanie spotkania rozstrzygającego problem, przygotowanie i uzgodnienie notatki ze spotkania. |
Tryb postępowania
Lp. | Czynność |
1 | Zgłaszanie problemów i rejestr zgłoszonych problemów Każdy z członków zespołu projektowego (po stronie Wykonawcy i Zamawiającego) zobowiązany jest do zgłaszania zaobserwowanych problemów swemu Kierownikowi Projektu. Kierownik Projektu decyduje o tym, czy zgłoszony problem zostanie potraktowany jako problem wewnętrzny, który można rozwiązać bez potrzeby informowania oficjalnie o problemie drugiej strony projektu. Jeśli uzna, że jest to problem wymagający zgłoszenia wg procedury zarządzania problemami, wówczas wypełnia Formularz Zgłoszenia Problemu (szablon w rozdziale 16). Formularz Zgłoszenia Problemu wysyła do Kierownika Projektu drugiej strony. Rejestr zgłoszonych problemów jest wspólny dla Wykonawcy i Zamawiającego. Administruje nim Sekretarz Projektu Wykonawcy. Każdy nadesłane Zgłoszenie Problemu jest rejestrowane przez Sekretarza Projektu w Rejestrze Zgłoszonych Problemów. Dostęp do rejestru zgłoszonych problemów mają uprawnione osoby, a w szczególności Kierownicy Projektu, Kierownicy Jakości, Sekretarze Projektu. |
2 | Reakcja adresata na zgłoszony problem Kierownik Projektu do 2 dni roboczych od daty otrzymania zgłoszonego problemu zobowiązany jest uzyskać opinię na temat zgłoszonego problemu od Kierownika Jakości, który może wprowadzić do Formularza Zgłoszenia Problemu swoje uwagi. Na przedstawienie opinii Kierownik Jakości ma jeden dzień roboczy, po czym zwraca Formularz Zgłoszenia Problemu Kierownikowi Projektu. Kierownik Projektu od momentu otrzymania opinii od Kierownika Jakości ma 2 dni robocze na określenie rozwiązań problemu. Kierownik Projektu dokonuje oceny wpływu problemu na projekt biorąc pod uwagę informacje o problemie zapisane przez właściciela problemu oraz uwagi Kierownika Jaxxxxx. Istnieją następujące możliwości rozwiązania problemu: Kierownik Projektu uznaje, że problem nie ma żadnego wpływu na losy projektu. W takiej sytuacji Kierownik Projektu zamyka problem. Może on również sformułować sugestie dalszego postępowania w celu rozwiązania problemu. Właścicielem problemu pozostaje zgłaszający. Kierownik Projektu uzna, że problem będzie miał wpływ na bieżący stan prac. W takiej sytuacji przekazuje go do rozwiązania wyznaczonej osobie, która staje się właścicielem problemu lub zostaje sam właścicielem problemu. Kierownik Projektu uznaje, że problem nie ma wpływu na bieżący stan prac, lecz będzie miał wpływ na jego dalszy przebieg. W takiej sytuacji Kixxxxxxx Xrojektu sam zostaje właścicielem problemu. |
3 | Realizacja i wdrożenie rozwiązania problemu Właściciel problemu odpowiada za rozwiązanie problemu aż do jego wdrożenia. Do jednego dnia roboczego po zakończeniu akcji naprawczej informuje swego Kierownika Projektu. Kierownik Projektu odnotowuje na Formularzu Zgłoszenia Problemu fakt jego wdrożenia. Kierownik Projektu informuje o tym Kierownika Projektu strony zgłaszającej problem. Gdy właściciel problemu formułuje rozwiązanie problemu, istnieją następujące możliwości: Wdrożenie rozwiązania problemu leży w zakresie kompetencji właściciela problemu. W takiej sytuacji właściciel odpowiada za wdrożenie rozwiązania problemu. Wdrożenie rozwiązania nie leży w zakresie kompetencji właściciela problemu. W takiej sytuacji zgodnie z procedurą eskalacji problemu jest on przekazywany na wyższy poziom, w szczególnych sytuacjach, za zgodą obu stron rozwiązanie problemu będzie przedmiotem odrębnych ustaleń. |
4 | Kontrola i całkowity czas realizacji zgłoszonych problemów Sekretarz Projektu (strony - adresata problemu) kontroluje okresowo w Rejestrze Zgłoszonych Problemów stan realizacji zgłoszonych problemów. Sekretarz Projektu (strony - adresata problemu) pilnuje, aby zgłoszony problem został rozwiązany w przeciągu czasu nie dłuższego niż 1 tydzień od momentu wprowadzenia zgłoszenia do Rejestru Zgłoszonych Problemów. Problemy nie mające wpływu na bieżący stan mogą być rozwiązywane w czasie nie dłuższym niż dwa tygodnie od momentu ich zgłoszenia. |
5 | Raportowanie o rozwiązaniu zgłoszonych problemów Na 2 dni robocze przed każdym spotkaniem postępu prac Sekretarz Projektu (po obu stronach) przygotowuje raport z rejestru zgłoszeń problemów, na którym są widoczne zgłoszenia nadesłane - nierozwiązane i nadesłane rozwiązane (daty, opisy rozwiązań, odpowiedzialni). Zgłoszone i nierozwiązane problemy są omawiane każdorazowo na spotkaniu postępu prac Patrz Formularz z Raportu Postępu Prac). |
6 | Potwierdzenie rozwiązania problemu Kierownik Jakości strony zgłaszającej problem powinien niezwłocznie po otrzymaniu informacji o rozwiązaniu problemu przekazać Kixxxxxxxxxx Xrojektu - właścicielowi problemu swoje stanowisko: potwierdzenie rozwiązania lub podtrzymanie problemu. Po otrzymaniu potwierdzenia rozwiązania problemu, Kierownik Projektu - właściciel problemu odnotowuje na formularzu zgłoszenia problemu jego zamknięcie. |
7 | Eskalacja problemu Kierownicy Projektu obu stron, w przypadku zaistnienia sytuacji, gdy nie mogą dojść do porozumienia, mogą przekazać sprawę na wyższy poziom zarządzania projektem. Kierownik Projektu Wykonawcy przekazuje ją Dyrektorowi Projektu i do wiadomości Kierownikowi Projektu Zamawiającego, a KP Zamawiającego - Przewodniczącemu Rady Projektu i do wiadomości Kierownikowi Projektu Wykonawcy. |
8 | Otrzymanie informacji o problemie Po otrzymaniu informacji o problemie, Przewodniczący Rady Projektu albo Dyrektor Projektu, może podjąć następujące działania: Zwxxxxx xo podległemu Kierownikowi Projektu wraz z formalnym pismem zawierającym instrukcje postępowania, co kończy sprawę. Pismo musi zostać wystosowane w terminie do 4 dni roboczych od otrzymania informacji o problemie. Rozpocząć postępowanie polubowne z drugą stroną. W tym celu należy wystosować formalne pismo do osoby na odpowiednim szczeblu zarządzania drugiej strony. |
9 | Postępowanie polubowne- zwołanie spotkania Podstawą rozpoczęcia formalnego postępowania układowego jest pismo wzywające do poluvbownego rozwiązania sporu/kontrowersji.. Za zwołanie spotkania odpowiada strona eskalująca problem. Spotkanie należy wyznaczyć w przeciągu 2 tygodni od terminu doręczenia pisma. W spotkaniu mogą uczestniczyć po stronie Wykonawcy: Dyrektor Projektu, Kierownik Projektu i inni upełnomocnieni i kompetentni przedstawiciele Wykonawcy, po stronie Zamawiającego: Rada Projektu, Kierownik Projektu. Każda ze stron ma prawo zaproszenia ekspertów zewnętrznych. Kierownicy Projektu Wykonawcy i Zamawiającego muszą zostać powiadomieni o terminie spotkania na co najmniej 1 tydzień przed spotkaniem. |
10 | Zakończenie formalnego postępowania układowego. Informacje o zakończeniu postępowania polubownego i jego wyniki zapisywane są w postaci protokołu z postępowania i przekazywane nie później niż do 2 dni robocze od zakończenia postępowania Kierownikom Projektu Wykonawcy i Zamawiającego. Wszelkie postanowienia są realizowane przez ich adresatów wg zakresu i terminu określonych w protokole. |
11 | Dalsze kroki eskalacji problemów Jeżeli uzgodnienie rozwiązania jest niemożliwe, dalsze rozmowy prowadzone są pomiędzy prawomocnymi, wyznaczonymi przedstawicielami Kierownictwa Zamawiającego i Zarządu Wykonawcy. W wypadku niemożności osiągnięcia kompromisu wszelkie spory będą rozstrzygane przez Sąd powszechny właściwy dla siedziby Zamawiającego. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Zgłoszenie Zagadnienia Projektowego | Sekretarz Projektu | Archiwum projektu | ✓ 3 lata |
Rejestr Zagadnień Projektowych | Sekretarz Projektu | Archiwum projektu | 3 lata |
Pismo opisujące problem, stanowiące podstawę rozpoczęcia postępowania polubownego | Sekretarz projektu Wykonawcy | Archiwum projektu | 3 lata |
Protokół ze spotkania polubownego dotyczącego o | Sekretarz projektu Wykonawcy | Archiwum projektu | 3 lata |
Zarządzanie konfiguracją
Określenie elementów konfiguracji
Zarządzaniu konfiguracją podlegają wszystkie produkty związane z opracowaniem systemu, wytworzone lub dostarczone w ramach projektu.
Elementami podlegającymi kontroli konfiguracji są:
oprogramowanie narzędziowe, bazy danych,
oprogramowanie produkowane, oprogramowanie pomocnicze (w tym COTS),
dokumentacja analityczna, techniczna i użytkowa powstająca w trakcie realizacji projektu, plany instalacji, wdrożenia, testów,
scenariusze testowe,
sprzęt wykorzystywany do testów,
sprzęt instalowany w centrum i lokalizacjach pilotowych wszelka dokumentacja zarządcza i korespondencja.
Zasady oznaczania elementów konfiguracji
Każdy element składowy konfiguracji systemu musi być jednoznacznie określony przez jego identyfikację oraz określenie jego wersji:
1. akronim, jednoznacznie identyfikujący element konfiguracji (obowiązkowo), numer wersji (obowiązkowo) - jedna cyfra,
numer rewizji (obowiązkowo) - kropka - dwie cyfry,
data ostatniej modyfikacji (opcjonalnie) - format rrrrmmdd (bez kropek) opis (opcjonalnie) - [opis]
Przykład: NCTS_ZPU_2.01_20100229_opis
Kontrola konfiguracji
Cel, przedmiot i zakres zastosowania
Ustalenie zasad postępowania przy tworzeniu, oznaczaniu i zmianach konfiguracji komponentów oprogramowania, dokumentacji projektowej oraz sprzętu. Zakres stosowania procedury odnosi się do całego okresu prac projektowych.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Ustalenie bazowej zawartości „Rejestru Konfiguracji“ w ciągu pierwszego miesiąca trwania projektu. Utrzymanie rejestru kontroli konfiguracji. |
Kierownik Projektu Zamawiającego | Kontrola „Rejestru Konfiguracji “. Kontrola realizacji procedury kontroli konfiguracji. |
Sekretarz Projektu Wykonawcy | Wprowadzanie nowego elementu do Rejestru Konfiguracji. Dbałość o prawidłowe funkcjonowanie systemu kontroli wersji oraz administrowanie plikami i dokumentami. |
Tryb postępowania
Lp. | Czynność |
1 | Zgłoszenie nowych produktów do objęcia kontrolą konfiguracji W Rejestrze Konfiguracji będą umieszczane wszystkie produkty projektowe objęte kontrolą wersji. Wszystkie produkty należy umieszczać w rejestrze w terminie 3 dni od objęcia produktu kontrolą wersji, czyli po zakończeniu etapu wytwarzania. Dopisanie nowego produktu powinno nastąpić nie później niż 1 dzień roboczy po zgłoszeniu do rejestru. |
2 | Aktualizacja rejestru kontroli konfiguracji Kierownik Projektu Wykonawcy na podstawie posiadanych informacji o zmianie wersji produktu lub zmianach jego konfiguracji wprowadza zmiany w Rejestrze Konfiguracji w ciągu 1 dnia roboczego od zmiany. |
3 | Kontrola Przynajmniej raz w trakcie trwania projektu projektu Rejestr Konfiguracji jest kontrolowany przez Kierownika Projektu Zamawiającego pod względem zawartości merytorycznej. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Rejestr Konfiguracji Karta Kontroli Wersji | Sekretarz Projektu | Archiwum Projektu | 3 lata |
Rejestr Konfiguracji
Rejestr ten jest tworzony na początku projektu i zawiera zestaw bazowy elementów konfiguracji wraz z ich początkowymi wersjami:
Akronim lub nazwę elementu konfiguracji (produkt). Bieżący numer wersji i rewizji.
Status produktu.
Datę ostatniej modyfikacji.
Kontrola wersji
Kontroli wersji podlega dokumentacja zarządcza, projektowa i oprogramowanie wytworzone w ramach projektu.
Cel, przedmiot i zakres stosowania
Ustalenie zasad postępowania przy tworzeniu, oznaczaniu i zmianach wersji dokumentacji zarządczej, projektowej i oprogramowania. Procedurę stosuje się podczas całego okresu trwania projektu.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Nadzór nad realizacją procedury wersjonowania produktów. |
Kierownik Projektu Zamawiającego | Kontrola realizacji procedury wersjonowania produktów. |
Sekretarz Projektu Wykonawcy | Założenie i utrzymanie Repozytorium Produktów. Wprowadzanie nowego produktu do Repozytorium Produktów. Objęcie produktu kontrolą wersji. Prawidłowe funkcjonowanie systemu kontroli wersji oraz administrowanie plikami i dokumentami. |
Lider zespołu | Zgłaszanie zmiany wersji lub rewizji produktu. |
Tryb postępowania
Lp. | Czynność |
1 | Objęcie dokumentu/produktu kontrolą wersji Dokumenty/produkty, sporządzane/wytwarzane w trakcie realizacji projektu są zgłaszane Kierownikowi Projektu Wykonawcy do objęcia kontrolą wersji przed pierwszym przedstawieniem ich Zamawiającemu. Każdy produkt posiada indywidualną „kartę kontroli wersji” i jest wprowadzony do narzędzia kontroli wersji. |
2 | Produkty dostarczane Nie podlegają wersjonowaniu w ramach projektu. Każdy produkt standardowy ma własną wersję nadaną przez producenta. Dla każdego produktu należy założyć kartę kontroli wersji. |
3 | Raport historii zmian produktu „Raport historii zmian produktu“ jest dostępny do czytania w formie elektronicznej dla wszystkich uczestników projektu. |
4 | Standaryzacja kontroli wersji Kontrola wersji jest prowadzona w formie elektronicznej. |
5 | Zmiany Każde udostępnienie produktu w dowolnym stadium do przeglądu wewnętrznego lub przeglądu realizowanego u Zamawiającego powoduje inkrementację numeru rewizji. Produkt przekazywany do akceptacji uzyskuje numer wersji aktualnej + 1, po czym w przypadku konieczności dokonania poprawek po ich wykonaniu każdorazowo, inkrementowane są numery rewizji. Odrzucenie produktu w całości powoduje inkrementację numeru wersji. Produkty zawierające elementy składowe wersjonowane są wg takich samych zasad jak elementy jednorodne z tym, że zmiana dowolnego elementu składowego zmienia numer wersji lub rewizji produktu. Kierownik Zespołu Realizacyjnego Wykonawcy informuje Kierownika Projektu Wykonawcy o pojawieniu się nowej wersji dokumentu/produktu. Kierownik Projektu Wykonawcy jest odpowiedzialny za naniesienie zmian w „Karcie Kontroli Wersji” dokumentu/produktu w ciągu 1 dnia roboczego od zgłoszenia. Zmiana wersji produktu znajdującego się w Rejestrze Konfiguracji uruchamia aktualizację Rejestru Konfiguracji. |
6 | Kontrola Przynajmniej raz w okresie trwania projektu projektu „Karty Kontroli Wersji” są kontrolowane przez Kierownika Projektu ze Strony Zamawiającego pod względem zawartości merytorycznej i prawidłowości działania. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
„Karta kontroli wersji” | Sekretarz projektu | Archiwum projektu | ✓ 3 lata |
Kontrola jakości
Rozdział prezentuje metody sprawdzania zgodności dostarczonych rozwiązań z wymaganiami jakościowymi dla danego elementu pracy, a także kontroli przestrzegania procedur określonych w ZRPU przez członków obu zespołów projektowych. Na działania kontrolne składają się:
audyty, przeglądy
działania korygujące
kontrola dokumentacji jakości
Audyty
Cel
Audyty przeprowadzane są w celu sprawdzenia czy realizowane w projekcie zadania w zakresie opisanym w planie projektu i ich wyniki są zgodne z planowanymi oraz w celu ustalenia efektywności przeprowadzonych działań.
Audyty planowane planuje okresowo, w zależności od sytuacji i ważności działań, Kierownik Jakości ze strony Wykonawcy, w porozumieniu z Kierownikiem Jakości ze strony Zamawiającego.
Zamawiający ma prawo przeprowadzenia audytu u Wykonawcy w dowolnym terminie (jako Audyt na żądanie) z zachowaniem trybu uzgodnienia z Wykonawcą terminu Audytu, z wyprzedzeniem co najmniej pięciu dni roboczych.
Kierownicy Jakości reprezentujący stronę Wykonawcy i Zamawiającego są odpowiedzialni również za wykonanie i udokumentowanie audytów oraz skuteczne rozesłanie zapisów pokontrolnych do Kierownika Projektu ze strony Wykonawcy i Zamawiającego.
Zapisy z przeprowadzonych audytów wskazują kwestie formalne (data, osoba audytowana, audytor, miejsce) oraz merytoryczne dotyczące omówionych podczas audytu spraw projektowych, obejrzanych dowodów audytowych oraz zauważone problemy (błędy i niedopatrzenia) z rekomendacją dotyczącą ich rozwiązania i wskazaniem terminów usunięcia. Następstwem przeprowadzanych audytów są działania korygujące.
Przedmiot i zakres stosowania
Czynności audytorskie stosują się do całego projektu mogą być prowadzone w każdej chwili od rozpoczęcia przez Wykonawcę realizacji projektu.
Wykonawca ma obowiązek przechowywać dokumentację związaną z wykonaniem Umowy przez okres 3 lat w sposób gwarantujący należyte bezpieczeństwo i zachowanie rzetelności informacji.
.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Audytor | Przygotowanie, przeprowadzenie audytu i wykonanie zapisów pokontrolnych z audytu jakości projektu. |
Dyrektor Projektu | Zatwierdzenie planu realizacji audytów. Adresat raportu z realizacji audytu. |
Kierownik Projektu strony, której audyt dotyczy | Poinformowanie personelu projektu o celach i zakresie audytu. Wyznaczenie przewodnika dla audytora. Zapewnienie audytorowi dostępu do dokumentacji i pracowników (dowodów obiektywnych). Współpracę z audytorem. Ustalenie i realizację działań korygujących. |
Tryb postępowania
Lp. | Czynność |
✓ 1 | Terminy audytów Zamawiający przeprowadza audyty planowane oraz ma prawo przeprowadzenia audytu na żądanie. |
✓ 2 | Zapowiedzenie audytu Zamawiający zapowiada Wykonawcy przeprowadzenie audytu na 5 dni roboczych przed przystąpieniem do jego realizacji. |
✓ 3 | Informacja o zakresie audytu Zamawiający, w tym samym czasie, kiedy zostaje wystosowane powiadomienie o przeprowadzeniu audytu, przekazuje Wykonawcy szczegółowy zakres przeprowadzenia audytu. |
✓ 4 | Przebieg audytu – raport z audytu Po zakończeniu audytu komisja audytorska Zamawiającego przygotowuje raport z audytu, który podpisany przez członków komisji, do 5 dni roboczych po zakończeniu audytu, przekazuje Kixxxxxxxxxx Xrojektu Wykonawcy. |
✓ 5 | Uwagi do raportu z audytu Kierownik Projektu Wykonawcy w ciągu 2 dni roboczych od otrzymania raportu z audytu może wnieść uwagi do niego na ręce komisji audytorskiej Zamawiającego poprzez Audytora. |
✓ 6 | Terminy realizacji zaleceń Audytor wraz z Kierownikiem Projektu Wykonawcy ustalają nieprzekraczalne terminy realizacji poszczególnych zaleceń i zapisują je w raporcie z audytu. |
✓ 7 | Ustalenia dotyczące kontroli realizacji zaleceń Komisja audytorska zapisuje w raporcie z audytu priorytety realizacyjne zaleceń oraz termin i formę sprawdzenia ich realizacji. |
✓ 8 | Akceptacja raportu z audytu Kierownik Projektu Wykonawcy, po uzgodnieniu z Audytorem wszelkich kwestii spornych oraz wyjaśnieniu zaleceń i uzgodnieniu terminów, akceptuje raport z audytu poprzez złożenie podpisu na nim. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Raport z audytu | Sekretarz projektu | Archiwum projektu | 3 lata |
Przeglądy
Każdy przegląd należy ściśle zdefiniować z określeniem przedmiotu, miejsca przeprowadzania, uczestników i ich zadań oraz produktów i dokumentacji przeglądu.
Przeglądy kontrolne produktów, spotkania techniczne i analityczne
Przeglądy techniczne i analityczne organizowane są zgodnie z procedurą spotkań określoną w Rozdziale 2.3.
Przeglądy produktów
Przeglądy produktów odbywają się w ramach procedur akceptacji i odbioru prac opisane w umowie.
Wdrażanie i śledzenie działań naprawczych
Cel
W przypadku wystąpienia odchyleń od wymagań jakości będą podejmowane działania mające na celu: analizę przyczyn niezgodności,
wyeliminowanie przyczyn ponownego wystąpienia odchyleń, usunięcie skutków odchylenia,
monitorowanie skuteczności działań korekcyjnych.
Celem procedury jest przedstawienie sposobu rejestrowania niezgodności oraz nadzorowania realizacji działań naprawczych.
Zakres stosowania
Procedurę stosuje się przez cały czas trwania umowy.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Zamawiającego i Wykonawcy | Analizy wyników procedur lub dostępnych danych celem ujawnienia odchyleń od przyjętych w projekcie norm jakościowych. |
Audytor | Sporządzenie raportu niezgodności. |
Dowolny uczestnik projektu | Zwrócenie uwagi na niezgodności. |
Kierownik Jakości Wykonawcy i Zamawiającego | Monitorowanie i kontrola wyników działań naprawczych. Sporządzenie listy niezgodności i przyjętych rozwiązań. Egzekwowanie i kontrola wykonania poprawek i działań naprawczych. |
Tryb postępowania
Lp. | Czynność |
1. | Rejestracja odstępstw i niezgodności wobec standardów jakości Wszyscy uczestnicy projektu winni zgłaszać Kierownikom Jakości Projektu zauważone odchylenia lub propozycje usprawnień. Do systematycznej rejestracji odstępstw i niezgodności wykorzystywane są mechanizmy procedur opisanych w Planie Jakości Projektu: w zakresie wykrywania formalnych niezgodności prowadzenia projektu – procedura audytu, w zakresie wykrywania merytorycznych niezgodności prowadzenia projektu – przeglądy, SPP, spotkania, w zakresie wykrywania niezgodności ze specyfikacją – przeglądy produktów, procedury testów, weryfikacje i oceny wykonywanych usług, w zakresie obsługi zgłaszanych problemów w projekcie – procedura zarządzania problemami. |
2. | Ustalanie przyczyn niezgodności produktu i określenie działania naprawczego, w celu zapobieżenia dalszym rozbieżnościom Kierownik Jakości Zamawiającego i Wykonawcy, w miarę możliwości, ustalają przyczyny niezgodności na podstawie analizy kryteriów jakościowych, zarejestrowanych odstępstw oraz analizy działania procedur, według których postępowania powstały odstępstwa, analizy wszystkich procesów, działań operacyjnych, dokumentacji jakości i reklamacji zgłaszanych przez użytkowników produktów. |
3. | Inicjowanie działań zapobiegawczych służących eliminowaniu problemów Na podstawie wyników analizy, Kierownicy Jakości w porozumieniu ze sobą i Kierownikami Projektu Zamawiającego i Wykonawcy proponują usprawnienia mechanizmów kontrolnych, procedur, ulepszenie kryteriów jakości. |
4. | Sporządzenie listy niezgodności, na podstawie zebranych niezgodności Po zaakceptowaniu propozycji działań zapobiegawczych, Kierownicy Jakości wspólnie ustalają listę niezgodności oraz przyjęte rozwiązania ich usunięcia i zapobieżenia powstawania w przyszłości. Lista ta między innymi zawierają docelową datę usunięcia niezgodności i datę i miejsce wprowadzenia działań zapobiegawczych i odpowiedzialności. |
5. | Stosowanie działań kontrolnych zapewniających skuteczność działań naprawczych Wyznaczone osoby odpowiedzialne za wprowadzenie działań zapobiegawczych realizują wyznaczone zadania. Kierownicy Jakości Zamawiającego i Wykonawcy sprawują nadzór okresowy lub ciągły nad wprowadzaniem ulepszeń oraz usuwaniem niezgodności. Nadzór ten realizują poprzez monitorowanie działań naprawczych oraz weryfikację wykonania w terminie zaleconych poprawek, a następnie przez obserwację działania procedur projektowych mających wpływ na zachowanie się systemu jakości. |
6. | Wdrożenie i zarejestrowanie zmian proceduralnych będących wynikiem działań naprawczych |
Lp. | Czynność |
W miarę potrzeb działania naprawcze odnoszące się do zmian procedur są wprowadzane przez Kierownika Jakości Zamawiającego i Wykonawcy do Planu Jakości Projektu. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Umowa - Wymagania jakościowe i kryteria jakości wyspecyfikowane w Umowie. | Sekretarz projektu | Archiwum projektu | 3 lata |
Kontrola dokumentacji jakości
Odpowiedzialności
Odpowiedzialnym za utrzymanie archiwum dokumentacji jakości jest Sekretarz Projektu Wykonawcy.
Odpowiedzialnym za utrzymanie spójności i weryfikację stanu archiwum oraz wszystkich dokumentów i zapisów jakości jest Kierownik Projektu Wykonawcy.
Cel utrzymania archiwum dokumentacji jakości
Obsługa dokumentacji jakości w projekcie umożliwia wykazanie zgodności przebiegu projektu z ustalonymi wymaganiami jakościowymi, zapewnienie przez to skuteczności funkcjonowania systemu jakości i osiągnięcia wymaganego poziomu jakości.
Dokumentacja jakości będzie zawierać dokumenty stwierdzające przestrzeganie przez Wykonawcę wymogów jakości. Dokumenty związane z działaniami utrzymania i zapewnienia jakości są przechowywane w archiwum projektowym w sposób umożliwiający ich szybkie wyszukiwanie. Dokumentacja ta może być udostępniana Zamawiającemu w celu przeprowadzenia oceny (np. podczas realizowanych przez Zamawiającego audytów).
Wykonawca prowadzi rejestr dokumentacji jakości oraz zapisów dotyczących utrzymania jakości.
Rejestr ten będzie na tyle szczegółowy, aby można na jego podstawie dokonać śledzenia czynności w celu wykazania:
właściwego poziomu szczegółowości i częstotliwości przeglądów, zgodności z przepisami prawa i spójności z warunkami umowy, zgodności z wymaganiami ZPU,
zgodności z procedurami zarządczymi prowadzenia projektu.
Dokumentacja zapisów jakości jest w archiwum oznaczana i opisywana w następujący sposób:
1. Miejsce powstania zapisu oraz autor zapisu, Data wprowadzenia do archiwum,
Lokalizacja w archiwum, Kto dokonał archiwizacji,
Czas przechowywania w archiwum.
Zawartość archiwum
Archiwum dokumentacji jakości zawiera między innymi następujące informacje:
1. Zapisy dokumentujące wyniki przeglądów jakości ustalonych w ZPU, (przeglądy produktów, spotkania postępu i robocze, w tym techniczne, analityczne, itd.).
Zapisy dokumentujące realizację działań naprawczych w celu usunięcia skutków ryzyk, których wystąpienia nie udało się uniknąć.
Dokumentacja wykrytych niezgodności i podejmowanych działań korygujących. Wyniki formalnych przeglądów produktów.
Dokumenty z akceptacji i odbioru produktów. Raporty z testów.
Zarządzanie archiwum
Obsługa, składowanie danych i archiwizacja
Archiwum i procedury archiwizacji
Archiwum Projektu zostanie założone w pomieszczeniach Wykonawcy w przeciągu tygodnia od podpisania umowy. Archiwum projektu, znajdujące się w pomieszczeniach Wykonawcy, zawiera: bieżące wersje prac w toku, dostarczone i zaakceptowane produkty, protokoły wszystkich formalnych posiedzeń pomiędzy Wykonawcą i Zamawiającym, protokoły kontroli jakości.
Produkty dokumentowe objęte umową przechowywane są zarówno w postaci papierowej jak i elektronicznej (na nośnikach magnetycznych lub optycznych).
Stworzone oprogramowanie przechowywane jest w postaci elektronicznej, natomiast dokumentacja projektowa oraz dane, scenariusze i dokumentacja testowa przechowywane są w postaci papierowej i elektronicznej.
Nowe elementy zapisywane są codziennie na serwerze archiwizacyjnym, na nośniku magnetycznym. W przypadku zakończenia tworzenia nowego produktu, tworzone są dwie kopie na nośniku optycznym. Jedna kopia optyczna pozostaje w Archiwum Projektu, pod kontrolą Kierownika Jakości Wykonawcy, a druga kopia przesyłana jest do Archiwum, które znajduje się w pomieszczeniach Zamawiającego pod kontrolą Kierownika Projektu Zamawiającego.
Kierownik Jakości Wykonawcy okresowo kontroluje Archiwum, aby zapewnić, że w Archiwum przechowywane są najnowsze dokumenty i produkty, i że zachowane zostały procedury opisane powyżej. W przypadku odstępstw od ustalonych procedur, Kierownik Jakości informuje Kierownika Projektu Wykonawcy, który podejmuje odpowiednie czynności.
Procedury archiwizacji
Tworzenie i utrzymanie archiwum projektu
Cel
Celem prowadzenia archiwum projektowego jest przechowywanie wszystkich dokumentów w taki sposób, aby zapewnić ich dostępność dla osób zarządzających oraz innych upoważnionych, a przez to umożliwienie wiarygodnego odtwarzania przebiegu zdarzeń oraz utrzymanie kontroli nad realizowanymi pracami.
Przedmiot i zakres stosowania
Czynności wynikające z tej procedury są wykonywane przez cały czas realizacji projektu oraz w ustalonym przez strony czasie od jego zakończenia.
Zawartość archiwum projektu
Archiwum projektu prowadzone jest w dwóch formatach:
w formie papierowej,
w formie elektronicznej.
Archiwum projektu prowadzone jest w dwóch formach. Forma podstawowa - „papierowa” - przeznaczona do gromadzenia dokumentów powstałych w oryginalnej postaci na papierze. Wszystkie zatwierdzone wersje dokumentów muszą być przechowywane w archiwum papierowym. Forma archiwum elektronicznego przeznaczona jest do przechowywania oprogramowania, elektronicznych kopii dokumentów papierowych, roboczych kopii dokumentów produkowanych, wszystkich innych dokumentów projektowych.
Archiwum elektroniczne prowadzone będzie na dedykowanym serwerze, który Wykonawca udostępni zdalnie całemu zespołowi projektowemu po stronie Zamawiającego i Wykonawcy.
W archiwum zamieszczane będą wszystkie wersje wszelkiej dokumentacji i oprogramowania najpóźniej jeden dzień po dacie dostawy.
Klasyfikacja dokumentów w archiwum i jego struktura
Rejestr główny
Rejestr główny jest centralnym rejestrem zapewniającym kontrolę przepływu pism i dokumentów - zawiera katalogi tematyczne. W poszczególnych katalogach będą umieszczane dokumenty projektu zgodnie z opisem
poszczególnych katalogów. Poniżej jest opisana struktura katalogów archiwum, jaka będzie stworzona na potrzeby projektu.
Struktura archiwum
W poszczególnych katalogach będą umieszczane dokumenty projektu zgodnie z opisem poszczególnych katalogów. Poniżej jest opisana struktura katalogów archiwum, jaka będzie stworzona na potrzeby projektu.
1. Dokumentacja techniczna
a. Architektura techniczna
b. Specyfikacja funkcjonalna
2. Podręczniki
3. Szkolenia
a. Zewnętrzne
b. Wewnętrzne
i. Użytkowników
a. Programy
b. Materiały
c. Poświadczenia
ii. Administratorów
a. Programy
b. Materiały
c. Poświadczenia
4. Testy
iii. COTS
1. Programy
2. Materiały
3. Poświadczenia i licencje
i. Wewnętrzne
1. Plany
2. Scenariusze
3. Raporty
ii. Krajowe i międzynarodowe
1. Plany
2. Scenariusze
3. Raporty
5. Instalacje
i. Środowisko testowe
ii. Środowisko produkcyjny
iii. Środowisko szkoleniowe
iv. Środowisko deweloperskie
6. Oprogramowanie / Aplikacje (tylko w formie elektronicznej)
7. Zarządzanie
a. ZRPU
b. Spotkania robocze
c. Przeglądy
d. Audyty
e. Problemy
f. Dostawy
g. Odbiory
h. Rejestr konfiguracji
i. Gwarancja
j. Raporty
k. Zarządzanie zmianami
l. Analiza ryzyka
8. Szablony
Dopuszcza się możliwość rozszerzenia struktury archiwum.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Jest odpowiedzialny za nadzór nad archiwum projektu. |
Kierownik Xxxxxxx Wykonawcy | Jest odpowiedzialny za kontrolę archiwum projektu. |
Sekretarz Projektu Wykonawcy | Jest odpowiedzialny za utrzymanie i aktualizację archiwum projektu papierowego i elektronicznego w celu umożliwienia kontroli postępu prac (kontrola terminowości dat granicznych realizacji zadań/osiągnięcia kamieni milowych projektu). |
Tryb postępowania przy tworzeniu, aktualizowaniu archiwum oraz kontroli postępu prac z wykorzystaniem archiwum
Lp. | Czynność |
✓ 1. | Założenie archiwum Kierownik Projektu Wykonawcy przed przystąpieniem do realizacji zadań projektowych ustala archiwa: archiwum dokumentów w postaci papierowej oraz archiwum dokumentów w formie elektronicznej. dla każdego archiwum określa miejsca prowadzenia archiwum i sposoby jego zabezpieczenia. |
✓ 2. | Przechowywanie dokumentów w archiwum Archiwum dokumentów w postaci papierowej znajdować się będzie w siedzibie Wykonawcy. Różne rodzaje dokumentów, przechowywane będą w osobnych segregatorach lub w wydzielonych folderach segregatorów. Elektroniczne archiwum znajdować się będzie na serwerze w siedzibie Wykonawcy. Bieżące wersje dokumentów będą przechowywane w wydzielonym folderze. Po przekazaniu kolejnych wersji dokumentów Sekretarzowi Projektu, nowa wersja zostanie wprowadzona do zarządzanego wewnętrznie systemu kontroli wersji. |
✓ 3. | Zasady funkcjonowania archiwum Do archiwum dokumentów papierowych wprowadzane są dokumenty, które zostały przesłane do Kierownika Projektu Wykonawcy oraz inne, których Kierownik Projektu bezpośrednio nie otrzymuje. Kierownik Projektu Wykonawcy ma obowiązek przekazać kopię każdego otrzymanego od Zamawiającego dokumentu Sekretarzowi Projektu. Dokument papierowy adresowany do innej osoby niż do Kierownika Projektu Wykonawcy, adresat ma obowiązek przekazać Sekretarzowi Projektu, a kopię dokumentu przekazać Kierownikowi Projektu Wykonawcy. Autor dokumentu, który powstał u Wykonawcy w ramach projektu i został przez Zamawiającego zatwierdzony ma obowiązek przekazać go Sekretarzowi Projektu. Sekretarz Projektu powinien otrzymywać kopie wszelkiej dokumentacji przychodzącej od Zamawiającego do Wykonawcy celem archiwizacji. Każdy otrzymany dokument Sekretarz Projektu umieszcza w archiwum papierowym w odpowiedniej dla niego sekcji. |
✓ 4. | Przyjęta zasada aktualności dokumentów W przypadku dokumentów elektronicznych za aktualną uznaje się wersję wskazaną przez narzędzie kontroli wersji i posiadającą najwyższy numer referencyjny. W przypadku dokumentów, których oryginały są w postaci papierowej za wersję aktualną uznaje się dokument z najmłodszą datą. |
✓ 5. | Zasady przechowywania i wykorzystywania szablonów i formularzy dokumentów zarządczych Archiwum zawiera w wydzielonej części standardowe szablony i formularze, wzory raportów, przeznaczone do stosowania w projekcie w zakresie określonym w ZPU w rozdziale 8. Dla zgromadzonych szablonów dokumentów jest określona w ZPU, w procedurze obsługi dokumentów zarządczych, metoda kontroli realizacji zadań i/lub ustaleń z tych dokumentów. Każdy uczestnik projektu, konstruując dokument, powinien sprawdzić czy jego szablon jest zdefiniowany w archiwum i jeśli tak, to wykorzystać standardowy szablon. Jeżeli w archiwum nie ma standardu dla dokumentu, wówczas osoba tworząca dokument powiadamia o tym Kierownika Projektu. Kierownik Projektu wraz z Sekretarzem Projektu ustala ewentualny szablon i miejsce przechowywania nowego rodzaju dokumentu w archiwum oraz procedurę jego śledzenia i dokonuje aktualizacji procedury obsługi dokumentów zarządczych. Aktualizacja procedury obsługi dokumentów zarządczych podlega akceptacji Zamawiającego. Po zaakceptowaniu procedury i szablonu przez Zamawiającego, Sekretarz powiadamia o tym uczestników projektu. |
Lp. | Czynność |
✓ 6. | Kontrola stanu projektu z wykorzystaniem archiwum Wszystkie dokumenty przeznaczone do kontroli postępu prac i śledzenia realizacji prac projektowych są przechowywane w archiwum. Sekretarz Projektu Wykonawcy każdorazowo po zaakceptowaniu (kolejnej wersji lub rewizji) dowolnego z wymienionych dokumentów przez Zamawiającego umieszcza go w archiwum, skąd jest on dostępny dla Kierownika Projektu Wykonawcy. Kierownik Projektu Wykonawcy, śledząc postęp prac, ma do dyspozycji w archiwum wszystkie wersje raportów z postępu prac oraz protokołów odbioru prac potwierdzających osiągnięcie kolejnych terminów realizacji zadań/kamieni milowych. |
✓ 7. | Wprowadzanie dokumentów do archiwum Dokument zostaje wprowadzony do archiwum w momencie jego utworzenia i zatwierdzenia przez Xxxxxxxxxxxxx. Wszystkie notatki są umieszczane w archiwum w momencie ich wysłania lub otrzymania. Wszystkie protokoły są gromadzone w archiwum w momencie ich wysłania do Zamawiającego lub otrzymania od Zamawiającego oraz drugi raz - jako protokoły zatwierdzone przez Zamawiającego. Raporty z postępu prac są wprowadzane do archiwum w momencie uzyskania potwierdzenia kompletności dokumentu od Zamawiającego. Proponowane i zatwierdzone Wnioski Zmian są przechowywane w archiwum. Pozostałe dokumenty powstające w projekcie trafiają do archiwum w stanie zatwierdzonym przez Xxxxxxxxxxxxx /Wykonawcę. Dokumenty pomocnicze, które nie podlegają zatwierdzeniu, są gromadzone w archiwum w momencie ich otrzymania. |
Czas przechowywania zapisów w archiwum
Należy przechowywać wszystkie zapisy Archiwum Projektu u Wykonawcy przez 3 lata. Archiwum Projektu będzie również przechowywana przez co najmniej 3 lata Zamawiającego.
Analiza ryzyka
Definicja
Poprzez Ryzyko w projekcie rozumiana jest potencjalna możliwość zaistnienia sytuacji, która może spowodować zagrożenie dla osiągnięcia celów stawianych przed projektem. Ryzyko może mieć bardzo różną naturę i pochodzić zarówno z wewnątrz, np. brak zasobów niezbędnych do powołania Zespołu Realizacyjnego, jak i z zewnątrz projektu, np. zmiany prawnoorganizacyjne.
Ze względu na bardzo dużą złożoność realizowanego projektu o jego sukcesie decyduje wiele różnych czynników. Jedynym sposobem ustrzeżenia się przed negatywnymi sytuacjami jest przewidywanie ich zaistnienia, ocena ich potencjalnego wpływu na projekt oraz prawdopodobieństwa wystąpienia, a następnie określenie sposobu reakcji na ryzyko.
Procedura zarządzania ryzykiem
Celem procedury zarządzania ryzykiem jest określenie zasad identyfikacji, określania wielkości, kontroli i eliminacji, o ile jest to możliwe, zagrożeń mogących stanowić niebezpieczeństwo dla pomyślnego zakończenia projektu.
Zadania związane z zarządzaniem ryzykiem to:
Identyfikacja i klasyfikacja potencjalnych obszarów zagrożenia;
Określenie wielkości zagrożeń, szacunek prawdopodobieństwa ich wystąpienia oraz potencjalne szkody, jakie każde z nich może spowodować;
Przygotowanie planu zarządzania ryzykiem w stosunku do znacznych zagrożeń;
Identyfikacja odpowiedzialności związanej z zarządzaniem ryzykiem w stosunku do każdej kategorii i zagrożenia; Monitorowanie zagrożeń i działań zapobiegawczych;
Inicjacja planów zaradczych tam, gdzie jest to niezbędne; Okresowe ponowne szacowanie ryzyka.
Procedurę stosuje się podczas całego czasu trwania umowy.
Wykaz odpowiedzialności
Rola | Odpowiedzialność |
Kierownik Projektu Wykonawcy | Przedstawienie propozycji ryzyk po stronie wykonawcy, Utrzymanie rejestru ryzyk, Realizacja akcji naprawczych. |
Kierownik Projektu Zamawiającego | Przedstawienie propozycji ryzyk – po stronie Zamawiającego. Uzgodnienie rejestru ryzyk, weryfikacja rejestru ryzyk. Weryfikacja prawidłowości wykonania akcji naprawczych. |
Tryb postępowania
Lp. | Czynność |
✓ 2 | Utworzenie Rejestru Ryzyka. ✓ Po podpisaniu umowy Wykonawca tworzy Rejestr Ryzyka. |
✓ 3 | Zgłaszanie nowych ryzyk ✓ Wszyscy uczestnicy zespołu projektowego mogą zgłaszać nowe ryzyka. ✓ Ryzyka są przekazywane do Kierownika Projektu. Ryzyko należy opisać szczegółowo na formularzu szczegółowym opisu ryzyka. ✓ Decyzja o umieszczeniu w rejestrze ryzyka zapada na najbliższym spotkaniu, na którym przeprowadzana jest analiza ryzyka. |
✓ 4 | Monitorowanie i akceptacja. ✓ Rejestr ryzyka jest przeglądany na spotkaniu, na którym przeprowadzana jest analiza ryzyka. Zawartość rejestru ryzyka jest uzgadniana i akceptowana przez Kierowników Projektu Wykonawcy i Zamawiającego |
✓ 5 | Akcje zapobiegawcze ✓ Akcje zapobiegawcze są ustalane podczas analizy ryzyka.. Akcje naprawcze są zapisywane w szczegółowym opisie ryzyka. Dla każdej akcji zapobiegawczej należy określić osobę odpowiedzialną i termin wykonania. ✓ Uzgodnione akcje zapobiegawcze wchodzą do harmonogramu projektu. ✓ Kontrola wykonania akcji zapobiegawczych odbywa się podczas Spotkań Postępu Prac. |
✓ 6 | Zamknięcie ryzyka. ✓ Xxxxxx zostaje zamknięte podczas analizy ryzyka, jeśli obie strony uzgodnią, że ryzyko nie wystąpi w wyniku akcji zapobiegawczych lub innych okoliczności. |
Zapisy
Nazwa | Odpowiadający za przechowywanie | Miejsce przechowywania | Okres przechowywania |
Rejestr Xxxxxx | Xxxxxxxxx Projektu | Archiwum projektu | ✓ 3 lata |
Szczegółowy Opis Ryzyka. | Sekretarz Projektu | Archiwum projektu | 3 lata |
Spis dokumentów i procedur związanych
Procedura monitorowania postępu prac
Rejestr ryzyka
Rejestr ryzyka jest dokumentem żywym, poddawanym przeglądom zgodnie z procedurami spotkań opisanymi w rozdziale 2.3. Wyniki przeglądów są opisywane w sprawozdaniach ze Spotkań Postępu Prac lub odrębnych spotkań poświęconych Analizie Ryzyka i stanowią część dokumentacji projektowej.
Ryzyko w Rejestrze Xxxxxx opisuje się przy pomocy następujących faktów:
Nazwa i opis ryzyka, Właściciel ryzyka,
Wielkość ryzyka (prawdopodobieństwo wystąpienia x poziom zagrożenia), Częstotliwość przeglądania,
Strategia zapobiegania i plan działań zapobiegawczych.
Nr ryzyka | Nazwa ryzyka | Poziom zagrożenia | Prawdopodobieństw o wystąpienia | Wielkość ryzyka | Właściciel | Kod okresu wystąpienia | Stan |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Karta opisu ryzyka
Numer ryzyka: numer kolejny w rejestrze. Służy do identyfikacji. Nie mówi nic o wadze ryzyka.
Nazwa ryzyka: krótki opis oddający sedno treści ryzyka.
Opis ryzyka: szczegółowy opis ryzyka.
Strategia zapobiegania: Opracowane i uzgodnione przez obie strony zalecenia oraz plany działania, w wymaganym przedziale czasowym, określające dostępne i najbardziej odpowiednie działania zapobiegawcze, mające na celu uniknięcie ryzyka w ogóle bądź robienie wszystkiego, co możliwe i praktyczne, aby zminimalizować prawdopodobieństwo wystąpienia wydarzenia i/lub zredukować wpływ tego wydarzenia.
Właściciel ryzyka: Osoba lub organizacja, po stronie, której leży zapobieganie ryzyku. Odpowiedzialna za wykonanie działań zapobiegających ryzyku w wymaganym czasie.
Status ryzyka: jest istotny, zwłaszcza we wczesnych etapach projektu, aby pomóc w potwierdzeniu priorytetów i potrzeby podejmowania działań zapobiegawczych.
Kod stanu | Opis |
F | Nieaktywny. |
D | Aktywny, ale ograniczony, bez wpływu na koszty i harmonogram. |
A | Aktywny i mający wpływ na koszty i/lub harmonogram. |
C | Zamknięty. |
Poziom zagrożenia: jest miarą tego, czy ryzyko jest „krytyczne”. Podczas wczesnych etapów projektu rzadko bywa dostępna pełna informacja. W miarę jak dalsze informacje stają się osiągalne, poziom zagrożenia może ulec zmianie.
Kod | Wartość | Poziom zagrożenia | Opis |
K | 5 | Krytyczne | Konsekwencje są „krytyczne” dla powodzenia projektu. Krytyczne zagrożenia mogą spowodować zatrzymanie lub znaczne opóźnienie projektu. |
W | 4 | Wysokie | Konsekwencje są „wysokie” dla powodzenia. Zagrożenie może spowodować opóźnienie realizacji projektu. |
S | 3 | Średnie | Nie „krytyczne” ani „wysokie” ale należy ich unikać, może okazać się niezbędny plan akcji zapobiegawczych. |
N | 2 | Niskie | Mało kosztowne zagrożenie o minimalnym wpływie. |
D | 1 | Drobne | Bardzo mało kosztowne zagrożenie o znikomym wpływie. |
Okres wystąpienia: Precyzuje termin wystąpienia ryzyka. Choć zagrożenie może wydać się krytyczne ze względu na jego wielkość, to jego pilność zależy od przewidywanego terminu wystąpienia.- na przykład zagrożenie średnie, które może mieć wpływ na projekt w ciągu kilku tygodni, może okazać się pilniejsze od zagrożenia wysokiego, które może mieć wpływ za 6 miesięcy. Dlatego kod okresu wystąpienia powinien być określany i brany pod uwagę.
Aby uzupełnić tę informację i xxxxxxx określanie priorytetów, przewidywany czas wystąpienia zagrożenia należy rejestrować wg. dat. Należy zwrócić uwagę na przewidywany czas wystąpienia pod kątem działań zapobiegawczych - jeżeli, na przykład, wydarzenie stanowiące zagrożenie ma mieć miejsce za 9 miesięcy, a działanie zapobiegawcze wymaga 12 miesięcy, aby odnieść skutek, to już teraz staje się ono krytyczne.
Kod okresu wystąpienia | Przewidywany czas wystąpienia |
I | W ciągu dwóch tygodni |
II | W ciągu miesiąca |
III | W ciągu 3 miesięcy |
IV | Więcej niż 6 miesięcy |
Prawdopodobieństwo wystąpienia: jest miarą tego, czy ryzyko „wystąpi”. Jest jednym z elementów określania wielkości ryzyka.
Wartość | Prawdopodobieństwo |
5 | Pewne |
4 | Wysokie |
3 | Średnie |
2 | Niskie |
1 | Drobne |
Wielkość ryzyka: = prawdopodobieństwo wystąpienia x poziom zagrożenia. Wynik jest podstawą do określenia częstotliwości przeglądania i terminów podejmowanych działań zapobiegawczych.
Wpływ na harmonogram - Wpływ na czas trwania projektu w przypadku wystąpienia zagrożenia.
Historia ryzyka: lista działań podejmowanych dla ryzyka.
Załącznik nr 5 do umowy nr ... z dnia 2016r.
RAMOWY HARMONOGRAM REALIZOWANYCH ZADAŃ I PLANOWANYCH PŁATNOŚCI
Lp. | Produkty/Usługi | Zakres | Termin realizacji /dostawy | Cena brutto (zł) |
Etap nr I Umowy – 3 miesiące od dnia następnego po dniu podpisania umowy | ||||
1. | Realizacja Usługi wsparcia utrzymania Systemu | Określony w§ 3 Umowy | Przez 3 miesiące od dnia rozpoczęcia realizacji Umowy (czyli od 5 Dnia roboczego po dniu podpisania umowy) | ……………… |
2. | Wprowadzanie zmian do Systemu w ramach Wniosków Zmian wynikających z konieczności ich bieżącej aktualizacji systemu | Określony w§ 4 Umowy | Przez 3 miesiące od dnia rozpoczęcia realizacji Umowy (czyli od 5 Dnia roboczego po dniu podpisania umowy) | …………….. |
3. | Opracowanie koncepcji wraz z dokumentacją umożliwiającej przystosowanie Systemu NCTS do pełnienia roli archiwum oraz wyłączenia i zarchiwizowania systemu z uwzględnieniem prawidłowego przekazania materiałów archiwalnych do Archiwum Państwowego. | Ustalony z Zmawiającym | 2 miesiące od dnia rozpoczęcia realizacji Umowy (czyli od 5 Dnia roboczego po dniu podpisania umowy) | ……………1 |
Etap nr II Umowy – 3 miesiące od dnia następnego po dniu zakończenia Etapu nr I | ||||
4. | Realizacja Usługi wsparcia utrzymania Systemu | Określony w§ 3 Umowy | Przez 3 miesiące od dnia następnego po dniu zakończenia I Etapu Umowy | ………………. |
5. | Wprowadzanie zmian do Systemu w ramach Wniosków Zmian wynikających z konieczności ich bieżącej aktualizacji systemu | Określony w§ 4 Umowy | Przez 3 miesiące od dnia rozpoczęcia realizacji Umowy (czyli od dnia następnego po dniu podpisania umowy) | |
Lp. | Produkty/Usługi | Zakres | Termin realizacji /dostawy | Cena brutto (zł) |
6. | W przypadku podjęcia przez Xxxxxxxxxxxxx decyzji o wdrożeniu koncepcji dostarczonej w Etapie I punkt 3 implementacja mechanizmów opisanych w tej koncepcji | Ustalony z Zmawiającym | Przez 1 miesiąc od dnia następnego po dniu zakończenia I Etapu Umowy |
1 Płatność wyłącznie za zrealizowane Wnioski Zmian
Załącznik nr 6 do umowy nr ... z dnia 2016r.
Zgłoszenie Błędu / Gwarancyjne*
Adresat: .....................................
.....................................
.....................................
Wypełnia Zgłaszający
Klasyfikacja zgłoszenia:.............
Numer zgłoszenia w rejestrze zgłoszeń w jednostce SC.
Dane kontaktowe (tel.,e-mail):................................................................................
Umiejscowienie wady: ...........................................................................................
Numer wersji programu:..........................................................................................
Ścieżka dostępu:....................................................................................................
Opis wady:..............................................................................................................
Rekomendacja do usunięcia w najbliższej łacie programowej (tak/nie*) Data i godzina zgłoszenia wady Wykonawcy:.........................
Podpis:......................
Potwierdzenie usunięcia wady
Data usunięcia wady:.........................
Kierownika Projektu Zgłaszającego (data i podpis):
......................
Kierownika Projektu Wykonawcy (data i podpis):
.....................
* niepotrzebne skreślić
Załącznik nr 7 do umowy nr ... z dnia 2016r.
Zgłoszenie Incydentu/Problemu
Adresat: .....................................
.....................................
.....................................
Wypełnia Zgłaszający
Numer zgłoszenia w rejestrze zgłoszeń w jednostce SC.
Dane kontaktowe (tel.,e-mail):................................................................................
Umiejscowienie incydentu/problemu: ...........................................................................................
Numer wersji programu:..........................................................................................
Ścieżka dostępu:....................................................................................................
Opis incydentu/problemu:.........................................................................................
..................................................................................................................................
Załączniki do zgłoszenia: ............................
Data i godzina zgłoszenia incydentu/problemu Wykonawcy:.........................
Podpis:......................
Wypełnia Kierownik Projektu Wykonawcy
Opis źródła zaistnienia incydentu/problemu: .........................................................................
...............................................................................................................................................
Sposób rozwiązania incydentu/problemu: ............................................................................
...............................................................................................................................................
Potwierdzenie rozwiązania incydentu/problemu
Kierownik Projektu Zamawiającego (data i podpis):
......................
Kierownika Projektu Wykonawcy (data i podpis):
.....................
Załącznik nr 8 do umowy nr ... z dnia 2016r.
Raport z Usługi Wsparcia
Wykonawca: | Zamawiający: |
Raport z Usługi Wsparcia - Etap nr …… | |
(Nazwa Systemu, nr Umowy) | |
Nr Etapu: | |
Dokonujący odbioru: | |
Czas trwania Etapu wg harmonogramu Umowy: | |
Uwagi dotyczące odbioru: | |
Zestawienie wszystkich danych zawartych w Rejestrze Incydentu/Problemów
Lp. | Numer zgłoszenia PSC | Data i godzina zgłoszenia Problemu | Data i godzina usunięcia Problemu |
1. | |||
2. | |||
3. |
Zestawienie wszystkich danych zawartych w Rejestrze Konsultacji
Lp. | Numer zgłoszenia PSC | Data i godzina zgłoszenia Konsultacji | Data i godzina udzielenia Konsultacji |
1. | |||
2. | |||
3. |
Zestawienie wszystkich danych zawartych w Rejestrze Błędów
Lp. | Numer zgłoszenia PSC | Klasa | Data i godzina zgłoszenia błędu | Data i godzina usunięcia błędu |
1. | ||||
2. | ||||
3. |
Zestawienie wszystkich danych zawartych w Rejestrze Zgłoszeń Gwarancyjnych
Lp. | Numer zgłoszenia PSC | Klasa | Data i godzina Zgłoszenia Gwarancyjnego | Data i godzina usunięcia Zgłoszenia Gwarancyjnego |
1. | ||||
2. | ||||
3. |
UWAGI: ...........................................................................................................................................
...........................................................................................................................................................
...........................................................................................................................................................
Funkcja | Podpis | Data |
Xxxxxxxxx Projektu Wykonawcy (imię i nazwisko) | ||
Xxxxxxxxx Projektu Zamawiającego (imię i nazwisko) |
Załącznik nr 9 do umowy nr .. . z dnia 2016r.
Zgłoszenie Zmiany
Wykonawca: | Zamawiający: | |
Zgłoszenie Zmiany nr … | ||
System NCTS Umowa nr …* | ||
Data przekazania | ||
Szczegółowy opis zmiany | ||
Proponowany sposób realizacji | ||
Proponowany termin realizacji | ||
Funkcja | Podpis | Data |
Kierownik Projektu Zamawiającego ** | ||
* Wpisać numer
** Należy podać imię i nazwisko
Załącznik nr 10 do umowy nr .. . z dnia 2016r.
Wniosek Zmiany
Wykonawca: | Zamawiający: |
Wniosek Zmiany Nr ........ | |
System NCTS, Umowa nr ..................... | |
Wypełnia Kierownik Projektu Zamawiającego: |
Opis zmiany: |
Uzasadnienie merytoryczne i prawne: |
Wpływ zmiany na System: |
Wypełnia Kierownik Projektu Zamawiającego w uzgodnieniu z Kierownikiem Projektu Wykonawcy | ||||
Zakres prac do wykonania: | ||||
Zadanie | Opis | Pracochłonnoś | Wartość | Termin |
1. | ||||
2. | ||||
Sumarycznie: | ||||
Funkcja | Podpis | Data |
Kierownik Projektu Zamawiającego * | ||
Kierownik Projektu Wykonawcy* |
* Należy podać imię i nazwisko
Zamawiający: (imię, nazwisko, xxxx, podpis) | Wykonawca: (imię, nazwisko, xxxx, podpis) |
Załącznik nr 11 do umowy nr ... z dnia 2016r
Zespół Realizacyjny Zamawiającego
W skład Zespołu Realizacyjnego Zamawiającego wchodzą następujące osoby :
Lp. | Imię i nazwisko | Xxxx |
Xxxxxxx Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego | ||
Członek Zespołu Realizacyjnego |
Osoby Upoważnione do Podpisywania Dokumentów po stronie Zamawiającego:
1. W zakresie Protokołu Odbioru Pogwarancyjnego:
Pani/Pan ………………………
a w przypadku jego nieobecności:
Pani/Pan ………………………….
2. W zakresie Raportu z Usługi Wsparcia oraz Potwierdzenia Wykonania Usługi Wsparcia:
Pani/Pan ,
a w przypadku jego nieobecności:
Pani/Pan ,
3. W zakresie Protokołów: Dostawy, Akceptacji i Obioru Produktu oraz Zgłoszenia Zmiany:
Pani/Pan ,
a w przypadku jego nieobecności:
Pani/Pan ……………………………………..
4. W zakresie Zgłoszeń Błędu/Gwarancyjnych, Zgłoszeń Incydentu/Problemu, Konsultacji:
Pani/Pan ,
a w przypadku jego nieobecności: Pani/Pan ,
5. W zakresie Wniosków Zmiany:
A. Podpisuje:
Pani/Pan ,
a w przypadku jego nieobecności:
Pani/Pan …………………………..
B. Zatwierdza:
Pani/Pan ;
a w przypadku jej nieobecności:
Pani/Pan …………………………
6. W zakresie Protokołu Odbioru Etapu:
Pani ; a w przypadku jej nieobecności:
Pani/Pan ………………………………………..
* Każda ze Stron Umowy może zmienić osoby upoważnione do podpisywania dokumentów, po uprzednim pisemnym powiadomieniu drugiej ze Stron.
Załącznik nr 12 do umowy nr ... z dnia 2016r.
Protokół Odbioru Produktu
Wykonawca: | Zamawiający: | |
Protokół Odbioru Produktu nr ... | ||
System NCTS, Umowa nr … | ||
Określenie Produktu * | ||
Kategoria wydatku ** | ||
Uwagi dotyczące odbioru | Przedmiot Umowy w zakresie objętym odbiorem został wykonany w terminie / nie został wykonany w terminie *** Zgodnie z Umową wykonanie przedmiotu Umowy objętego niniejszym odbiorem powinno nastąpić do dnia …………. Faktyczne wykonanie przedmiotu Umowy objętego niniejszym odbiorem nastąpiło w dniu ……………… | |
Dokumenty dołączone i odnośne | ||
Funkcja | Podpis | Data |
Kierownik Projektu Zamawiającego **** | ||
Kierownik Projektu Wykonawcy **** | ||
* Należy dodatkowo podać odniesienie do numeru zadania z Załącznika nr 5 lub nr Wniosku Zmiany
** Należy podać kod właściwej kategorii
*** Niepotrzebne skreślić
**** Należy podać imię i nazwisko
Załącznik nr 13 do umowy nr ... z dnia 2016r.
Kryteria jakości dla kodów źródłowych
Strony umowy będą wykonywały wspólne, okresowe przeglądy kodów źródłowych nie rzadziej niż jeden raz w trakcie każdego Etapu umowy. Wynikiem przeglądu będzie raport, w którym strony uzgodnią tryb dalszego postępowania, tj. zidentyfikują elementy wymagające zmiany lub uzupełnienia.
Kryterium odbioru | Warunki spełnienia kryterium odbioru |
Pliki opisujące strukturę dokumentów w formacie XML (tzw. XML Schema) zawarta w specyfikacji technicznej XML. | Bez odstępstw. |
Wszystkie parametry systemu, uzgodnione z Zamawiającym w specyfikacji technicznej, można modyfikować bez konieczności zmiany kodu źródłowego. | Bez odstępstw. |
Opis wszystkich parametrów, uzgodnionych z Zamawiającym znajduje się w specyfikacji technicznej. | Parametry można zmodyfikować bez udziału Wykonawcy |
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 System NCTS komunikuje się, lokalizacji plików wczytywanych i zapisywanych przez System NCTS, nazw własnych (nie będących wewnętrznymi nazwami obiektów programowych) i stałych używanych w Systemie NCTS. | Literały można zmodyfikować bez udziału Wykonawcy. |
Kompilacja dostarczonych przez Wykonawcę kodów źródłowych odbyła się bez błędów w środowisku opisanym przez Wykonawcę. | Kompilacja przeszła bez błędów. |
Pliki uzyskane po kompilacji odpowiadają plikom z wersji zaakceptowanej, pod względem ilości, wielkości, typu i zawartości. | Dopuszczalne różnice wynikające z charakterystyki narzędzia. |
Wszystkie operacje zmieniające zawartość danych w bazach danych będą wykonywane transakcyjnie; w kodzie źródłowym zostanie | Bez odstępstw. |
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, Krótki opis działania, Lista dokonanych zmian (kto, kiedy, co) Opisane są kluczowe instrukcje sterujące – warunki, wyniki, Zachowana jest jednolitość nazw zmiennych, do opisu wykorzystano j. angielski. | Dopuszczalne braki w komentarzach wynikające z zastosowania bibliotek zewnętrznych |
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. | Bez odstępstw |
Kody źródłowe są przekazane w postaci repozytorium źródeł zapewniającego kontrolę wersji. | Bez odstępstw |
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 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. | Bez odstępstw |
Załącznik nr 14 do umowy nr ... z dnia 2016r.
Protokół Akceptacji Produktu
Wykonawca: Zamawiający:
Protokół Akceptacji Produktu nr ...
System NCTS, Umowa nr …, Wniosek Zmiany nr … *
Nr pisma / Protokołu Dostawy
Data dostawy
Miejsce dostawy
Skład Zespołu Akceptacyjnego / Weryfikacyjnego **:
Lp. 1.***
2.
Imię
Nazwisko
Podpis i data
Określenie akceptowanego Produktu:
3.
Status
Data nadania statusu
Akceptacja
Akceptacja z uwagami
Odrzucenie
UWAGI (w przypadku, gdy produkt został zaakceptowany z uwagami albo przyczyny odrzucenia, jeśli został odrzucony)
Załączniki
Funkcja
Kierownik Projektu Zamawiającego
****
Podpis
Data
Kierownik Projektu Wykonawcy ****
* Niepotrzebne skreślić
** Jeśli taki został powołany przez Kierownika Projektu Zamawiającego
*** Przewodniczący Zespołu
**** Należy podać imię i nazwisko