Budowa i wdrożenie systemu informatycznego SODiR 3.0 – Warszawa

Zamawiający ujednolici zapisy SWZ w tym zakresie.

Zamawiający zmieni zapisy SWZ w tym zakresie.

Zamawiający ujednolici zapisy SWZ w tym zakresie.

Zamawiający ujednolici zapisy SWZ w tym zakresie.

Zamawiający ujednolici zapisy SWZ w tym zakresie.

Zamawiający ujednolici zapisy SWZ w tym zakresie.

Zamawiający wyjaśnia, że Analiza wstępna Zmiany stanowi element procedury realizacji Modyfikacji i Rozwoju Systemu SODiR 3.0, a jej zakres został określony w § 4 ust. 15 Projektowanych Postanowień Umowy. Wykonanie Analizy wstępnej jest nieodpłatne, co oznacza, że z tytułu jej sporządzenia Wykonawcy nie przysługuje odrębne wynagrodzenie, a czas przeznaczony na jej przygotowanie nie pomniejsza limitu Roboczogodzin przeznaczonego na realizację Modyfikacji i Rozwoju. Zamawiający nie określa ani nie gwarantuje liczby Analiz wstępnych, które zostaną zlecone w okresie obowiązywania Umowy. Konieczność ich sporządzenia będzie wynikała z rzeczywistych potrzeb Zamawiającego dotyczących Zmian. Zadanie nr 3 realizowane jest w ramach Opcji, do maksymalnego limitu 60 000 Roboczogodzin, na zasadach określonych w PPU. Koszty związane z realizacją obowiązku sporządzania Analiz wstępnych Wykonawca powinien uwzględnić w kalkulacji ceny oferty jako koszty realizacji obowiązków wynikających z Umowy. Zamawiający nie przewiduje odrębnego wynagrodzenia za sporządzanie Analiz wstępnych ani nie gwarantuje określonej liczby Zmian, które po przeprowadzeniu Analizy wstępnej zostaną skierowane do realizacji.

Zamawiający wyjaśnia, że Projektowane Postanowienia Umowy nie przewidują odrębnego trybu odwoławczego od opinii biegłego ani procedury ponownej weryfikacji tej opinii. Celem powołania biegłego jest uzyskanie obiektywnej i merytorycznej oceny zagadnień wymagających wiedzy specjalistycznej. Zgodnie z § 4 ust. 21A.2 PPU, przed sporządzeniem opinii Wykonawca udostępnia biegłemu materiały i informacje niezbędne do jej sporządzenia oraz przedstawia biegłemu swoje stanowisko, w terminie wskazanym przez Zamawiającego, nie krótszym niż 3 Dni Robocze. Na tym etapie Wykonawca może przedstawić dane, argumenty i okoliczności, które w jego ocenie powinny zostać uwzględnione przy ustalaniu pracochłonności i czasu realizacji Zlecenia lub Zmiany. Po sporządzeniu opinii pracochłonność oraz czas realizacji określone przez biegłego stanowią, zgodnie z § 4 ust. 21A.3 i 21A.5 PPU, wiążącą Strony podstawę ustalenia pracochłonności, wynagrodzenia Wykonawcy oraz czasu realizacji danego Zlecenia lub Zmiany. PPU nie przewidują w ramach tego mechanizmu dodatkowego etapu odwoławczego ani ponownego rozpoznania opinii.

Zamawiający nie potwierdza, że Product Backlog zatwierdzony w ramach odbioru Etapu 1 będzie stanowił zamknięty zakres funkcjonalny i niefunkcjonalny objęty wynagrodzeniem ryczałtowym. Zakres Zadania nr 1 wynika z dokumentacji postępowania, w szczególności z OPZ wraz z załącznikami oraz Projektowanych Postanowień Umowy, i podlega uszczegółowieniu oraz konkretyzacji w toku realizacji Etapu 1 i Etapu 2, na zasadach określonych w Umowie. Product Backlog jest jednym z narzędzi służących opisaniu, organizacji i zarządzaniu tym zakresem i może być w toku realizacji Umowy doprecyzowywany, rozwijany i aktualizowany. Nie można zatem przyjąć, że każdy element dodany do Product Backlogu po jego zatwierdzeniu będzie automatycznie kwalifikowany jako Modyfikacja lub Rozwój Systemu. O sposobie realizacji danego wymagania decydować będzie jego charakter oraz ocena, czy mieści się ono w zakresie wymagań funkcjonalnych i niefunkcjonalnych określonych dla Systemu w dokumentacji zamówienia. Za Modyfikację lub Rozwój Systemu mogą zostać uznane wyłącznie wymagania wykraczające poza zakres określony w dokumentacji postępowania, realizowane zgodnie z zasadami przewidzianymi w Umowie.

Zamawiający wyjaśnia, że kwalifikacja funkcjonalności zidentyfikowanej po zakończeniu Etapu 1 będzie dokonywana z uwzględnieniem jej rzeczywistego charakteru oraz źródła wymagania, na podstawie Umowy, OPZ wraz z załącznikami, produktów Analizy funkcjonalnej opracowanych w Etapie 1 oraz ustaleń dokonanych zgodnie z Umową w toku Etapu 1 i Etapu 2. Sam moment zidentyfikowania funkcjonalności ani moment wprowadzenia jej do Product Backlogu nie przesądza o sposobie jej rozliczenia. Jeżeli funkcjonalność wynika z wymagań określonych w dokumentacji postępowania lub stanowi ich uszczegółowienie, dekompozycję albo sposób realizacji i powinna zostać uwzględniona w ramach Analizy funkcjonalnej Etapu 1, jej późniejsze zidentyfikowanie nie powoduje zmiany zakresu Zadania nr 1 ani powstania prawa do dodatkowego wynagrodzenia. Dotyczy to również przypadku określonego w pkt 8.2.1.4 OPZ. Zmiana istniejącego wymagania będzie oceniana z punktu widzenia tego, czy pozostaje w granicach zakresu Zadania nr 1 określonego Umową i OPZ. Doprecyzowanie lub zmiana sposobu realizacji wymagania, pozostająca w tych granicach i dokonywana zgodnie z zasadami określonymi w Umowie dla Etapu 1 i Etapu 2, nie stanowi automatycznie Modyfikacji lub Rozwoju Systemu. Funkcjonalność, która nie wynika z dokumentacji postępowania ani nie stanowi doprecyzowania lub sposobu realizacji określonych w niej wymagań, lecz wprowadza nowe wymaganie funkcjonalne lub niefunkcjonalne albo rozszerza zakres określony dla Zadania nr 1, nie będzie traktowana jako brakujący element zakresu podstawowego. Taka funkcjonalność może zostać zrealizowana w ramach Modyfikacji i Rozwoju Systemu, na zasadach i w terminach przewidzianych dla Zadania nr 3, albo jeżeli jej realizacja nie mieści się w zakresie tego Zadania na zasadach zmiany Umowy, o ile będzie ona dopuszczalna zgodnie z Umową i przepisami ustawy Pzp. O zakwalifikowaniu danej funkcjonalności decydować będzie zatem jej powiązanie z wymaganiami określonymi w dokumentacji postępowania i ustaleniami dokonanymi zgodnie z nią w toku realizacji Umowy, a nie wyłącznie fakt jej ujęcia lub braku ujęcia w Product Backlogu na dzień odbioru Etapu 1.