URZĄD MARSZAŁKOWSKI WOJEWÓDZTWA DOLNOŚLĄSKIEGO Departament Infrastruktury Wydział Wdrażania Technologii Informacyjnych ul. Ostrowskiego 7, 53-238 Wrocław, tel. (71) 770 41 39 PFU.Z10 Proces Zarządczo-Produkcyjny NA POTRZEBY REALIZACJI PROJEKTU „Regionalna platforma informacyjna dla mieszkańców i samorządów Dolnego Śląska e-DolnySlask” Proces Zarządczo-Produkcyjny Status dokumentu Metryka dokumentu Projekt: „Regionalna platforma informacyjna dla mieszkańców i samorządów Dolnego Śląska e-DolnySlask” Beneficjent: Województwo Dolnośląskie Rodzaj dokumentu: Dokument techniczny Tytuł dokumentu: PFU.Z10 Proces Zarządczo-Produkcyjny Autor dokumentu: Małgorzata Łobos, Justyna Pancerow, Marek Kłosiński, Łukasz Ośmiałowski Nr wersji: 2.00 Status: Finalny Zweryfikował: Data i Podpis: Zatwierdził: Data i Podpis: Data 2012.12.21 Historia zmian dokumentu Wersja Data Osoba Opis 1.00 2012-12-18 Małgorzata Łobos, Justyna Pancerow, Marek Kłosiński, Łukasz Ośmiałowski Finalna wersja dokumentu 2.00 2012-12-21 Marek Kłosiński Finalna wersja dokumentu Strona 2 z 81 Proces Zarządczo-Produkcyjny Spis Treści 1. 2. 3. 4. 5. 6. Wstęp .............................................................................................................................................. 4 1.1. Cel dokumentu ........................................................................................................................ 4 1.2. Słownik pojęć ........................................................................................................................... 4 Zarządzanie projektem .................................................................................................................... 5 2.1. Struktura zarządzania projektem ............................................................................................ 5 2.2. Planowanie prac ...................................................................................................................... 8 2.3. Zarządzanie ryzykiem ............................................................................................................ 11 2.4. Zarządzanie zagadnieniami.................................................................................................... 11 2.5. Zarządzanie jakością .............................................................................................................. 12 2.6. Komunikacja .......................................................................................................................... 12 2.7. Raportowanie postępów prac ............................................................................................... 13 2.8. Audyt ..................................................................................................................................... 16 Ramy dostarczania produktów ...................................................................................................... 17 3.1. Produkty projektu .................................................................................................................. 17 3.2. Wytyczne dla kategorii produktów ....................................................................................... 21 Wytyczne do wytwarzania produktów projektu ........................................................................... 36 4.1. Dokumentacja Implementacyjna (DI) .................................................................................... 36 4.2. Kod źródłowy ......................................................................................................................... 51 4.3. Testy ...................................................................................................................................... 52 4.4. Regulamin korzystania z Portalu ........................................................................................... 68 4.5. Dokumentacja powykonawcza .............................................................................................. 68 4.6. Wdrożenie ............................................................................................................................. 69 4.7. Instrukcje stanowiskowe ....................................................................................................... 70 4.8. Transfer wiedzy ..................................................................................................................... 72 4.9. Utrzymanie ............................................................................................................................ 73 4.10. Zintegrowana Platforma e-DS ............................................................................................... 73 Narzędzia i standardy wykorzystywane w projekcie ..................................................................... 75 5.1. Narzędzia i standardy wspierające zarządzanie projektem................................................... 75 5.2. Narzędzia i standardy wspierające prace specjalistyczne ..................................................... 75 Procedury akceptacji produktów i odbiorów etapów ................................................................... 77 Strona 3 z 81 Proces Zarządczo-Produkcyjny 1. Wstęp Cel dokumentu 1.1. Dokument prezentuje wymagania Zamawiającego na sposób pracy Wykonawcy Systemu w zakresie przekazywania produktów, poświadczenia ich jakości, przygotowania do weryfikacji ich jakości przez Zamawiającego oraz interakcje Wykonawcy z Zamawiającym we wskazanym zakresie. Słownik pojęć 1.2. Termin Wyjaśnienie ET Etap Techniczny EZ Etap Zarządczy Podprodukty Elementy składowe produktów, stanowiące dekompozycję Produktów wyszczególnionych w Umowie. Projekt Prowadzony przez Zamawiającego Projekt „Regionalna platforma informacyjna dla mieszkańców i samorządów Dolnego Śląska e-DolnySlask”. Rozwiązanie Patrz: System. Stadium systemu Fragment Systemu, nad którym w danym Etapie Technicznym będą prowadzone prace. System Platforma e-DolnySlask stanowiąca przedmiot niniejszej Umowy. Umowa Umowa zawarta pomiędzy Zamawiającym i Wykonawcą Ilekroć w niniejszym dokumencie jest użyte sformułowanie „Umowa” oznacza ono Umowę oraz wszystkie jej załączniki. Wykonawca Podmiot odpowiedzialny za realizację Umowy. Strona 4 z 81 Proces Zarządczo-Produkcyjny 2. Zarządzanie projektem 2.1. Struktura zarządzania projektem ID PZP.ZP.01 Nazwa cechy Opis Projekt a Niniejsza Umowa jest częścią aktualnie prowadzonego przez Zamawiającego niniejsza Umowa Projektu „Regionalna platforma informacyjna dla mieszkańców i samorządów Dolnego Śląska e-DolnySlask”. Projekt ten zarządzany jest zgodnie z metodyką PRINCE2, w szczególności posiada Komitet Sterujący, mianowanego Kierownika Projektu oraz wynikające z metodyki produkty zarządcze. PZP.ZP.02 Zarządzanie realizacją Struktury zarządcze powołane przez Wykonawcę na potrzeby zarządzania realizacją niniejszej Umowy muszą być zgodne z przyjętymi w Projekcie założeniami oraz muszą się wkomponowywać w dotychczas powołane w Projekcie struktury. Struktura zarządzania Projektem zostanie przedstawiona Wykonawcy po podpisaniu Umowy. PZP.ZP.03 Posiedzenia Komitetu Sterującego uczestnicy W posiedzeniach Komitetu Sterującego Projektu będą uczestniczyli: PZP.ZP.04 Posiedzenia Komitetu Sterującego a. Członkowie Komitetu Sterującego, b. Kierownik Projektu Zamawiającego, c. Koordynator Projektu – rola pełniona przez reprezentanta Inżyniera Kontraktu – o ile o jego uczestnictwo w posiedzeniu zawnioskuje Kierownik Projektu lub któryś z członków Komitetu Sterującego, d. Koordynator Zespołu Wykonawcy - rola pełniona przez reprezentanta Wykonawcy – o ile o jego uczestnictwo w posiedzeniu zawnioskuje Kierownik Projektu lub któryś z członków Komitetu Sterującego, e. Sekretarz - rola pełniona przez reprezentanta Zamawiającego. – rola pełniona przez reprezentanta Posiedzenia Komitetu Sterującego zgodnie z metodyką PRINCE2 będą się odbywały na koniec Etapów Zarządczych oraz mogą odbywać się w trakcie Etapów Zarządczych, o ile o takie posiedzenie zawnioskuje któryś z członków Komitetu Sterującego lub Kierownik Projektu. Strona 5 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.05 Posiedzenia Komitetu Sterującego – zakres notatki Podczas posiedzenia Komitetu Sterującego będzie sporządzana notatka (przez Sekretarza), która zawierać będzie co najmniej: a. listę osób uczestniczących w posiedzeniu, b. agendę posiedzenia ustalaną każdorazowo przed posiedzeniem Komitetu Sterującego, c. podjęte decyzje. PZP.ZP.06 PZP.ZP.07 Notatka z Komitetu Sterującego wymagania Posiedzenia Komitetu Sterującego – prezentacja prac Notatka z posiedzenia Komitetu Sterującego musi zostać: a. uzgodniona podczas posiedzenia, na którym powstała, b. wydrukowana i podpisana przez: i. członków Komitetu Stertującego oraz osoby przez nich zaproszone, ii. Kierownika Projektu, iii. Koordynatora Zespołu Wykonawcy (o ile uczestniczył w posiedzeniu), iv. Koordynatora Projektu (o ile uczestniczył w posiedzeniu). Podczas posiedzenia Komitetu Sterującego, w którym uczestniczy Koordynator Zespołu Wykonawcy musi on zaprezentować Komitetowi Sterującemu prezentację przedstawiającą zaawansowanie prac nad realizacją niniejszej Umowy. Treści oraz zakres informacji zawartych w prezentacji muszą być uzgodnione z Koordynatorem Projektu oraz Kierownikiem Projektu. Treści zawarte w prezentacji muszą obejmować co najmniej: a. omówienie produktów zaplanowanych do realizacji w aktualnym Etapie Zarządczym, b. statusy produktów, które muszą zostać wytworzone w aktualnym Etapie Zarządczym, c. aktualny Plan Prac Wykonawcy i ewentualne jego odchylenia od baseline (który jest zawarty w dokumencie „WU.Z5 Harmonogram rzeczowo-finansowy”) d. ryzyka, e. zagadnienia, f. decyzje do podjęcia istotne z punktu widzenia realizacji prac Wykonawcy. Strona 6 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.08 PZP.ZP.09 PZP.ZP.10 Posiedzenia Komitetu Sterującego – przygotowanie prezentacji Prezentacja Koordynatora Zespołu Wykonawcy dedykowana na posiedzenie Komitetu Sterującego: a. musi być przesłana do wszystkich członków Komitetu Sterującego, Kierownika Projektu, Koordynatora Projektu oraz Biura Projektu nie później niż na 2 dni robocze przez terminem posiedzenia Komitetu Sterującego, b. traktowana będzie jako załącznik do notatki z posiedzenia Komitetu Sterującego. Koordynator Koordynator Zespołu Wykonawcy w szczególności odpowiada za: Zespołu a. zarządzanie całością prac leżących w zakresie prac Wykonawcy, Wykonawcy b. dostarczanie produktów w terminach określonych w Umowie, odpowiedzialność Współpraca z Biurem Projektu c. wywiązywanie się z uzgodnień roboczych, d. dostarczenie produktów zgodnie z wymaganiami (w tym ich kryteriami jakości i akceptacji). Zamawiający wymaga, aby Wykonawca przekazywał do Biura Projektu produkty oraz informację zarządczą zgodnie z wymaganiami określonymi w niniejszym dokumencie. Strona 7 z 81 Proces Zarządczo-Produkcyjny 2.2. Planowanie prac ID PZP.ZP.11 Nazwa cechy Opis Plan Dostarczenia Produktów Wykonawca przed rozpoczęciem swoich prac musi przekazać Zamawiającemu „Plan Dostarczenia Produktów”, który będzie obejmował: a. Plan Prac Wykonawcy, obejmujący: i. harmonogram prac (przedstawiony w postaci diagramu Gantt’a) zawierający: a) terminy dot. Etapów Technicznych, b) dekompozycję produktów na podprodukty, c) terminy rozpoczęcia i zakończenia poszczególnych prac nad produktami i podproduktami, ii. wykaz i opis standardów, które Wykonawca wykorzysta podczas pracy nad poszczególnymi produktami i podproduktami; poszczególne standardy muszą zostać przyporządkowane do produktów i podproduktów, których będą dotyczyły, b. Macierz Podproduktów Produktów, c. Opisy produktów (rozumiane zgodnie z PRINCE2). Zamawiający zastrzega sobie prawo do zgłoszenia uwag do ww. materiału. PZP.ZP.12 Podział na etapy Wykonawca wykona przedmiot niniejszej Umowy w dwóch Etapach Zarządczych (EZ) podzielonych łącznie na 10 Etapów Technicznych (ET), z czego: a. EZ 1 obejmuje: ET 1 – ET 5 – etapy będą obejmowały w szczególności przygotowanie kontentu (wraz z ontologiami), wytworzenie i wdrożenie Systemu, b. EZ2 obejmuje: ET 6 – ET 10 – etapy będą obejmowały utrzymanie Systemu (w tym publikowanie kontentu). PZP.ZP.13 Etap techniczny jako faza prac Zamawiający wymaga, aby Etap Techniczny utożsamiany był z fazą prac planowanych i prowadzonych przez Wykonawcę. W szczególności od decyzji Wykonawcy zależą daty rozpoczęcia poszczególnych Etapów Technicznych składających się na Etap Zarządczy 1. PZP.ZP.14 Etap Zarządczy 1 Zamawiający dopuszcza, aby w ramach EZ 1: - warunki a. kilka Etapów Technicznych rozpoczynało się w tym samym czasie (w szczególności wszystkie), b. Etapy Techniczne nachodziły na siebie. Strona 8 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.15 Podział na etapy Zamawiający wymaga, aby nie nachodziły na siebie: a. Etapy Zarządcze, b. zadania z Etapów Zarządczych. PZP.ZP.16 Realizacja przedmiotu Umowy Wykonawca będzie realizował przedmiot niniejszej Umowy zgodnie z opracowanym przez siebie „Planem Dostarczenia Produktów”, z uwzględnieniem wytycznych zawartych w Umowie. PZP.ZP.17 Planowanie oparte na produktach Zamawiający wymaga, aby planowanie prac przez Wykonawcę było realizowane – zgodnie z PRINCE2 - w oparciu o technikę planowania opartego na produktach. PZP.ZP.18 Macierz podproduktów produktów Wykonawca w ramach planowania prac w ET1 zobowiązany jest opracować „Macierz podproduktów produktów”. Macierz musi prezentować: a. dekompozycję produktów wymienionych w Umowie na ich elementy składowe (podprodukty), b. przypisanie do każdego produktu (lub podproduktu – o ile produkt podlegał dekompozycji) kategorii zgodnej z rozdziału 3.2 „Wytyczne dla kategorii produktów. Przypisana do produktu lub podproduktu kategoria definiuje w szczególności przebieg procedury przeglądu jakości oraz kryteria jakie muszą być spełnione dla danego produktu. Zamawiający nie wyklucza sytuacji, w której podprodukt będzie przypisany do więcej niż jednej kategorii. Jeśli w Umowie dla danego produktu nie zostały zdefiniowane podprodukty, Wykonawca zobowiązany jest do ich określenia oraz przypisania do nich właściwych kategorii (zgodnie z nomenklaturą, o której mowa powyżej) stosownie do przyjętego sposobu realizacji. Zamawiający dopuszcza, aby produkt nie był zdekomponowany przez Wykonawcę na podprodukty (elementy składowe), ale dotyczy to wyłącznie przypadków, w których dany produkt będzie przypisany wyłącznie do jednej kategorii. Poniżej przedstawiony został szablon ww. macierzy. Analiza wymagań szczegółowyc h Projekt wykonawczy Transfer wiedzy Roboty budowlane Promocja Dokumentacja Implementacyjn a Kontent 01.01 Element składowy produktu (podprodukt) Sprzęt Produkt Oprogramowanie Identyfika -tor produktu Dokumentacja Kategorie produktów x x Strona 9 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.19 Plan dostarczenia produktów – określenie wymagań Wykonawca w ramach opracowania „Planu dostarczenia produktów” do każdego z produktów i podproduktów musi przypisać wymagania (w tym wymagania szczegółowe tj. zidentyfikowane przez siebie w wyniku określenia sposobu realizacji wymagań określonych w Umowie), które będą przez nie realizowane. Wymagania powiązane z danym elementem składowym będą podlegały weryfikacji prowadzonej w ramach przeglądu jakości produktu. PZP.ZP.20 Opis produktu Po podpisaniu Umowy Wykonawca dla każdego produktu z Umowy przygotuje „Opis produktu”. Zamawiający zastrzega sobie prawo zgłoszenia uwag do przygotowanych opisów. PZP.ZP.21 Opis produktu – zakres Przygotowany przez w szczególności: Wykonawcę „Opis produktu” musi zawierać a. unikalny identyfikator produktu, b. nazwę produktu, c. przeznaczenie/cel realizacji produktu, d. strukturę produktu (podprodukty produktu - o ile istnieją), e. metodę kontroli jakości (wskazanie kategorii produktu/podproduktu, z której wynikać będzie sposób realizacji przeglądu jakości; metoda kontroli jakości musi być wskazana dla każdego z podproduktów – o ile zostały one wskazane), f. zawartość merytoryczną – np. wskazanie funkcjonalności, które produkt/podprodukt realizuje, g. format w jakim zostanie dostarczony produkt lub każdy z jego podproduktów – np. model xml, dokument .doc, h. formę dostarczenia produktu - np. płyta CD, i. kryteria jakości i akceptacji produktu, j. tolerancję dla jakości, k. produkty zewnętrzne – produkty niewynikające z zakresu Umowy niezbędne do realizacji pracy Wykonawcy (o ile występowanie takich produktów będzie zasadne). PZP.ZP.22 Zarządzanie ryzykiem a planowanie harmonogramu prac Wykonawca musi zarządzać ryzykiem proaktywnie i uwzględniać w planie swoich prac odpowiednie bufory czasowe np. na ryzyko przesunięcia terminu realizacji poszczególnych zadań. PZP.ZP.23 Zmiany ustaleń operacyjnych Każda zmiana ustaleń przyjętych na poziomie operacyjnym niewymagających aneksu do Umowy), wymaga zgody Zamawiającego. (tj. Strona 10 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.24 PZP.ZP.25 2.3. Zakres Etapu Technicznego 1 dla oprogramowani a W zakresie procesu wytwórczego oprogramowania w ET 1 Wykonawca musi zrealizować następujące fazy procesu wytwórczego: Zakres Etapów Technicznych 25 dla oprogramowani a W zakresie procesu wytwórczego oprogramowania w ET 2-ET 5 Wykonawca musi zrealizować następujące fazy procesu wytwórczego: a. analizę szczegółową, b. projektowanie szczegółowe. a. analizę szczegółową, b. projektowanie szczegółowe, c. wytwarzanie, d. dokumentowanie, e. instruktaż stanowiskowy, f. testowanie, g. wdrożenie. Zarządzanie ryzykiem ID PZP.ZP.26 Nazwa cechy Opis Zarządzenie ryzykiem Zarządzanie ryzykiem będzie się odbywało zgodnie z obowiązującymi w Projekcie regułami (zgodnymi z metodyką PRINCE2). Obowiązujące w Projekcie zasady zarządzania ryzykiem zostaną przekazane Wykonawcy po podpisaniu Umowy. PZP.ZP.27 Rejestr ryzyk Podstawowym narzędziem zarządzania ryzykiem w Projekcie jest „Rejestr ryzyka”. Zamawiający wymaga, aby „Rejestr ryzyka” był zasilany przez Wykonawcę zidentyfikowanymi przez niego ryzykami. PZP.ZP.28 Omawianie ryzyk Ryzyka zidentyfikowane przez Wykonawcę dotyczące realizacji niniejszej Umowy będą omawiane podczas spotkań statusowych. 2.4. Zarządzanie zagadnieniami ID PZP.ZP.29 Nazwa cechy Opis Zarządzanie zagadnieniami Zarządzanie zagadnieniami będzie się odbywało zgodnie z obowiązującymi w Projekcie regułami (zgodnymi z metodyką PRINCE2). Strona 11 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.30 Rejestr zagadnień Podstawowym narzędziem zarządzania zagadnieniami w Projekcie jest „Rejestr zagadnień”, zawierający wpisy dotyczące zagadnień związanych z realizacją Projektu, w tym również wynikające z realizacji niniejszej Umowy. PZP.ZP.31 Omawianie zagadnień Zagadnienia dotyczące realizacji niniejszej Umowy będą omawiane podczas spotkań statusowych. 2.5. Zarządzanie jakością ID PZP.ZP.32 2.6. Nazwa cechy Opis Zarządzanie jakością Zarządzanie jakością musi się odbywać zgodnie z obowiązującymi w Projekcie regułami (zgodnymi z metodykąPRINCE2). Obowiązujące w Projekcie zasady zarządzania jakością zostaną przekazane Wykonawcy po podpisaniu Umowy. W przypadku, gdyby była konieczność ich rozbudowy – Wykonawca zobowiązany jest aktywnie uczestniczyć w ich ustalaniu. Komunikacja ID Nazwa cechy Opis PZP.ZP.33 Przepływ komunikacji Przepływ komunikacji w ramach realizacji Umowy będzie zgodny z podległością (poziomami zarządzania) oraz zasadami obowiązującymi w Projekcie. Zasady komunikacji zostaną przedstawione Wykonawcy po podpisaniu Umowy. PZP.ZP.34 Eskalacja zagadnień W przypadku wystąpienia zagadnienia na którymś z poziomów zarządzania i braku możliwości jego rozwiązania np. z powodu niewystarczających uprawnień, następować będzie eskalacja zagadnienia na wyższy poziom. PZP.ZP.35 Komunikacja poprzez Biuro Projektu W zakresie oficjalnej komunikacji (w tym przekazywania produktów do akceptacji) Wykonawca musi komunikować się z Zamawiającym za pośrednictwem Biura Projektu. Biuro Projektu jest odpowiedzialne m.in. za obsługę dokumentacji projektu. PZP.ZP.36 Komunikacja w Wykonawca może komunikować się z Zamawiającym i Inżynierem Kontraktu trybie w trybie roboczym (np. poprzez organizację spotkań, komunikację mailowa, roboczym komunikację telefoniczną). Zasady i tryb tej komunikacji zostaną szczegółowo określone po podpisaniu Umowy z Wykonawcą. Strona 12 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.37 PZP.ZP.38 2.7. Komunikacja między zespołami Komunikacja pomiędzy zespołami Zamawiającego, Wykonawcy i Inżyniera Kontraktu musi odbywać się w oparciu o następujące założenia: Komunikacja bezpośrednia a. podstawowym językiem komunikacji będzie język polski. W przypadku, gdy Wykonawca będzie korzystał z osób nie posługujących się językiem polskim, musi zapewnić tłumaczenie ustne i/lub pisemne na język polski (według potrzeb) w ramach realizowanego zamówienia, b. cała dokumentacja projektowa (wszelkie dokumenty powstałe w ramach niniejszej Umowy) musi być sporządzona w języku polskim. Dopuszcza się język angielski w dokumentacji kodu źródłowego (za wyjątkiem komentarzy zawartych w kodzie). Zamawiający dopuszcza bezpośrednią komunikację pomiędzy Wykonawcą i Inżynierem Kontraktu, w której nie będzie uczestniczył Zamawiający. Raportowanie postępów prac ID Nazwa cechy Opis PZP.ZP.39 Raportowanie postępów prac Raportowanie przez Wykonawcę postępów prac w etapach ET1-ET5 musi się odbywać nie rzadziej niż raz na dwa tygodnie - w ramach spotkań statusowych. PZP.ZP.40 Spotkanie statutowe weryfikacja W ramach spotkania statusowego (odbywającego się nie rzadziej niż raz na 2 – tygodnie) wykonywane będą m.in.: a. weryfikacja postępów prac, b. potwierdzenie aktualności Planu Prac Wykonawcy, c. omówienie ryzyka i zagadnień projektowych. Ww. tematy muszą być omawiane w oparciu o „Raport Statusowy” przygotowywany: a. przez Koordynatora Zespołu Wykonawcy, b. na każde spotkanie statusowe. PZP.ZP.41 Raport statusowy cechy Przygotowywany przez Wykonawcę „Raport statusowy” musi posiadać – następujące cechy: a. zgodność z metodyką PRINCE2, b. zgodność zakresu z przyjętymi ustaleniami, c. zgodność z warunkami Umowy i zakresem obowiązków Wykonawcy. Strona 13 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.42 Raport statusowy zakres informacji Szczegółowy zakres „Raportu Statusowego” zostanie uzgodniony po – podpisaniu Umowy z Wykonawcą i będzie obejmował wszystkie potrzeby informacyjne Zamawiającego dot. przebiegu realizacji Umowy. Raport: a. musi zawierać co najmniej: i. informacje o działaniach podjętych w okresie sprawozdawczym w celu obsługi zagadnień i ryzyk zgłoszonych w poprzednich okresach, ii. zestawienie prac wykonanych przez Wykonawcę za okres raportowania oraz wynikających z zaleceń pokontrolnych (kto, gdzie, kiedy, wynik), iii. informacje o postępie rzeczowym prac związanych z wykonaniem Umowy, iv. propozycje działań naprawczych, v. wszelkie niezbędne załączniki (np. notatki ze spotkań wraz z listami obecności, itp.), b. elementy opcjonalne raportu (załączane odrębnie na pisemne żądanie Zamawiającego): i. płyty DVD z kopią dokumentów przekazywanych w formie papierowej, ii. graficzną prezentację postępów prac w harmonogramu bazowego (wykres Gantta), iii. opisy i fotografie dokumentujące realizację prac, wykonane kontrole jakości, zgłoszone zagadnienia lub zidentyfikowane ryzyka, iv. szczegółowe opisy realizacji działań naprawczych podjętych w poprzednich okresach sprawozdawczych. odniesieniu do PZP.ZP.43 Raport „Raport Statusowy” przygotowany na spotkanie statusowe będzie stanowił statutowy jako załącznik do notatki z tego spotkania statusowego. załącznik PZP.ZP.44 Raport statusowy adresaci „Raport Statusowy” musi zostać przesłany do: - a. Biura Projektu, b. Kierownika Projektu, c. Koordynatora Projektu co 2 tygodnie, w pierwszy dzień roboczy tygodnia, przy czym pierwszy Raport zostanie przedłożony Zamawiającemu po 4 tygodniach począwszy od daty podpisania Umowy. Strona 14 z 81 Proces Zarządczo-Produkcyjny PZP.ZP.45 Spotkanie statutowe uczestnicy W spotkaniach statusowych muszą uczestniczyć: – a. Kierownik Projektu, b. Koordynator Zespołu Wykonawcy, c. Koordynator Projektu (lub reprezentujący go Ekspert ze strony Inżyniera Kontraktu). W spotkaniach statusowych (na zaproszenie ww. ról) mogą uczestniczyć eksperci i inni interesariusze Projektu. Lista osób, która weźmie udział w spotkaniu statusowym musi być przekazana do Biura Projektu nie później niż na 2 dni robocze przed tym spotkaniem. Zamawiający zastrzega sobie prawo do niewyrażenia zgody na udział w spotkaniu wszystkich wskazanych osób (Zamawiający może ograniczyć ich liczbę). PZP.ZP.46 Spotkanie statutowe Spotkania statusowe odbywać się będą w siedzibie Zamawiającego, chyba, że Zamawiający zadecyduje inaczej. PZP.ZP.47 Terminarz lokalizacje statutowe i Terminarz i lokalizację spotkań statusowych przesyła Zamawiający z co najmniej pięciodniowym (liczonym w dniach roboczych) wyprzedzeniem. PZP.ZP.48 Spotkanie statutowe notatka Podczas spotkania statusowego będzie sporządzana notatka, która zawierać – będzie: a. listę osób uczestniczących w spotkaniu, b. agendę spotkania, c. podjęte decyzje. Notatka musi zostać: a. przygotowana przez reprezentanta Wykonawcy, b. uzgodniona podczas spotkania, na którym powstała, c. wydrukowana i podpisana przez: i. ii. iii. PZP.ZP.49 Przedstawienie stanu zaawansowanie prac Kierownika Projektu, Koordynatora Zespołu Wykonawcy, Przedstawiciela Inżyniera Kontraktu. Wykonawca na każde żądanie skierowane przez Kierownika Projektu zobowiązany będzie do przedstawienia mu stanu zaawansowania prac. Żądanie takie będzie kierowane do Koordynatora Zespołu Wykonawcy pisemnie (na jego adres email). Informacja zwrotna nt. zaawansowania stanu prac musi trafić do Kierownika Projektu i Koordynatora Projektu w ciągu 1 dnia roboczego od momentu zawnioskowania o jego przedstawienie. Strona 15 z 81 Proces Zarządczo-Produkcyjny 2.8. Audyt ID PZP.ZP.50 Nazwa cechy Opis Audyt prac Zamawiający zastrzega sobie prawo przeprowadzenia niezależnego audytu prac Wykonawcy mającego na celu dokonanie: a. niezależnej oceny poprawności realizacji przez zobowiązań związanych z realizacją prac w Projekcie, Wykonawcę b. zidentyfikowanie słabych stron działań Wykonawcy i wskazanie niezbędnych do wdrożenia działań naprawczych, c. ustalenia statusów produktów oraz listy uwag do uwzględnienia przez Wykonawcę. Ocena będzie wykonywana w oparciu o: PZP.ZP.51 Działania audytowe PZP.ZP.52 Informacja audycie a. sposób wypełniania zobowiązań Wykonawcy wynikających z Umowy, b. zgodność z bieżącymi uzgodnieniami dotyczącymi sposobu realizacji prac, c. normy prawne, d. zadeklarowane przez Wykonawcę standardy stosowane podczas realizacji Umowy, e. uznane światowe standardy (np. PRINCE 2, ITIL) związane z obszarem specjalistycznym prac oraz obszarem zarządczym. Zamawiający przewiduje, że działania audytowe będą miały miejsce w sytuacji wystąpienia odchyleń w pracach Wykonawcy, wykrycia nieprawidłowości w produktach lub sposobie realizacji prac. Zamawiający nie rezygnuje jednak z prawa uruchomienia działań audytowych z innych przyczyn. o Na 5 dni roboczych przed planowanym audytem Zamawiający poinformuje pisemnie Wykonawcę o terminie audytu oraz jego zakresie. Wykonawca w celu przeprowadzenia audytu musi udostępnić Zamawiającemu i/lub jego reprezentantom elementy niezbędne do przeprowadzenia audytu we wskazanym zakresie. Czas trwania audytu oraz stosowania wniosków poaudytowych nie może być powodem niewywiązania się przez Wykonawcę z terminów zawartych w Umowie. Strona 16 z 81 Proces Zarządczo-Produkcyjny 3. Ramy dostarczania produktów 3.1. Produkty projektu 3.1.1. Produkty zarządcze ID PZP.PROD.01 PZP.PROD.02 Nazwa cechy Opis Produkty zarządcze Produkty zarządcze wytwarzane w ramach realizacji niniejszej Umowy muszą wynikać kolejno z: Utrzymanie produktów zarządczych a. potrzeb Zamawiającego, b. metodyki PRINCE2 i być z nią zgodne. Wykonawca zobowiązany jest do aktywnego uczestnictwa w przygotowywaniu, aktualizacji i utrzymywaniu już istniejących produktów zarządczych Projektu (tzn. dostarczaniu w miarę postępów projektu materiału aktualizującego produkty zarządcze). Przez produkty zarządcze należy rozumieć w szczególności: a. Dokument Inicjujący Projekt, na który składają się.: i. Strategia Zarządzania Ryzykiem, ii. Strategia Zarządzania Jakością, iii. Strategia Zarządzania Konfiguracją, iv. Strategia Zarządzania Komunikacją, v. Szczegółowe uzasadnienie biznesowe, vi. Plan projektu (w tym opisy produktów), vii. Opisy ról, viii. Formuła realizacji projektu, ix. Definicja projektu, x. Mechanizmy sterowania, xi. Struktura zespołu zarządzania projektem , b. Plan Etapu, c. Zapisy Obiektu Konfiguracji, d. Rejestr Ryzyk, e. Rejestr Jakości, f. Rejestr Zagadnień, Strona 17 z 81 Proces Zarządczo-Produkcyjny g. Plan Przeglądu Korzyści, h. Raport Statusowy (tzw. raport okresowy), i. Raport Końcowy Etapu, j. Raport Doświadczeń. Zapisy zawarte w produktach zarządczych muszą w szczególności odzwierciedlać zobowiązania Wykonawcy, które musi on wykonać na rzecz Zamawiającego na podstawie niniejszej Umowy i do których się on zobowiązuje. PZP.PROD.03 Zasilanie rejestrów „Rejestr ryzyka”, „Rejestr zagadnień” i „Rejestr jakości” muszą być zasilane przez Wykonawcę przez cały czas trwania Umowy w trybie umożliwiającym sprawne zarządzanie ryzykiem, zagadnieniami i jakością. PZP.PROD.04 Raport „Raport Końcowy Etapu” zawierać będzie w szczególności: końcowy etapu a. wykazy zakończonych elementów Umowy oraz informację o postępie – zakres rzeczowym realizacji Umowy, informacji b. informacje o działaniach informacyjno promocyjnych przeprowadzonych przez Wykonawcę. PZP.PROD.05 Szablon raportów protokołów Po podpisaniu Umowy Wykonawca przygotuje i uzgodni z Zamawiającym i szablony raportów i protokołów (zgodne z wymaganymi zawartymi w Umowie), które będą wykorzystywane podczas realizacji Umowy. Uzgodnieniu będą podlegały co najmniej: a. b. Raporty: i. Raport statusowy, ii. Raport z testów wewnętrznych, iii. Raport z testów, iv. Raport pokrycia kodu testami automatycznymi, v. Raport kwartalny (szczegółowo opisany w dokumencie „PFU.Z8 Utrzymanie i funkcje operatorskie – specyfikacja wymagań”), vi. Raport przekazywany co pół roku w ramach informowania o wykorzystaniu zasobów systemu (szczegółowo opisany w dokumencie „PFU.Z8 Utrzymanie i funkcje operatorskie – specyfikacja wymagań”), vii. Raport roczny (szczegółowo opisany w dokumencie „PFU.Z8 Utrzymanie i funkcje operatorskie – specyfikacja wymagań”), viii. Raporty działań bieżących (szczegółowo opisany w dokumencie „PFU.Z8 Utrzymanie i funkcje operatorskie – specyfikacja wymagań”). Protokoły: i. Protokół przekazania produktu do akceptacji, Strona 18 z 81 Proces Zarządczo-Produkcyjny ii. Protokół akceptacji produktu, Uzgodnieniu nie będą podlegały: PZP.PROD.06 a. Raport z przeglądu jakości, b. Protokół częściowego odbioru, c. Protokół końcowego odbioru. Protokół „Protokół przekazania produktu do akceptacji” musi zawierać co najmniej: przekazania a. liczbę i formę (np. płyta CD, wydruk) dostarczanych Produktów, produktu do b. deklarację Wykonawcy podpisaną przez następujące osoby: akceptacji – zakres i. Koordynatora Zespołu Wykonawcy informacji ii. osobę odpowiedzialną za wytworzenie produktu, iii. w przypadku dokumentacji – autora/autorów dokumentu że dany produkt: i. spełnia wszystkie zdefiniowane dla niego wymagania w tym kryteria (jakości i akceptacji), ii. jest wolny od wad, iii. jest kompletny z punktu widzenia celu jakiemu ma służyć, iv. jest zgodny z przepisami prawa krajowego i wspólnotowego, v. jest zgodny z wiedzą techniczną i metodami projektowania, vi. jest zgodny z normami i przepisami techniczno-budowlanymi (dotyczy robót montażowych). W przypadku, gdy dla produktu wskazano podprodukty, ww. informacje muszą zostać przedstawione również dla każdego z podproduktów. „Protokół przekazania produktu do akceptacji” musi dotyczyć jednego kompletnego produktu. PZP.PROD.07 Raport z „Raport z przeglądu jakości” zawiera w szczególności: przeglądu a. informacje nt. produktu, którego przegląd dotyczył, jakości – zakres b. zakres przeglądu, informacji c. informacje nt. ilości błędów/niezgodności produktu z przyjętymi założeniami. Strona 19 z 81 Proces Zarządczo-Produkcyjny 3.1.2. Produkty specjalistyczne ID Nazwa cechy Opis PZP.PROD.08 Odbiory produktów Wszystkie produkty wymienione w dokumencie „WU.Z1 Wykaz produktów wraz z kryteriami jakości i akceptacji” podlegają akceptacji Zamawiającego w etapach, do których zostały przypisane. PZP.PROD.09 Rozpoczęcie prac Zamawiający dopuszcza, aby Wykonawca rozpoczął prace nad nad produktami poszczególnymi produktami projektu we wcześniejszych Etapach Technicznych niż te, do których zostały one przypisane w Umowie. PZP.PROD.10 Zarządzanie pracą Prace Wykonawcy nad produktami innymi niż przypisane do danego nad produktami Etapu Technicznego nie mogą: a. zakłócić prac nad produktami, które są w danym etapie poddawane akceptacji, b. wpłynąć negatywnie na jakość produktów, które są w danym etapie poddawane akceptacji. Strona 20 z 81 Proces Zarządczo-Produkcyjny 3.2. Wytyczne dla kategorii produktów 3.2.1. Produkt z kategorii: dokumentacja ID Nazwa cechy Opis PZP.PROD.11 Język dokumentu Dokument musi być sporządzony w języku polskim (chyba, że Zamawiający określił inaczej) z zachowaniem poprawności językowej. PZP.PROD.12 Metryka dokumentu Dokument musi posiadać metrykę informującą co najmniej o: a. osobie ze strony Wykonawcy odpowiedzialnej za treść dokumentu, b. osobie ze strony Wykonawcy weryfikację zawartości dokumentu, c. autorach dokumentu, d. historii zmian obejmującej wyłącznie wersje przekazane Zamawiającemu; w historii zmian muszą być uwzględnione: odpowiedzialnej za i. data wytworzenia wersji, ii. opis zmian względem poprzedniej wersji przekazanej Zamawiającemu – jednoznaczny opis dokonanych zmian wraz ze wskazaniem fragmentu (lub fragmentów dokumentu), którego treść podlegała modyfikacjom, iii. autorach zmiany, iv. powodach dokonania zmiany. PZP.PROD.13 Struktura dokumentu Dokument musi posiadać czytelną strukturę, tzn. tworzone dokumenty muszą być podzielone w czytelny i przejrzysty sposób na rozdziały, podrozdziały i sekcje. PZP.PROD.14 Spójność dokumentu Dokument musi posiadać spójną strukturę, formę oraz sposób konstruowania treści (w tym także pod względem gramatycznym). PZP.PROD.15 Poprawność dokumentu Dokument musi być niesprzeczny, logicznie spójny wewnętrznie oraz logicznie spójny ze wszystkimi innymi produktami przekazanymi Zamawiającemu przez Wykonawcę. PZP.PROD.16 Przekazanie dokumentu Dokument musi zostać przekazany Zamawiającemu w następujących postaciach: a. plik Microsoft Word 2007, w wersji edytowalnej, b. plik w standardzie Portable Document Format (zgodny z ISO 32000-1:2008) , c. dokument w formie wydrukowanej. Strona 21 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.17 Aktualizacja dokumentów Przekazywane Zamawiającemu dokumenty (stanowiące produkty lub podprodukty wynikające z niniejszej Umowy) muszą być przez Wykonawcę utrzymywane (aktualizowane) przez cały okres trwania Umowy, niezależnie od tego, w którym Etapie Technicznym zostały zaakceptowane. Zamawiający musi przez cały czas trwania Umowy dysponować aktualnymi wersjami dokumentów (w szczególności Dokumentacją Powykonawczą). PZP.PROD.18 Standard dokumentacji Dokumentacja wynikająca z realizacji niniejszej Umowy musi być sporządzona zgodnie z wymaganiami Zamawiającego. Poszczególne dokumenty muszą być tworzone zgodnie z przygotowanymi przez Wykonawcę szablonami. Zamawiający zastrzega sobie prawo zgłoszenia uwag do przygotowanych przez Wykonawcę szablonów dokumentów. PZP.PROD.19 Dokumentacja - zakres Prowadzona przez Zamawiającego (w ramach przeglądu jakości weryfikacji produktu) weryfikacja produktu/podproduktu z kategorii dokumentacja, może obejmować weryfikację: a. zgodności przekazanego produktu”, produktu z jego „Opisem b. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, c. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji). 3.2.2. Produkt z kategorii: oprogramowanie ID PZP.PROD.20 Nazwa cechy Opis Produkty z kategorii Do produktów z kategorii oprogramowanie zalicza się: oprogramowanie a. oprogramowanie standardowe-komercyjne (oprogramowanie typu COTS - Commercial off-the-shelf – „z półki”), b. oprogramowanie standardowe–publiczne (oprogramowanie typu open-source), c. oprogramowanie dedykowane – budowane przez Wykonawcę na potrzeby realizacji niniejszej Umowy. Strona 22 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.21 Zastosowanie oprogramowania Zamawiający wymaga, aby wszędzie tam, gdzie możliwe jest zastosowanie oprogramowania standardowego-komercyjnego lub oprogramowania standardowego - publicznego – takie oprogramowanie zostało dostarczone i wykorzystane przez Wykonawcę. Zamawiający może odstąpić od tego wymagania jedynie w przypadkach, w których Wykonawca jednoznacznie udowodni, że zastosowanie danego programowania dedykowanego jest: a. bardziej korzystne dla Zamawiającego (korzyści muszą zostać przedstawione w postaci wymiernych oraz mierzalnych korzyści), b. niesie ze sobą mniejsze ryzyko (tak na etapie wytwarzania jak i późniejszego użytkowania oraz utrzymania). Ponadto, Wykonawca musi przedstawić macierz prezentującą listę wszystkich wymagań, które zgodnie z Umową ma spełniać dane oprogramowanie oraz sposób realizacji każdego z wymagań przez oprogramowanie dedykowane, a także programowanie standardowe najbardziej dopasowane do potrzeb Zamawiającego. PZP.PROD.22 Oprogramowanie standardowekomercyjne Za oprogramowanie standardowe - komercyjne może być uznane tylko oprogramowanie powszechnie dostępne, spełniające następujące warunki: a. komercyjne, b. gotowe w momencie złożenia oferty, c. jest dostępna dojrzała i czytelna dokumentacja techniczna, d. są dostępne usługi szkoleniowe i wdrożeniowe u dostawców innych niż producent tego oprogramowania, e. oprogramowanie posiada minimum 3 wdrożenia wykonane przez minimum 2 różnych, niezależnych od producenta dostawców (Zamawiający wymaga pisemnego poświadczenia tego faktu przez instytucje, w których dokonano takiego wdrożenia). Ponadto Wykonawca dla standardowego - komercyjnego: dostarczonego oprogramowania a. dostarczy dokumentację dotyczącą dostarczonego oprogramowania (w tym licencje dla oprogramowania); dostarczone licencje nie mogą być ograniczone w czasie, b. zapewni w ramach serwisu gwarancyjnego asystę techniczną polegającą na dostarczaniu przez cały okres realizacji Umowy i gwarancji poprawek, aktualizacji oprogramowania standardowego oraz subskrypcji udostępnianych przez producenta, c. zapewni wsparcie producenta podczas rozwiązywania Strona 23 z 81 Proces Zarządczo-Produkcyjny incydentów i problemów przez cały okres realizacji Umowy i gwarancji, zgodnie z zapisami zawartymi w dokumencie „PFU.Z8.Utrzymanie i funkcje operatorskie – specyfikacja wymagań”. Dostarczone przez Wykonawcę licencje nie mogą być związane z konkretnym sprzętem, muszą natomiast umożliwiać przenoszenie licencjonowanego oprogramowania pomiędzy poszczególnym sprzętem w ramach Projektu (nawet sprzętem zakupionym przez Zamawiającego poza niniejszą Umową), przy zachowaniu ograniczeń na liczbę komputerów i procesorów, na których jest zainstalowane i uruchomione oprogramowanie standardowe, zgodnie z warunkami licencji. PZP.PROD.23 Oprogramowanie Wykonawca dla dostarczonego oprogramowania standardowego standardowe – publicznego : publiczne a. dostarczy dokumentację dotyczącą dostarczonego oprogramowania (w tym licencje dla oprogramowania); dostarczone licencje nie mogą być ograniczone w czasie, b. zapewni w ramach serwisu gwarancyjnego asystę techniczną polegającą na dostarczaniu przez cały okres realizacji Umowy i gwarancji poprawek, aktualizacji oprogramowania standardowego oraz subskrypcji, c. zapewni wsparcie podczas rozwiązywania incydentów i problemów przez cały okres realizacji Umowy i gwarancji, zgodnie z zapisami zawartymi w dokumencie: „PFU.Z8.Utrzymanie i funkcje operatorskie – specyfikacja wymagań”. Dostarczone przez Wykonawcę licencje: a. nie mogą być związane z konkretnym sprzętem, muszą natomiast umożliwiać przenoszenie licencjonowanego oprogramowania pomiędzy poszczególnym sprzętem w ramach Projektu (nawet sprzętem zakupionym przez Zamawiającego poza niniejszą Umową), b. nie mogą zawierać żadnych ograniczeń w szczególności dotyczących liczby komputerów i procesorów, na których jest zainstalowane i uruchomione oprogramowanie standardowe – publiczne, miejsca jego użytkowania, itp. Strona 24 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.24 PZP.PROD.25 Oprogramowanie dedykowane Wykonawca dla dostarczonego oprogramowania dedykowanego: a. dostarczy dokumentację dotyczącą dostarczonego oprogramowania, b. dostarczy kod źródłowy, c. dostarczy wersję uzyskaną na podstawie przeprowadzonej asemblacji, d. zapewni wsparcie podczas rozwiązywania i problemów przez cały okres realizacji Umowy zgodnie z zapisami zawartymi w „PFU.Z8.Utrzymanie i funkcje operatorskie – wymagań”, d. przeniesie na Zamawiającego prawa autorskie. incydentów i gwarancji, dokumencie specyfikacja Oprogramowanie – Prowadzona przez Zamawiającego (w ramach przeglądu jakości zakres weryfikacji produktu) weryfikacja produktu/podproduktu z kategorii oprogramowanie, może obejmować weryfikację: a. zgodności przekazanego produktu z jego „Opisem produktu”, d. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, b. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji). 3.2.3. Produkt z kategorii: sprzęt ID Nazwa cechy Opis PZP.PROD.26 Sprzęt Wykonawca dostarczy sprzęt pozwalający na osiągnięcie wolumetrii systemu zgodnie z wymaganiami zawartymi w Umowie. PZP.PROD.27 Element sprzęt produktu Wykonawca dostarczy sprzęt wraz z niezbędnym okablowaniem, dokumentacją techniczno-eksploatacyjną, certyfikatami bezpieczeństwa oraz dokumentami potwierdzającymi udzielenie Zamawiającemu gwarancji na te urządzenia. PZP.PROD.28 Koszty sprzętu dostawy Wszelkie koszty związane z dostawą sprzętu do wskazanego przez Zamawiającego miejsca, a także instalacją sprzętu oraz oprogramowania ponosi Wykonawca. PZP.PROD.29 Instalacja Instalacja sprzętu oraz oprogramowania, a także jego konfiguracja musi spełniać wymagania zawarte w Umowie. PZP.PROD.30 Asysta techniczna Dla dostarczonej infrastruktury sprzętowej i sieciowej Wykonawca zapewni asystę techniczną polegającą na dostarczaniu przez cały okres realizacji Umowy i gwarancji poprawek, aktualizacji oprogramowania oraz subskrypcji udostępnianych przez producenta. Strona 25 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.31 Wsparcie producenta Dla dostarczonej infrastruktury sprzętowej i sieciowej Wykonawca zapewni wsparcie producenta podczas rozwiązywania incydentów i problemów przez cały okres realizacji Umowy i gwarancji. PZP.PROD.32 Raport z dostawy podproduktu – uzupełnienie dla produktów z kategorii sprzęt W przypadku „Raportu z dostawy podproduktu” dla podproduktów z kategorii sprzęt musi on dodatkowo zawierać: a. b. opis wszystkie elementów sprzętowych oraz dla każdego z nich wyspecyfikowane co najmniej: i. nazwę podproduktu, ii. nazwę własną danego elementu sprzętowego (wraz z jego modelem), iii. nr seryjny elementu sprzętowego (ewentualne inne istotne identyfikatory określone przez Wykonawcę lub producenta), iv. lokalizację zainstalowanego sprzętu np. w serwerowni (rysunek poglądowy lub opis), v. datę produkcji elementu sprzętowego, vi. koszt elementu sprzętowego wyrażony w polskich złotych. deklarację, że dostarczony sprzęt jest nowy, wolny od wad, pochodzi z legalnego źródła i jest dopuszczony w Polsce do obrotu. W przypadku, gdy Wykonawca dla produktu/podproduktu z kategorii sprzęt zrezygnuje z wykorzystania „Raportu z dostawy podproduktu” ww. informacje będą musiały się znaleźć w „Protokole przekazania produktu do akceptacji” na podstawie którego dany produkt/podprodukt zostanie przekazany Zamawiającemu. PZP.PROD.33 Sprzęt – weryfikacji zakres Prowadzona przez Zamawiającego (w ramach przeglądu jakości produktu) weryfikacja produktu/podproduktu z kategorii sprzęt, może obejmować weryfikację: a. zgodności przekazanego produktu z jego „Opisem produktu”, e. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, b. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji), w szczególności w zakresie zgodności produktu/podproduktu z wymaganą specyfikacją, c. poprawności działania (w podstawowym zakresie). Strona 26 z 81 Proces Zarządczo-Produkcyjny 3.2.4. Produkt z kategorii: transfer wiedzy ID Nazwa cechy Opis PZP.PROD.34 Przygotowanie środowiska Za przygotowanie środowiska pozwalającego na przeprowadzenie instruktarzy odpowiada Wykonawca. Środowisko, na którym będą prowadzone instruktaże zostanie wyodrębnione na czas przeprowadzenia instruktaży ze środowiska testowego. PZP.PROD.35 Przeprowadzenie instruktażu Wykonawca podczas instruktażu musi zapewnić: a. b. dla każdego z uczestników: i. wydrukowane materiały prezentacyjne i instrukcje dla każdego uczestnika, ii. komplet materiałów biurowych tj. długopis, notatnik oraz ewentualnie inne materiały wymagane w celu sprawnego przeprowadzenia instruktażu (np. karteczki samoprzylepne), iii. certyfikat świadczący o ukończeniu instruktażu, iv. inny sprzęt niezbędny do przeprowadzenia instruktażu (np. odpowiednio skonfigurowanego laptopa bądź stację roboczą). rzutnik. PZP.PROD.36 Czas trwania Czas trwania instruktażu dziennie dla każdej grupy to maksymalnie 6 instruktażu godzin zegarowych (liczonych bez przerw). PZP.PROD.37 Ilość osób instruktażu PZP.PROD.38 Miejsce instruktażu PZP.PROD.39 Zapewnienie miejsca Wykonawca musi zapewnić salę, w której zostanie przeprowadzony instruktażu instruktaż. PZP.PROD.40 Uczestnicy instruktażu W instruktażach mogą uczestniczyć pracownicy Zamawiającego lub osoby z podmiotów przez niego wskazanych. PZP.PROD.41 Plan instruktażu Wykonawca musi opracować plan instruktaży (w tym w szczególności ich szczegółową zawartość merytoryczną). Zamawiający zastrzega sobie prawo zgłoszenia uwag do przygotowanych planów. PZP.PROD.42 Przedstawienie planu instruktażu Wykonawca po wykonaniu instruktażu zobowiązany jest przedstawić Zamawiającemu (w ciągu 2 dni roboczych) listę obecności uczestników podpisaną przez każdego z nich oraz wypełnione przez uczestników ankiety oceny instruktażu. na Grupy biorące udział w instruktażu nie mogą przekraczać 10 osób. Wszystkie instruktaże muszą być prowadzone na terenie województwa dolnośląskiego. Strona 27 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.43 Ankieta oceniająca Podczas każdego z instruktaży wszyscy jego uczestnicy muszą wypełnić instruktaż przygotowaną przez Wykonawcę „Ankietę” oceniającą instruktaż. Ocenie muszą podlegać: a. lokalizacja przeprowadzenia instruktażu, b. przygotowane prezentacje, c. jakość oraz przydatność prezentacyjnych i instrukcje, d. przygotowanie sali do instruktaży (w tym rzutnik, stacje robocze, o ile były wykorzystywane podczas instruktażu), e. wiedza merytoryczna osób prowadzących instruktaż z zakresu jego tematyki, f. zaangażowanie osób prowadzących instruktaż w przekazanie uczestnikom wiedzy. wydrukowanych materiałów Ankieta nie może być anonimowa. Skala wykorzystana do oceny ww. aspektów musi się składać z czterech następujących poziomów: PZP.PROD.44 PZP.PROD.45 a. 1 – bardzo złe, b. 2 – słabe, c. 3 – dobre, d. 4 – doskonałe. Potwierdzenie Potwierdzeniem dla Zamawiającego faktu przeprowadzenia przez wykonania transferu Wykonawcę danego instruktażu będzie przekazanie Zamawiającemu: wiedzy a. podpisanej listy obecności uczestników biorących udział w instruktażu, Ocena instruktażu przez wizytatora b. ankiet oceniających instruktaż wypełnionych przez wszystkich uczestników, c. zbiorczego podsumowania wyników z przekazanych ankiet, d. trzech kompletów materiałów przekazanych uczestnikom. Zamawiający ma prawo do oddelegowania wizytatora, który dokona oceny sposobu przeprowadzenia instruktażu. Podczas instruktażu wizytator nie będzie traktowany jak uczestnik. Strona 28 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.46 Weryfikacja instruktażu - zakres Prowadzona przez Zamawiającego (w ramach przeglądu jakości produktu) weryfikacja produktu/podproduktu z kategorii transfer wiedzy, może obejmować weryfikację: a. zgodności przekazanego produktu z jego „Opisem produktu”, b. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, c. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji), w tym: d. i. weryfikację zakresu informacyjnego instruktażu, ii. weryfikację materiałów dostarczonych uczestnikom instruktażu (w tym np. ich zgodności z aktualną wersją oprogramowania, do której odwołuje się instruktaż), iii. weryfikację wyników ankiet wypełnionych przez uczestników instruktażu po jego zakończeniu (w przypadku, gdy średnia ocena z ankiet wszystkich uczestników biorących udział w danym instruktażu, dla każdego z obszarów, o których mowa w wymaganiu: PZP.PROD.43 (liczona dla każdego z obszarów osobno) będzie niższa niż 3 - instruktaż będzie musiał zostać powtórzony i ponownie poddany ocenie zgodnie z zasadami opisanymi w niniejszym wymaganiu. Zamawiający zastrzega sobie prawo do nieskorzystania z ponownego przeprowadzenia instruktażu), pozyskanie opinii wizytatora biorącego udział w instruktażu. 3.2.5. Produkt z kategorii: kontent ID Nazwa cechy Opis PZP.PROD.47 Autorecenzje Autorecenzja kontentu będzie wykonana przez Wykonawcę zgodnie z wymaganiami określonymi w dokumencie „PFU.Z5 Architektura informacji i specyfikacja kontentu”. PZP.PROD.48 Badanie ortofotomapy Dla ortofotomapy (stanowiącej kontent ekspercki) oprócz autorecenzji (opracowywanej przez Wykonawcę) będzie dodatkowo prowadzone badanie zgodności z zapisami zawartymi w załączniku nr 2 do dokumentu „PFU.Z5 Architektura informacji i specyfikacja kontentu”. Strona 29 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.49 Metody weryfikacji Dla produktu/podproduktu z kategorii kontent prowadzone będą kontentu następujące weryfikacje: a. b. PZP.PROD.50 Weryfikacja dostarczonego kontentu weryfikacja dostarczonego kontentu (treści informacyjnej) weryfikacje te prowadzone będą w każdym z Etapów Technicznych 2 – 5, weryfikacja sformalizowanych ontologii dziedzinowych oraz ontologii systemowej (dla ET5). Weryfikacja dostarczanego kontentu (treści informacyjnej) obejmować będzie: a. weryfikację ilościową dla danego zakresu informacyjnego treści: i. zgodnie z wytycznymi wskazanymi w rozdziale „Wymagania ilościowe” w dokumencie „PFU.Z5 Architektura informacji i specyfikacja kontentu”. ii. przed rozpoczęciem weryfikacji przez Zamawiającego Wykonawca Platformy e-DS przekaże potwierdzenie realizacji wymagań ilościowych tj. potwierdzenie, iż wszystkie wytyczne z Załącznika nr 1 do dokumentu „PFU.Z5 Architektura informacji i specyfikacja kontentu” zostały zrealizowane (mapowanie wymagań potwierdzające zaimplementowanie w systemie wymaganej ilości obiektów bazodanowych w tym zdjęć/grafik, materiałów audio, wideo, panoram, spacerów wirtualnych, materiałów e-learning, itd. – zgodnie z Załącznikiem nr 1 do dokumentu „PFU.Z5 Architektura informacji i specyfikacja kontentu”). b. weryfikację jakościową dla danego zakresu informacyjnego treści - weryfikacja zostanie przeprowadzona na podstawie próbek, które zostaną wybrane i zweryfikowane zgodnie z zapisami zawartymi w dokumencie „PFU.Z5 Architektura informacji i specyfikacja kontentu”. PZP.PROD.51 Weryfikacja sformalizowanych ontologii Weryfikacja sformalizowanych ontologii dziedzinowych oraz ontologii systemowej obejmować będzie potwierdzenie spełnienia wymagań wskazanych w dokumencie „PFU.Z5 Architektura informacji i specyfikacja kontentu” oraz kompletności opisywanych dziedzin wiedzy. Strona 30 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.52 Kontent – zakres weryfikacji Prowadzona przez Zamawiającego (w ramach przeglądu jakości produktu) weryfikacja produktu/podproduktu z kategorii dokumentacja, może obejmować weryfikację: a. zgodności przekazanego produktu z jego „Opisem produktu”, b. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, c. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji) w tym dotyczących przekazania praw autorskich do wytworzonego kontentu. 3.2.6. Produkt z kategorii: roboty montażowe ID Nazwa cechy Opis PZP.PROD.53 Prace montażowe Wszystkie prace montażowe muszą być przeprowadzone zgodnie z obowiązującymi w Polsce normami, standardami (w tym określonymi przez producentów produktów i materiałów wykorzystywanych podczas montażu) oraz dobrymi praktykami. PZP.PROD.54 Przeprowadzenie montażu Wykonawca musi dokonać montażu w sposób estetyczny, w tym okablowanie musi przebiegać w możliwie niewidocznych miejscach, a ewentualne uszczerbki w powierzchni budynków (powstałe na skutek np. wiercenia otworów), muszą zostać naprawione w sposób możliwie nierzucający się w oczy, PZP.PROD.55 Bezpieczeństwo montażu Wykonawca musi odpowiednio zabezpieczyć miejsce montażu, tak aby wykonywane przez niego prace oraz wykorzystywany przez niego sprzęt w żadnym stopniu nie zagrażały zdrowiu osób trzecich (np. przechodniów). PZP.PROD.56 Forma przeprowadzenia montażu Wykonawca musi prowadzić prace montażowe w sposób, który nie uniemożliwi normalnego korzystania z budynków (i obiektów), na których (i w otoczeniu których) będą prowadzone prace montażowe. PZP.PROD.57 Prace po montażu Wykonawca musi posprzątać miejsce, w którym dokonywał montażu i pozostawić je w stanie nie gorszym niż je zastał. PZP.PROD.58 Raport z przekazania „Raport z przekazania podproduktu” dla podproduktów z kategorii podproduktu – prace prace montażowe musi dodatkowo obejmować: montażowe a. okres prowadzenia prac montażowych, b. miejsce montażu, c. charakterystykę przeprowadzonych prac (specyfikacja prac, które zostały wykonane), d. oświadczenia, że: Strona 31 z 81 Proces Zarządczo-Produkcyjny e. i. prace zostały wykonane zgodnie z obowiązującym w Polsce prawem, normami i standardami, ii. wykonany montaż i przedmiot montażu jest wolny od wad, iii. sposób wykonania montażu nie zagraża zdrowiu osób trzecich, iv. wykonane prace montażowe realizują wszystkie zdefiniowane dla nich wymagania (w tym szczegółowe), v. wykonanie obiektu budowlanego jest zgodne z dokumentacją projektową, vi. o doprowadzeniu do należytego stanu i porządku terenu budowy, a także - w razie korzystania - drogi, ulicy, sąsiedniej nieruchomości, budynku lub lokalu. podpis: Koordynatora Zespołu Wykonawcy oraz kierownika budowy lub kierownika/kierowników robót w specjalności wymaganej zakresem prac. W przypadku, gdy Wykonawca dla produktu/podproduktu z kategorii roboty montażowe zrezygnuje z wykorzystania „Raportu z dostawy podproduktu” ww. informacje będą musiały się znaleźć w „Protokole przekazania produktu do akceptacji” na podstawie którego dany produkt/podprodukt zostanie przekazany Zamawiającemu. PZP.PROD.59 Roboty montażowe – zakres weryfikacji Prowadzona przez Zamawiającego (w ramach przeglądu jakości produktu) weryfikacja produktu/podproduktu z kategorii roboty montażowe, może obejmować weryfikację: a. zgodności przekazanego produktu z jego „Opisem produktu”, b. „Macierzy spełnienia wymagań” opracowanej dla danego produktu/podproduktu, pod względem ilościowym i jakościowym, c. spełnienia przez dany produkt/podprodukt zdefiniowanych na niego wymagań (w tym kryteriów jakości i akceptacji) w tym wszystkich niezbędnych raportów, protokołów, opinii; weryfikacja może być prowadzona w szczególności w oparciu o wykonane wizje lokalne i zewnętrzne ekspertyzy. 3.2.7. Produkt z kategorii: promocja ID PZP.PROD.60 Nazwa cechy Banery www na Opis strony Każdy z banerów musi: a. być animowany, Strona 32 z 81 Proces Zarządczo-Produkcyjny b. zostać zaprojektowany przez Wykonawcę w co najmniej 3 wariantach istotnie różniących się od siebie; wyboru wariantu, który zostanie skierowany do wykorzystania dokonuje Zamawiający, c. zostać zaprojektowany w 3 wielkościach, przy czym ich wielkość nie może być mniejsza niż określona w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. Wytworzone banery muszą zostać przekazane Zamawiającemu na płycie CD/DVD w 3 egzemplarzach. PZP.PROD.61 Kampanie Dla: a. kampanii outdoor’owych – Wykonawca w szczególności musi przekazać dokumentacje fotograficzną, b. serwisów społecznościowych – Wykonawca w szczególności musi przekazać logi dokumentujące podjęte działania. Kampanie (outdoor’owe oraz w serwisach społecznościowych) muszą zostać przygotowane zgodnie ze szczegółową specyfikacją określoną w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. PZP.PROD.62 Konferencje spotkania informacyjne i Wykonawca przygotowując konferencję lub spotkanie informacyjne musi: a. zapewnić salę na terenie Wrocławia; lokalizacja musi zostać zaakceptowana przez Zamawiającego, b. przygotować dedykowane oznaczenia (przed oraz w budynku), pozwalające uczestnikom na dotarcie do właściwej sali, c. przygotować imienne identyfikatory dla uczestników, d. przygotować dla uczestników dedykowane materiały informacyjne zawierające m.in. agendę wydarzenia, e. zapewnić dla uczestników catering, w tym ciepłe dania obiadowe w przypadku, gdy konferencja/spotkanie informacyjne będzie trwało dłużej niż 3 godziny, f. przeprowadzić wśród uczestników ankietę oceniającą konferencję/spotkanie informacyjne; ankieta nie może być anonimowa. Ocenie w ankiecie muszą podlegać co najmniej następujące obszary: a. lokalizacja, b. przygotowane prezentacje, c. jakość wydrukowanych materiałów, d. przygotowanie sali, e. catering. Strona 33 z 81 Proces Zarządczo-Produkcyjny Skala wykorzystana do oceny ww. aspektów musi się składać z czterech następujących poziomów: a. 1 – bardzo złe, b. 2 – słabe, c. 3 – dobre, d. 4 – doskonałe. W przypadku, gdy średnia ocena z ankiet wszystkich uczestników biorących udział w danym wydarzeniu, dla każdego z obszarów, o których mowa powyżej (liczona dla każdego z obszarów osobno) będzie niższa niż 3 - wydarzenie będzie musiało zostać powtórzone i ponownie poddany ocenie zgodnie z zasadami opisanymi w niniejszym wymaganiu. Zamawiający zastrzega sobie prawo do nieskorzystania z ponownego przeprowadzenia wydarzenia. Potwierdzeniem realizacji konferencji/spotkania informacyjnego będzie przekazanie Zamawiającemu: a. podpisanej listy obecności przez uczestników konferencji/spotkania informacyjnego wraz z potwierdzeniem odebrania przez nich materiałów promocyjnych, b. ankiet oceniających konferencję/spotkanie wypełnionych przez uczestników, c. informacyjne zbiorczego podsumowania wyników z przekazanych ankiet, d. trzech kompletów materiałów przekazanych uczestnikom. PZP.PROD.63 Materiały promocyjne Każdy z materiałów promocyjnych musi zostać zaprojektowany przez Wykonawcę w co najmniej 2 wariantach istotnie różniących się od siebie. Wyboru wariantu dokonuje Zamawiający. Materiały promocyjne muszą zostać przygotowane zgodnie ze szczegółową specyfikacją określoną w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. PZP.PROD.64 Spoty radiowe Wykonawca musi opracować po 2 koncepcje i scenariusze dla każdego ze spotów radiowych, do dostarczenia których jest zobowiązany w ramach niniejszego Umowy. Wyboru spotów, które zostaną nagrane przez Wykonawcę dokonuje Zamawiający. Za pozyskanie lektorów oraz ścieżek dźwiękowych niezbędnych do nagrania spotów odpowiada Wykonawca. Wykonawca musi dostarczyć Zamawiającemu nagrane spoty radiowe przygotowane do emisji w formatach stosowanych w rozgłośniach radiowych oraz pliki w formacie mp3 umożliwiające odsłuchanie spotów. Zamawiający wymaga aby ww. materiał dostarczony był mu na płytach CD/DVD w 3 egzemplarzach. Wykonawca odpowiada za dostarczenie i wyemitowanie nagranych spotów w rozgłośniach radiowych. Strona 34 z 81 Proces Zarządczo-Produkcyjny PZP.PROD.65 Artykuły sponsorowane stronach www Artykuły sponsorowane publikowane na stronach www muszą zostać na przygotowane zgodnie ze szczegółową specyfikacją określoną w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. Opublikowane artykuły muszą zostać przekazane Zamawiającemu w postaciach, o których mowa w wymaganiu PZP.PROD.16, na płycie CD/DVD w 3 egzemplarzach. PZP.PROD.66 Ogłoszenia i artykuły Ogłoszenia i artykuły w prasie muszą zostać przygotowane zgodnie ze w prasie szczegółową specyfikacją określoną w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. Opublikowane ogłoszenia Zamawiającemu: i artykuły muszą zostać przekazane a) w postaciach, o których mowa w wymaganiu PZP.PROD.16, na płycie CD/DVD w 3 egzemplarzach b) w postaci 3 egzemplarze każdej z gazet codziennych/tygodników, w którym dane ogłoszenie/artykuł się ukazało. PZP.PROD.67 Pozycjonowanie stron www Pozycjonowanie stron musi zostać przygotowane zgodnie ze szczegółową specyfikacją określoną w dokumencie „PFU.Z6 Promocja – opis strategii i specyfikacja wymagań”. Strona 35 z 81 Proces Zarządczo-Produkcyjny 4. Wytyczne do wytwarzania produktów projektu 4.1. Dokumentacja Implementacyjna (DI) ID PZP.DI.01 Nazwa cechy Opis Dokumentacja Implementacyjna Wykonawca musi opracować Dokumentację Implementacyjną (DI), składającą się z: a. „ Analizy wymagań szczegółowych”, b. „Projektu wykonawczego”. PZP.DI.02 Analiza wymagań Wynikiem prac Wykonawcy prowadzonych w ramach analizy szczegółowych szczegółowej będzie dokument „Analiza wymagań szczegółowych”, który będzie obejmował zbiór wymagań szczegółowych oraz zbiór szczegółowych przypadków użycia dla każdego stadium Systemu. PZP.DI.03 Projekt wykonawczy Wynikiem prac Wykonawcy prowadzonych w ramach projektowania szczegółowego Systemu będzie dokument „Projekt wykonawczy”. 4.1.1. Analiza wymagań szczegółowych ID PZP.DI.04 Nazwa cechy Opis Analiza wymagań Analiza szczegółowa prowadzona przez Wykonawcę w Etapie szczegółowych – Technicznym 1 będzie obejmowała: zakres na Etap a. identyfikację wszystkich szczegółowych przypadków użycia Techniczny 1 Systemu, b. podział zidentyfikowanych szczegółowych przypadków użycia pomiędzy Etapy Techniczne (podział musi być spójny z podziałem na produkty wskazanym przez Zamawiającego w Umowie (w tym jej załącznikach), c. opracowanie dokumentu „Analiza wymagań szczegółowych” dla przypadków użycia wskazanych do przeanalizowania w ramach ET1, d. określenie dla każdego elementu kontentu listy obiektów, które będą opisywane (np. w przypadku PAISK.SP.201: Rozszerzony opis dla wybranych (najważniejszych) zabytków nieruchomych – podanie nazw obiektów, które zostaną opisane w kolejnych etapach). Strona 36 z 81 Proces Zarządczo-Produkcyjny PZP.DI.05 Analiza szczegółowa Analiza szczegółowa prowadzona przez Wykonawcę w ET 2 – ET 5 w Etapach będzie obejmowała doszczegółowienie DI przygotowanego w ET 1, w Technicznych 2-5 tym: a. potwierdzenie, że zidentyfikowane szczegółowe przypadki użycia opisują cały System lub - o ile zajdzie taka potrzeba - ich modyfikacja (np. dodanie/usunięcie/modyfikacja szczegółowego przypadku użycia), b. potwierdzenie utrzymania podziału zidentyfikowanych szczegółowych przypadków użycia pomiędzy Etapy Techniczne, w ramach których będą implementowane lub - o ile zajdzie taka konieczność – modyfikacja tego podziału (np. na skutek dodania szczegółowego przypadku użycia), c. doszczegółowienie dokumentu „Analiza wymagań szczegółowych” dla przypadków użycia wskazanych do realizacji (w tym implementacji) w ramach danego ET (tj. danego stadium Systemu). PZP.DI.06 Przypisanie przypadku użycia do jednego Etapu Technicznego Zamawiający nie dopuszcza, aby jeden szczegółowy przypadek użycia był przypisany do kilku Etapów Technicznych. Szczegółowy przypadek użycia musi być przypisany do tego Etapu Technicznego, w którym nastąpi jego przetestowanie i wdrożenie na środowisko produkcyjne (za wyjątkiem ET 1, w którym będzie prowadzana szczegółowa analiza, ale nie będą w tym etapie prowadzone prace nad implementacją, testami i wdrożeniem Systemu). PZP.DI.07 Analiza wymagań Dokument „Analiza wymagań szczegółowych” musi szczegółowych - następujące treści: zakres a. zestawienie aktorów, na które składać się będzie: zawierać i. diagram prezentujący wszystkich aktorów występujących w modelu opisującym System, ii. opis aktorów zaprezentowany w formie tabelarycznej, na który składać się będzie: a) identyfikator i nazwa aktora, b) opis aktora informujący o jego cechach istotnych z punktu widzenia Systemu, b. model szczegółowych przypadków użycia całego Systemu wraz z ich przypisaniem do etapu, w którym będą realizowane, c. analityczny model stadium systemu przedstawiony z perspektywy funkcjonalnie logicznie spójnych fragmentów Systemu (ujętych w kolejnych podrozdziałach dokumentu). Na każdy ww. logicznie spójny obszar składać się będzie: i. diagram szczegółowych przypadków użycia, ii. opis każdego szczegółowego znajdującego się na diagramie, przypadku użycia Strona 37 z 81 Proces Zarządczo-Produkcyjny iii. d. opis wszystkich wymagań szczegółowych powiązanych z danym szczegółowym przypadkiem użycia. logiczny model danych. PZP.DI.08 Analiza szczegółowa Dokument „Analiza szczegółowa” opracowany dla kolejnego stadium rozwój Systemu musi być rozwinięciem treści opracowanych dla poprzedniego stadium. Treści nowe w stosunku do treści dot. poprzedniego stadium muszą być wyraźnie wyróżnione. PZP.DI.09 Diagram aktorów PZP.DI.10 Wymagania z Każde wymaganie zawarte w Umowie (w tym jej załącznikach) musi być Umowy i wymagania uszczegółowione przez co najmniej jedno wymaganie szczegółowe. szczegółowe PZP.DI.11 Zbiór wymagań Zbiór wymagań szczegółowych będzie w trakcie całego projektu szczegółowych zarządzany przez Wykonawcę. W szczególności Wykonawca zapewni monitorowanie otoczenia legislacyjnego projektu jako źródła potencjalnych zmian w wymaganiach. Wykonawca zobowiązany jest przez cały czas trwania umowy i gwarancji dostosowywać dostarczony Zamawiającemu przedmiot umowy do obowiązujących regulacji prawnych. PZP.DI.12 Zmiany w otoczeniu projektu a rozwiązania zamienne PZP.DI.13 Wymagania szczegółowe analizie szczegółowej PZP.DI.14 Wymaganie szczegółowe opis PZP.DI.15 Wymaganie szczegółowe podziału Każde wymaganie szczegółowe musi być opisane w sposób jak forma najbardziej niepodzielny, tzn. aby była możliwość stwierdzenia (np. na etapie testów) że wymaganie jest realizowane w całości, a nie jedynie w pewnym jego fragmencie. PZP.DI.16 Wymaganie szczegółowe opisu Każde wymaganie szczegółowe musi być opisane co najmniej za forma pomocą następujących atrybutów: Diagram aktorów musi zawierać (tzn. prezentować) informacje nt. generalizacji aktorów, o ile takowa będzie występowała. Wykonawca ma obowiązek monitorowania otoczenia projektu. Jeśli Wykonawca stwierdzi zasadność wprowadzenia rozwiązań zamiennych zobowiązany jest zastosować się do zapisów zawartych w Umowie w szczególności dot. rozwiązań zamiennych. Wymagania szczegółowe muszą być zidentyfikowane przez Wykonawcę w na etapie prowadzonej przez niego analizy szczegółowej. Każde wymaganie szczegółowe musi być opisane w sposób zrozumiały i jednoznaczny dla Zamawiającego. a. unikalny identyfikator wymagania szczegółowego – oznaczenie jednoznacznie identyfikujące wymaganie, które nie może ulegać zmianom (identyfikator raz nadany wymaganiu nie może zostać zmieniony), b. nazwa wymagania szczegółowego – krótki opis sygnalizujący treść wymagania, Strona 38 z 81 Proces Zarządczo-Produkcyjny PZP.DI.17 Wersjonowanie wymagań szczegółowych c. opis – szczegółowa treść wymagania zawierająca w szczególności opis sposobu jego realizacji (tj. odpowiedź na pytanie: jak dane wymaganie szczegółowe będzie zaimplementowane w systemie?”), d. sposób weryfikacji wymagania szczegółowego– określenie, czy weryfikacja spełnienia wymagania będzie odbywała się z użyciem metody ilościowej czy jakościowej, e. status wymagania szczegółowego – określa status wymagania w cyklu życia, minimalny zestaw statusów to: i. zidentyfikowane – wymaganie, które zostało zidentyfikowane przez analityka Wykonawcy i wymaga dalszych uzgodnień lub analizy, ii. zdefiniowane – wymaganie dla którego zakończono analizę, iii. do poprawy – wymaganie, które wymaga modyfikacji na skutek uwag Zamawiającego, iv. zaakceptowane – wymaganie które zostało zaakceptowane przez Zamawiającego lub osobę przez niego upoważnioną, v. odrzucone – wymaganie, które zostało odrzucone przez Zamawiającego lub osobę przez niego upoważnioną, f. wersja - numer kolejnej wersji wymagania, g. źródło – wskazanie wymagania lub wymagań z Umowy (w tym jej załącznikach), z których bezpośrednio wynika wymaganie szczegółowe. h. aktualizacja – jednoznacznie wskazane zdarzenie (rozumiane jako np. data konkretnego spotkania, warsztatów analitycznych, data przesłania oraz autor maila), w trakcie którego uzgodniono aktualny kształt danego wymagania szczegółowego. Wersjonowanie wymagań szczegółowych musi zapewniać, że: a. kolejna wersja wymagania powstaje po każdej wprowadzonej zmianie, b. dokonana zmiana musi być skomentowana, c. możliwa jest identyfikacja osoby, która dokonała zmiany. Strona 39 z 81 Proces Zarządczo-Produkcyjny PZP.DI.18 Sposób określania Sposób określania identyfikatorów wymagań szczegółowych musi identyfikatorów zapewniać ich jednoznaczną identyfikację oraz: wymagań a. jednoznaczne określenie, czy jest to wymaganie funkcjonalne szczegółowych czy pozafunkcjonalne, b. numer wymagania, c. w przypadku wymagań pozafunkcjonalnych jednoznaczne określenie kategorii wymagań pozafunkcjonalnych (zgodnie w obowiązującą w projekcie kategoryzacją wymagań pozafunkcjonalnych). PZP.DI.19 Wymagania szczegółowe pozafunkcjonalne Każde wymaganie szczegółowe pozafunkcjonalne przyporządkowane wyłącznie do jednej kategorii. musi być PZP.DI.20 Wymagania szczegółowe powiązane hierarchicznie Wymagania szczegółowe muszą być powiązane ze sobą w sposób hierarchiczny, tj. wymaganie podrzędne musi stanowić uszczegółowienie wymagania nadrzędnego. PZP.DI.21 Dodanie wymagania Dodanie wymagania szczegółowego do zbioru wymagań nie może szczegółowego zaburzać struktury dotychczas zidentyfikowanych wymagań. PZP.DI.22 Zbiór wymagań Zbiór wymagań szczegółowych przedstawiany Zamawiającemu (lub szczegółowych osobom przez niego wskazanym) do akceptacji musi być zweryfikowany przez Wykonawcę pod względem niesprzeczności oraz poprawności logicznej (w tym także poprawności powiązań pomiędzy wymaganiami). PZP.DI.23 Kompletny zbiór Wykonawca musi zapewnić, że opracowany zbiór wymagań wymagań szczegółowych będzie kompletny tj. będzie opisywał cały projektowany szczegółowych System oraz ewentualnie definiować będzie wymagania na inne systemy stanowiące otoczenie budowanego systemu. PZP.DI.24 Uszczegółowienie wymagań z Umowy Każdy przypadek użycia zawarty w Umowie musi być uszczegółowiony przez co najmniej jeden szczegółowy przypadek użycia. PZP.DI.25 Identyfikacja szczegółowych przypadków użycia Szczegółowe przypadki użycia muszą być zidentyfikowane przez Wykonawcę na etapie prowadzonej przez niego analizy szczegółowej. PZP.DI.26 Szczegółowy przypadek użycia Każdy szczegółowy przypadek użycia musi stanowić zestaw czynności mających określony, istotny z punktu widzenia aktora cel. PZP.DI.27 Szczegółowy Każdy szczegółowy przypadek użycia musi być opisany co najmniej za przypadek użycia – pomocą następujących atrybutów: opis a. unikalny identyfikator przypadku użycia, b. nazwa szczegółowego przypadku użycia, c. Etap Techniczny – numer etapu technicznego, w którym szczegółowy przypadek użycia będzie realizowany, d. opis przypadku użycia - opis definiujący cel realizacji przypadku Strona 40 z 81 Proces Zarządczo-Produkcyjny użycia rozpoczynający się od słów „Celem przypadku użycia jest”, e. scenariusze – kroki realizacji przypadku użycia, f. warunki wejścia – warunki, które muszą być spełnione aby możliwe było rozpoczęcie realizacji przypadku użycia, g. warunki wyjścia – stan lub stany, w którym można uznać, że przypadek użycia zakończył się realizować, h. status przypadku użycia – określa status przypadku użycia na drodze do ostatecznego jego zaakceptowania; minimalny zestaw statusów to: i. Zidentyfikowany – przypadek użycia, który został zidentyfikowany przez analityka Wykonawcy i wymaga dalszych uzgodnień lub analizy, ii. Zdefiniowany – przypadek zakończono analizę, iii. Do poprawy – przypadek użycia, który wymaga modyfikacji na skutek uwag Zamawiającego, iv. Zaakceptowany – przypadek użycia który został zaakceptowane przez Zamawiającego lub osobę przez niego upoważnioną, v. Odrzucony – przypadek użycia, który został odrzucony przez Zamawiającego lub osobę przez niego upoważnioną, użycia dla którego i. wersja - numer kolejnej wersji przypadku użycia, j. źródło – źródło, na bazie którego przypadek użycia powstał (np. spotkanie z dnia…, email od … z dnia …), k. powiązane przypadki użycia z Umowy (w szczególności opisanych w dokumencie „PFU.Z1 Wymagania funkcjonalne dla platformy”) – wskazanie przypadku lub przypadków użycia z Umowy, z których bezpośrednio wynika szczegółowy przypadek użycia. PZP.DI.28 Szczegółowy Każdy szczegółowy przypadek użycia musi być opisany za pomocą przypadek użycia - jednego scenariusza głównego (scenariusz oczekiwany). scenariusz PZP.DI.29 Szczegółowy Każdy szczegółowy przypadek użycia musi być opisany za pomocą co przypadek użycia – najmniej jednego scenariusza alternatywnego. Liczba scenariuszy scenariusz alternatywnych uzależniona jest od liczby możliwych zachowań danego alternatywny szczegółowego przypadku użycia. Strona 41 z 81 Proces Zarządczo-Produkcyjny PZP.DI.30 Scenariusz Każdy scenariusz szczegółowego przypadku użycia musi: szczegółowego a. opisywać interakcję aktora z systemem, która odbywa się przypadku użycia – wyłącznie w ramach jednego, opisywanego przypadku użycia zakres (z zaznaczeniem ewentualnych punktów rozszerzeń), b. składać się z na przemian występujących po sobie działań podejmowanych przez aktora oraz system, c. być przyporządkowany do odpowiedniego warunku wyjścia określonego dla tego szczegółowego przypadku użycia, d. mieć ponumerowane wszystkie kroki, e. mieć wszystkie kroki opisane zgodnie z następującym schematem: [podmiot] [orzeczenie] [dopełnienie]. PZP.DI.31 Scenariusz alternatywny opis PZP.DI.32 Scenariusz dłuższy Dla scenariusza, który składa się z co najmniej 7 kroków musi zostać niż 7 kroków opracowany diagram czynności (ang. activity diagram). Jeden diagram czynności musi opisywać wyłączenie jeden scenariusz. PZP.DI.33 Analiza szczegółowa W dokumencie „Analiza szczegółowa” musi zostać przejrzyście – listy scenariuszy zaprezentowana lista scenariuszy opisujących dany szczegółowy przypadek użycia wraz z informacją na temat tego, czy dany scenariusz to scenariusz główny czy alternatywny. PZP.DI.34 Analiza szczegółowa – prezentacja szczegółowych relacji PZP.DI.35 Treść scenariusza W treści scenariusza głównego nie mogą znajdować się odwołania do głównego scenariuszy alternatywnych. PZP.DI.36 Wersjonowanie szczegółowych przypadków użycia PZP.DI.37 Identyfikator szczegółowego przypadku użycia Scenariusz alternatywny to logicznie zestaw kroków scenariusza głównego, który został zmodyfikowany o kroki, które realizowane są inaczej niż w scenariusz głównym. Scenariusz alternatywny nie może powielać treści scenariusza głównego (oczekiwanego), a jedynie musi wskazywać (poprzez oznaczenie literowe, np. 4a) kroki, które w danym scenariuszu realizowane są inaczej niż w scenariuszu głównym. Scenariusza alternatywnego nie należy jednak utożsamiać wyłącznie z krokami alternatywnych (np. 4a), które zaistnieją po spełnieniu danego warunku. W dokumencie „Analiza szczegółowa” muszą zostać przejrzyście zaprezentowane scenariusze do których zostały włączone (relacja Include lub Extend) scenariusze szczegółowych przypadków użycia, które rozszerzają opisywany szczegółowy przypadek użycia. Wersjonowanie szczegółowych przypadków użycia musi zapewniać, że: a. kolejna wersja szczegółowego przypadku użycia powstaje po każdej wprowadzonej zmianie, b. dokonana zmiana musi być skomentowana, c. możliwa jest identyfikacja osoby, która dokonała zmiany. Identyfikator szczegółowego przypadku użycia musi być zbudowany zgodnie ze schematem, w którym uwzględniony będzie obszar, którego dany szczegółowy przypadek użycia dotyczy. Strona 42 z 81 Proces Zarządczo-Produkcyjny PZP.DI.38 Szczegółowy Każdy szczegółowy przypadek użycia musi być powiązany: przypadek użycia a. ze wszystkimi wymaganiami szczegółowymi, powiązania charakteryzują sposób jego realizacji, b. wyłącznie z tymi wymaganiami szczegółowymi, charakteryzują sposób jego realizacji. które które PZP.DI.39 Szczegółowy Szczegółowe przypadki użycia muszą być pogrupowane (np. w przypadek użycia narzędziu wspierającym modelowanie - w pakiety) zgodnie z obszarami grupowanie funkcjonalnymi, których dotyczą. Ww. elementy grupujące (np. pakiety) mogą podlegać dalszemu grupowaniu (np. w pakiety). PZP.DI.40 Zbiór szczegółowych Zbiór szczegółowych przypadków użycia przekazany Zamawiającemu przypadków użycia - (lub osobom przez niego wskazanym) musi być zweryfikowany przez weryfikacja Wykonawcę pod względem niesprzeczności oraz poprawności logicznej. PZP.DI.41 Zbiór szczegółowych Wykonawca musi zapewnić, że opracowany zbiór szczegółowych przypadków użycia - przypadków użycia będzie kompletny, tj. będzie opisywał cały kompletność projektowany System. PZP.DI.42 Analityczny systemu PZP.DI.43 Szczegółowe Zamawiający oczekuje zapewnienia czytelności diagramów przypadki użycia - szczegółowych przypadków użycia, w szczególności, zapewnienia diagramy odpowiedniej liczby elementów na jednym widoku. W przypadku, gdy Zamawiający uzna diagram za zbyt mało przejrzysty – zastrzega sobie prawo do wnioskowania o jego podzielenie tak, aby zawierał nie więcej niż dziewięć elementów (aktorów i szczegółowych przypadków użycia). PZP.DI.44 Szczegółowe Diagram szczegółowych przypadków użycia przekazany Zamawiającemu przypadki użycia – (lub osobom przez niego wskazanym) musi być zweryfikowany przez weryfikacja Wykonawcę pod względem niesprzeczności oraz poprawności logicznej. diagramów model Analityczny model systemu składa się ze wszystkich diagramów szczegółowych przypadków użycia obejmując tym samym całą funkcjonalność projektowanego systemu. Zamawiający nie oczekuje od Wykonawcy, aby ten przedstawił analityczny model systemu na jednym diagramie (aby połączył wszystkie diagramy w jeden). Strona 43 z 81 Proces Zarządczo-Produkcyjny PZP.DI.45 Diagram Diagram szczegółowych przypadków użycia musi: szczegółowych a. być przedstawiony w formie graficznej, przypadków użycia b. obejmować co najmniej jednego aktora, jeden szczegółowy zakres przypadek użycia oraz relacje pomiędzy nimi, c. PZP.DI.46 zawierać powiązane elementy, tj.: i. szczegółowy przypadek użycia na diagramie szczegółowych przypadków użycia musi być powiązany z co najmniej jednym aktorem lub szczegółowym przypadkiem użycia, ii. aktor na diagramie szczegółowy przypadków użycia musi być powiązany z co najmniej jednym aktorem lub szczegółowy przypadkiem użycia, d. prezentować fragment logicznie ze sobą powiązanych funkcjonalności (dotyczy diagramu, na którym prezentowany jest więcej niż jeden szczegółowy przypadek użycia), e. prezentować informację na temat. punktów rozszerzeń (z ang. Extension points) o ile takie występują, f. prezentować: i. po lewej stronie szczegółowego przypadku użycia aktorów inicjujących dany szczegółowy przypadek użycia, ii. po prawej stronie szczegółowego przypadku użycia – aktorów inicjowanych przez dany szczegółowy przypadek użycia. Analiza wymagań W dokumencie „Analiza wymagań szczegółowych” muszą zostać w szczegółowych – sposób czytelny zaprezentowane powiązania: prezentacja a. wszystkich szczegółowych przypadków użycia powiązanych z powiązań konkretnym przypadkiem użycia z Umowy, b. wszystkich przypadków użycia z Umowy powiązanych z konkretnym szczegółowym przypadkiem użycia, c. wszystkich wymagań szczegółowych konkretnym wymaganiem z Umowy, d. wszystkich wymagań z Umowy powiązanych z konkretnym wymaganiem szczegółowym, e. wszystkich wymagań szczegółowych powiązanych konkretnym szczegółowym przypadkiem użycia, f. wszystkich szczegółowych przypadków użycia powiązanych z konkretnym wymaganiem szczegółowym. powiązanych z z Strona 44 z 81 Proces Zarządczo-Produkcyjny PZP.DI.47 Testy funkcjonalne Testom funkcjonalnym może podlegać wyłącznie ten szczegółowy przypadek użycia, dla którego wszystkie wymagania szczegółowe zostały zrealizowane. Zamawiający na wniosek Wykonawcy może dopuścić do testów szczegółowy przypadek użycia, dla którego nie są zrealizowane wszystkie wymagania szczegółowe. W takiej sytuacji niespełnione mogą być wyłącznie wymagania z grupy wymagań pozafunkcjonalnych. PZP.DI.48 Zbiór wymagań szczegółowych oraz zbiór szczegółowych przypadków użycia – wgląd dla Zamawiającego Zamawiający wymaga zapewnienia wglądu w powstający zbiór wymagań szczegółowych oraz zbiór szczegółowych przypadków użycia na etapie ich opracowywania przez Wykonawcę. Uzgodnienie sposobu dostępu do wyników prac analitycznych zostanie podjęte na etapie realizacji prac. 4.1.2. Projekt wykonawczy ID Nazwa cechy Opis PZP.DI.49 Projekt wykonawczy Wykonawca zobowiązany jest do przedstawienia Zamawiającemu na poziomie projektu wykonawczego rozwiązania na poziomie infrastruktury infrastruktury technicznej, który zapewni realizację wymagań funkcjonalnych oraz pozafunkcjonalnych zdefiniowanych na System i opisanych w Umowie. PZP.DI.50 Prace projektowe w Prace o charakterze projektowym prowadzone przez Wykonawcę w ET1 Etapie Technicznym będą obejmowały: 1 zakres a. opracowanie architektury logicznej całego systemu b. PZP.DI.51 opracowanie dokumentu „Projekt wykonawczy” dla fragmentu systemu, który został wskazany do zaprojektowania w kolejnym Etapie Technicznym. Prace projektowe w Prace o charakterze projektowym prowadzone przez Wykonawcę w ET Etapach 2 – ET 5 będą obejmowały: Technicznych 2-5 a. weryfikację opracowanie architektury logicznej całego systemu zakres oraz – o ile zajdzie taka potrzeba – jej aktualizację, b. opracowanie dokumentu „Projekt Wykonawczy” dla fragmentu systemu, który został wskazany do realizacji w danym Etapie Technicznym. PZP.DI.52 Projekt Techniczny kolejne stadium Systemu „Projekt wykonawczy” kolejnego stadium Systemu musi powstać przez rozwinięcie „Projektu wykonawczego” dla poprzedniego stadium. Elementy, które zostały zaprojektowane w czasie bieżącego projektowania muszą zostać wyraźnie wyróżnione. PZP.DI.53 Projekt wykonawczy Dokument „Projekt wykonawczy” musi opisywać: - środowiska a. środowisko developerskie oraz asemblacji, b. środowisko testowe, Strona 45 z 81 Proces Zarządczo-Produkcyjny c. środowisko produkcyjne. PZP.DI.54 Projekt wykonawczy Poszczególne elementy „Projektu wykonawczy” muszą jasno – wskazanie wskazywać, którego środowiska dotyczą i jak te środowiska mają się do środowiska siebie (o ile ma to uzasadnienie). PZP.DI.55 Projekt techniczny – Dokument „Projekt wykonawczy” musi obejmować następujące zakres elementy: PZP.DI.56 a. Powiązanie z modelem analitycznym b. Model architektury, c. Model fizyczny, d. Model projektowy, e. Interfejs użytkownika, f. Plan wdrożenia, g. Dokumentacja procesu wytwórczego, h. Dokumentacja kontentu. Projekt wykonawczy Powiązanie z modelem analitycznym musi zawierać co najmniej – powiązania z następujące informacje: modelem a. diagramy sekwencji obejmujące wymieniane komunikaty analitycznym opracowane dla szczegółowych przypadków użycia zdefiniowanych na etapie analizy szczegółowej. b. PZP.DI.57 wskazanie, które elementy „Analizy wymagań szczegółowych” są realizowane/uszczegóławiane przez poszczególne elementy „Projektu wykonawczego”. Model architektury Model architektury musi zawierać co najmniej następujące informacje: zakres a. model architektury logicznej - opisuje: b. i. ogólną koncepcję architektoniczną na poziomie logicznym, ii. komponenty (wraz ze wskazaniem oprogramowania, za pomocą którego będzie dany komponent realizowany), iii. interfejsy logiczne pomiędzy komponentami Systemu oraz Systemem i systemami zewnętrznymi, model architektury technicznej - opisuje: i. oprogramowanie standardowe i moduły użyte do budowy Systemu, ii. oprogramowanie oprogramowania dedykowane, powód wyboru dedykowanego zamiast użycia Strona 46 z 81 Proces Zarządczo-Produkcyjny oprogramowania standardowego, iii. konfigurację oprogramowania, iv. opis interfejsów z systemami zewnętrznymi obejmujący techniczne rozwiązanie sposobu komunikacji i specyfikację jej zawartości, v. opis interfejsów między komponentami Systemu, obejmujący techniczne rozwiązanie sposobu komunikacji i specyfikację jej zawartości, vi. opis funkcji udostępnianych przez komponenty Systemu, znaczenie, parametry wejściowe, parametry wyjściowe, działanie, wykorzystanie (skąd wywoływane), vii. rozmieszczenie oprogramowania w architekturze fizycznej (z podziałem na środowisko produkcyjne oraz testowe), Ponadto, dla: i. platformy systemowej: a) platforma systemowa, b) powiązanie z urządzeniem, c) podstawowe parametry (nazwa, wersja, dystrybucja), dodatkowe informacje. ii. platformy bazodanowej: a) producent, b) rodzaj i wersja RDBMS, c) wymagany system operacyjny. Strona 47 z 81 Proces Zarządczo-Produkcyjny PZP.DI.58 Dokumentacja procesu wytwórczego zakres Dokumentacja procesu wytwórczego musi zawierać co najmniej następujące informacje: - a. opis standardów pisania kodów źródłowych obejmujący co najmniej: iii. schemat nazewnictwa plików kodu źródłowego, i. schemat organizacji plików kodu źródłowego, ii. konwencje nazewnicze, iii. konwencję formatowania wyrażeń języka, iv. konwencje deklarowania klas i interfejsów, v. konwencje dokumentowania kodu. Konwencja zapisu kodu źródłowego musi zostać przygotowana dla każdego języka programowania wykorzystywanego przez Wykonawcę w ramach realizacji prac. b. PZP.DI.59 PZP.DI.60 Model zakres fizyczny opis wykorzystanych technologii programowania, biblioteki). (w tym: języki - Model fizyczny musi zawierać co najmniej następujące informacje: a. szczegółowy opis dostarczonego sprzętu obejmujący: a. nazwę/typ urządzenia, b. rolę w systemie, c. podstawowe parametry, d. numer seryjny. b. architekturę fizyczną, c. architekturę sieciową - obejmującą co najmniej schemat fizycznych połączeń sieciowych pomiędzy elementami Systemu, d. projekt instalacji dostarczanego sprzętu w serwerowni Zamawiającego z uwzględnieniem istniejącej infrastruktury sieciowej (zapewnianej w ramach MIT) lub projekt instalacji kompletnej infrastruktury sprzętowo-sieciowej niezbędnej do uruchomienia Systemu, e. konfigurację serwerów. urządzeń włączając systemy operacyjne Model projektowy - Model projektowy musi zawierać co najmniej następujące informacje: zakres a. diagram ERD, b. model fizyczny bazy danych, c. kanoniczny model danych, Strona 48 z 81 Proces Zarządczo-Produkcyjny d. usługi udostępniane, systemy, konsumowane przez integrowane e. interfejsy międzysystemowe, f. wszystkie obiekty danych (obiekty używane w przyjętych technologiach do gromadzenia i dostępu do danych) wykorzystywane w celu realizacji zakładanej funkcjonalności, g. kompletną listę relacji planowanych do implementacji w mechanizmach zarządzania danymi, h. opisy przeznaczenia obiektów – ich zastosowanie oraz specyfikację techniczną, i. listę pól z opisem ich zastosowania oraz specyfikacją techniczną (typ, długość, inne parametry jeśli istnieją), j. listę triggerów, procedur składowanych wraz z opisem ich działania i wykorzystania, k. podział bazy na tabele, l. określenie partycjonowania obiektów, m. określenie indeksów, n. PZP.DI.61 stopnia zrównoleglenia podczas dostępu do obiektów. Interfejs Interfejs użytkownika użytkownika - zakres informacje: musi zawierać co najmniej opisujące następujące a. szablony prezentacji prezentowanych danych, style formatów b. graficzny kształt elementów interfejsu użytkownika, c. poszczególne ekrany (w tym formularze) prezentujące układ, rozmieszczenie poszczególnych elementów i danych oraz style formatów. Ww. wymagania dotyczą portalu oraz aplikacji mobilnych. PZP.DI.62 Plan wdrożenia zakres - Plan wdrożenia musi zawierać co najmniej następujące informacje: a. procedury wdrożenia (opisane w taki sposób, aby była możliwość przeprowadzenia wdrożenia bez konieczności pozyskiwania dodatkowych informacji), b. wymagane zasoby (wszystkie niezbędne zasoby do przeprowadzenia prac wdrożeniowych – zarówno zasoby materialne jak i zasoby ludzkie po stronie Wykonawcy), c. harmonogram wdrożenia, d. wariant awaryjny (w przypadku nieudanego wdrożenia). Strona 49 z 81 Proces Zarządczo-Produkcyjny PZP.DI.63 Dokumentacja Kontentu informacyjnego zakres Dokumentacja Kontentu informacyjnego musi zawierać co najmniej następujące informacje: - a. wskazanie narzędzi do budowy kontentu oraz ontologii (dla narzędzi typu COTS niezbędne jest wskazanie dokumentacji technicznej, dla narzędzi budowanych w ramach realizacji przedmiotu zamówienia – musi zostać przekazana kompletna dokumentacja techniczna zawierająca co najmniej architekturę rozwiązania: moduły oraz ich funkcjonalności narzędzia oraz dokumentacja użytkownika), b. model konceptualny zawartości informacyjnej, c. opis przyjętej metodyki tworzenia ontologii dziedzinowych, d. wykaz wykorzystywanych klasyfikacji oraz standardów wymiany informacji obowiązujących w Europie (np. MARC21, GEDCOM), e. dla każdej dziedziny – ontologię przygotowaną w narzędziu informatycznym zapewniającym jej wizualizację zgodnie ze specyfikacją abstrakcyjnej składni OWL2, f. lista obiektów (konkretne wystąpienia tj. podanie nazwy obiektu), dla których w załączniku nr 1 do dokumentu: PFU.Z5 „Architektura informacji i specyfikacja kontentu” wskazano enumeratywnie wymaganą liczbę obiektów do opracowania. PZP.DI.64 Dokumentacja Przygotowywany dla kontentu informacyjnego model domenowy musi Kontentu być przygotowany zgodnie z wymaganiami wskazanymi w dokumencie informacyjnego – PFU.Z5 „Architektura informacji i specyfikacja kontentu”. model domenowy PZP.DI.65 Oprogramowanie – W przypadku oprogramowania tworzonego przez Wykonawcę, dla język każdego z elementów Systemu musi być wyraźnie zaznaczone w jakim programowania języku programowania został on zaimplementowany. Zamawiający dopuszcza wskazanie wiodącego języka programowania na poziomie całego Systemu, oraz wskazanie odstępstw dla poszczególnych komponentów Systemu. PZP.DI.66 Projekt wykonawczy PZP.DI.67 Projekt wykonawczy „Projekt wykonawczy” musi pozostawać spójny wewnętrznie oraz z - spójność wynikami analizy szczegółowej. PZP.DI.68 Projekt wykonawczy „Projekt wykonawczy” w zakresie definiowania komunikacji z innymi - zakres systemami musi obejmować: „Projekt wykonawczy” musi zawierać zestawienia ustalające jasną referencję pomiędzy jego elementami a elementami zdefiniowanymi na etapie analizy szczegółowej. a. opis wymienianych danych z odniesieniem do modelu danych, b. opis protokołu wymiany danych, c. kierunek przepływu informacji. Strona 50 z 81 Proces Zarządczo-Produkcyjny PZP.DI.69 Projekt wykonawczy „Projekt wykonawczy” będzie przez cały czas trwania projektu aktualność utrzymywany przez Wykonawcę, w szczególności będzie utrzymywana jego aktualność. PZP.DI.70 Projekt wykonawczy Zamawiający wymaga zapewnienia wglądu w powstający „Projekt wgląd dla wykonawczy”, w ciągi 2 dni roboczych od zgłoszenia takiej potrzeby Zamawiającego przez Zamawiającego. Ww. materiał musi być przekazany Zamawiającemu drogą mailową lub na płycie CD/DVD (zgodnie z przyjętym przez strony ustaleniem). 4.2. Kod źródłowy ID Nazwa cechy Opis PZP.TES.01 Asemblacja kodu źródłowego Każdorazowo podczas przekazania kodów źródłowych Wykonawca jest zobowiązany do wykonania asemblacji (kompilacji) przekazywanych kodów źródłowych. PZP.TES.02 Przekazanie kodów źródłowych Wykonawca jest zobowiązany przekazać Zamawiającemu kod źródłowy aplikacji oraz komplet skryptów i narzędzi potrzebnych do wykonania asemblacji i instalacji poprawnie działającej aplikacji. PZP.TES.03 Przekazanie kodów źródłowych w postaci elektronicznej Przekazywany Zamawiającemu w postaci elektronicznej kod źródłowy musi być zgodny z przyjętą konwencją zapisu kodu źródłowego. PZP.TES.04 Przekazanie kodów źródłowych – parametry konfiguracji Wraz z przekazywanym kodem źródłowym Wykonawca przekaże zestawienie użytych parametrów konfiguracyjnych środowiska wytwarzania i budowy kodu (środowisko asemblacji) oraz instrukcję umożliwiającą jego przygotowanie i poprawne przeprowadzenie asemblacji. PZP.TES.05 Skuteczne przekazanie kodów źródłowych Kod źródłowy (stanowiący element składowy produktu jakim jest oprogramowanie) uważa się za przekazany skutecznie po pozytywnym przejściu testu asemblacji. PZP.TES.06 Stopień skomentowania kodu Stopień skomentowania kodu musi być wystarczający do zrozumienia jego logiki przez osobę o podstawowych umiejętnościach programistycznych w danym języku programowania. Strona 51 z 81 Proces Zarządczo-Produkcyjny PZP.TES.07 Przygotowanie środowiska asemblacji Środowisko asemblacji na którym wykonana zostanie asemblacja kodu przygotowane będzie przez Wykonawcę w obecności Inżyniera Kontraktu (o ile o taki udział zawnioskuje Zamawiający). Środowisko musi być przygotowane zgodnie z przygotowaną przez Wykonawcę „instrukcją przygotowania środowiska asemblacji”. Zamawiający nie dopuszcza podczas przygotowywania środowiska asemblacji: a. wykonywania innych działań niż te opisane w instrukcji , b. wykonywania działań w innej kolejności niż opisanej w instrukcji. PZP.TES.08 Instrukcja przygotowania środowiska asemblacji „Instrukcją przygotowania środowiska asemblacji” musi zawierać wszystkie konieczne do wykonania kroki wraz z wartościami parametrów podlegających konfiguracji. PZP.TES.09 Instrukcja przygotowania środowiska asemblacji - zakres „Instrukcją asemblacji kodu źródłowego” musi zawierać wszystkie konieczne do wykonania kroki wraz z wartościami parametrów podlegających konfiguracji. Instrukcja ta musi zostać przekazana Zamawiającemu przed rozpoczęciem testów asemblacji. PZP.TES.10 Asemblacja kodu źródłowego Asemblacja kodu źródłowego będzie wykonana przez Wykonawcę w obecności Inżyniera Kontraktu. Proces asemblacji kodu musi być prowadzony zgodnie z przygotowaną przez Wykonawcę „instrukcją asemblacji kodu źródłowego”. Zamawiający nie dopuszcza podczas asemblacji kodu źródłowego: a. wykonywania innych działań niż te opisane w instrukcji , b. wykonywania działań w innej kolejności niż opisanej w instrukcji. PZP.TES.11 Asemblacja kodu źródłowego przez przedstawicieli Zamawiającego Zamawiający zastrzega sobie prawo do wykonania asemblacji przez własnych przedstawicieli, w którym to przypadku Wykonawca jest zobowiązany do wsparcia Zamawiającego podczas tych prac. PZP.TES.12 Ponowna asemblacja kodu źródłowego W wypadku gdyby proces asemblacji nie powiódł się z przyczyn leżących po stronie przygotowania środowiska, kodu, instrukcji itd., kolejna próba będzie mogła być wykonana dopiero po wykonaniu niezbędnych poprawek oraz zgłoszeniu przez Wykonawcę gotowości. Nazwa cechy Opis Testy Wykonawca zobowiązany jest zaplanować i przeprowadzić: 4.3. Testy ID PZP.TES.13 Strona 52 z 81 Proces Zarządczo-Produkcyjny a. Testy wewnętrzne, b. Testy akceptacyjne wydania – na które składają się: c. PZP.TES.14 Testy wydajnościowe zakres przeprowadzenie I. Testy asemblacji (testy procedur tworzenia paczek instalacyjnych), II. Testy instalacji wydania, III. Testy funkcjonalne, IV. Testy pozafunkcjonalne, V. Testy użyteczności (z ang. usability), VI. Testy integracyjne (usług) – weryfikacja integracji Systemu z jego otoczeniem lub wybranych elementów Systemu, VII. Testy bezpieczeństwa, VIII. Testy procesowe (end to end), IX. Testy regresji, X. Testy wydajnościowe, XI. Testy procedur utrzymaniowych, XII. Autorecenzje kontentu Testy powdrożeniowe – przeprowadzane w celu zweryfikowania poprawności pracy Systemu po zakończeniu każdego wdrożenia. Testy wydajnościowe: Testy muszą składać się z ciągu wywołań – webService’ów lub ekranów aplikacji, które symulują zachowanie i użytkownika systemu takie jak logowanie do aplikacji, przechodzenie pomiędzy stronami, klikanie na przyciskach, uzupełnianie i zapisywanie danych na formularzach, przeglądanie mapy wraz z warstwami mapowymi. Uruchamiane są również webService’y, których wywołanie nie jest wymuszane przez działania użytkownika, ale są one niezbędne do prawidłowego zachowania systemu (tworzenie, obsługa i zamykanie komponentów). Pomiędzy krokami, w których wpisywane są dane do systemu, dodane zostanie opóźnienie konfigurowane parametrem, mające na celu zasymulowanie zachowania użytkownika systemu (czas wpisywania danych). Testy te musza być wykonywane z wykorzystaniem narzędzia typu JMeter. PZP.TES.15 Testy przeciążeniowe Testy wydajnościowe: Testy muszą obejmować również testy przeciążeniowe (wysyceniowe). PZP.TES.16 Testy wydajnościowe automatyzacja Testy wydajnościowe: Wykonawca zobowiązany jest do przeprowadzenia testów wydajnościowych, podczas których wykorzystane zostaną narzędzia pozwalające na automatyzację testów tak aby zasymulować pracę maksymalnej liczby równocześnie Strona 53 z 81 Proces Zarządczo-Produkcyjny zalogowanych użytkowników (zgodnie z wymaganiami zawartymi w Umowie) np. przy zastosowaniu narzędzi typu, Unit, Rational Performance Test Serwer i równoważnych. PZP.TES.17 Testy bezpieczeństwa Testy bezpieczeństwa: Testom podlegać przeznaczone na środowisko produkcyjne. PZP.TES.18 Testy bezpieczeństwa zakres Testy bezpieczeństwa: Testy muszą obejmować: PZP.TES.19 Testy użyteczności będzie środowisko a. testy prowadzone zdalnie z zewnątrz (z Internetu) mające na celu określenie poziomu bezpieczeństwa aplikacji portalowej, b. testy prowadzone z poziomu poszczególnych stref DMZ/segmentów sieci - odnoszą się do środowiska wykonania Systemu. Ich celem jest ocena zabezpieczeń infrastruktury serwerowej (platform systemowych, serwerów http/s, serwerów Proxy, serwerów aplikacyjnych), c. testy bezpieczeństwa baz danych - z poziomu użytkownika portalu, d. test bezpieczeństwa infrastruktury sieciowej, e. testy lokalne serwerowej infrastruktury (aktualizacja patchy, błędy w konfiguracji kont i uprawnień, uprawnienia serwisów/demonów, zabezpieczenia partycji dysków, prawa dostępu do plików i katalogów, błędy w polityce audytu zdarzeń, błędy w zabezpieczeniach systemowych), f. atak na konto użytkownika (w tym administratora i klienta) Portalu (przeprowadzenie ataku na portal za pomocą zaatakowania komputera użytkownika portalu i wykorzystania podatności po stronie użytkownika). Testy użyteczności: Wykonawca zobowiązany jest do przeprowadzenia wiarygodnych testów użyteczności, które będą miały na celu poprawienie ergonomii oraz intuicyjności interfejsu użytkownika, w wykonanie których zostanie zaangażowana reprezentatywna próba użytkowników Systemu. Działania użytkowników wykonywane podczas testów muszą być rejestrowane poprzez dedykowane oprogramowanie. Strona 54 z 81 Proces Zarządczo-Produkcyjny PZP.TES.20 Testy użyteczności – Testy użyteczności: Wykonawca zobowiązany jest do przeprowadzenia prototypy systemu wiarygodnych testów użyteczności, które będą miały na celu ocenę dwóch prototypów Systemu (testy A/B) . Badanie musi zostać przeprowadzone na etapie projektowania interfejsu użytkownika. Przed rozpoczęciem badania Zamawiający zaakceptuje prototypy dla których prowadzone będą testy oraz scenariusze testów. Wykonawca przygotuję ankietę na bazie której użytkownicy (w liczbie nie mniejszej niż 25 osób) oceniać będą prototypy. Ankieta musi się składać z pytań zamkniętych (np. ocena w skali 1 – 10) oraz pytań otwartych. Wyniki badań będą stanowiły rekomendacje dla Zamawiającego odnośnie wyboru interfejsu użytkownika. PZP.TES.21 Testy użyteczności: Testy użyteczności: Badania typu Card Sorting Badania typu Card a. Badania typu Card Sorting muszą być przeprowadzone przez Sorting Wykonawcę przy udziale przedstawicieli Zamawiającego. b. Badanie musi zostać przeprowadzone: i. na grupie co najmniej 25 osób, które stanowić przedstawicieli każdej z grup docelowych, ii. najpóźniej na miesiąc produkcyjnym Systemu, iii. na miesiąc po uruchomieniu produkcyjnym Systemu. przed uruchomieniem c. Scenariusz badania musi zostać przedstawiony do akceptacji Zamawiającego nie późnij niż 14 dni przed rozpoczęciem badania. d. Po zakończeniu badania Wykonawca zobowiązany jest do przedstawienia „Raportu z testów” zawierającego: i. datę przeprowadzenia badania. ii. dane osób biorących udział w badaniu wraz z podpisaną listą obecności. iii. wykaz realizowanych scenariuszem badania. iv. wyniki badania, v. rekomendacje dot. zmian jakie muszą zostać wprowadzone w architekturze informacji, powiązaniach kontekstowych, kategoryzacji treści/tagowania, itd. zadań – zgodnie ze „Raport z testów” musi zostać przedstawiony do akceptacji Zamawiającego. Po akceptacji raportu Wykonawca zobowiązany jest do wprowadzania stosownych zmian w Platformie e-DS w terminie uzgodnionym z Zamawiającym. Strona 55 z 81 Proces Zarządczo-Produkcyjny PZP.TES.22 Testy użyteczności: Testy użyteczności: Analizy typu Cognitive Walkthrough. Analizy typu a. Badanie ma na celu ocenę użyteczności portalu oraz aplikacji Cognitive zbudowanych w ramach Systemu. W wynikach badania muszą Walkthrough zostać przestawione rekomendacje w zakresie łatwości obsługi dostarczonego rozwiązania przez użytkownika – przy założeniu, iż nowi użytkownicy muszą uczyć się sposobów nawigacji w poznawanym serwisie/aplikacji poprzez wykonywanie zdefiniowanych zadań. b. c. Badanie musi odpowiedzieć na pytanie: czy produkt jest zgodny z normami użyteczności? Jednym ze sposobów jest miara oceny wg następujących pytań: i. Czy użytkownik będzie próbował osiągnąć efekt, który daje kolejny krok zadania? Czy będzie rozumiał, że ten krok jest konieczny do realizacji jego celów? ii. Czy użytkownik zauważy, że dostępne jest prawidłowe działanie? Np. czy widzi przycisk? iii. Czy użytkownik rozumie, że krok zadania może być wykonany przez to działanie? Np. czy nie tylko widzi przycisk, ale czy także rozumie jego treść i w efekcie użyje przycisku? iv. Czy użytkownik otrzyma informację zwrotną od systemu? Czy zorientuje się, że wykonał prawidłowo to działanie? Wykonawca zobowiązany jest do przygotowania scenariuszy dla badania na 14 dni przed jego rozpoczęciem. Scenariusze podlegają akceptacji Zamawiającego. Badanie musi zostać przeprowadzone: i. na grupie 25 osób, które reprezentować będą grupy Systemu, ii. na prototypie, iii. najpóźniej na miesiąc uruchomieniem Systemu, iv. miesiąc po produkcyjnym uruchomieniu Systemu. przed produkcyjnym d. Scenariusze podlegać będą akceptacji Zamawiającego. Badanie prowadzone będzie przy udziale przedstawicieli Zamawiającego. e. W wyniku przeprowadzonego badania Wykonawca przedstawi Zamawiającemu „Raport z testów”, który obejmować będzie: i. datę przeprowadzenia badania, ii. dane osób biorących udział w badaniu wraz z podpisaną listą obecności, Strona 56 z 81 Proces Zarządczo-Produkcyjny iii. wykaz realizowanych scenariuszem badania, zadań – zgodnie ze iv. wyniki badania. v. rekomendacje dot. zmian jakie muszą zostać wprowadzone w systemie a także dokumentacji użytkownika. „Raport z testów” musi zostać przedstawiony do akceptacji Zamawiającego. Po akceptacji raportu Wykonawca zobowiązany jest do wprowadzania stosownych zmian w Platformie e-DS w terminie uzgodnionym z Zamawiającym. PZP.TES.23 Testy użyteczności: Testy użyteczności: Analiza heurystyczna przeprowadzona na Analiza heurystyczna prototypie na prototypie a. Badanie ma na celu weryfikację zgodności zaproponowanego rozwiązania z regułami użyteczności. W trakcie badania muszą zostać wskazane problemy związane z nawigacją po Systemie – o ile takowe będą istniały. b. Badanie musi zostać przeprowadzone na: i. grupie co najmniej 25 osób, które reprezentują grupy docelowe Systemu, ii. co najmniej dwukrotnie – na etapie projektowania interfejsu oraz po zakończeniu fazy implementacji, iii. po przeprowadzeniu testów A/B . c. Analiza heurystyczna musi dostarczyć informacji odnośnie użyteczności testowanego rozwiązania. d. W wyniku przeprowadzonego badania Wykonawca przedstawi Zamawiającemu „Raport z testów”, który obejmować będzie: i. datę przeprowadzenia badania, ii. dane osób biorących udział w badaniu wraz z podpisaną listą obecności, iii. wykaz realizowanych scenariuszem badania, iv. wyniki badania – uwagi osób biorących udział w badaniu, v. rekomendacje dot. zmian jakie muszą wprowadzone w interfejsie użytkownika. zadań – zgodnie ze zostać „Raport z testów” musi zostać przedstawiony do akceptacji Zamawiającego. Po akceptacji raportu Wykonawca zobowiązany jest do wprowadzania stosownych zmian w Platformie e-DS w terminie uzgodnionym z Zamawiającym. Strona 57 z 81 Proces Zarządczo-Produkcyjny PZP.TES.24 Testy kontentu Testy kontentu realizowane są: a. b. c. PZP.TES.25 Testy kontentu realizacja przez Zamawiającego lub podmiot go reprezentujący, w ramach procedury przeglądu jakości produktu z kategorii kontent, metodą próbkowania. - Spełnienie warunków formalnych będzie weryfikowane poprzez zbadanie zgodności z wykazami cech określonymi w Załącznikach nr 1 i 2 do dokumentu „PFU.Z5 Architektura informacji i specyfikacja kontentu”. Spełnienie warunków merytorycznych dla kontentu eksperckiego będzie weryfikowane poprzez system recenzji, przy czym w Załączniku nr 1 do ww. dokumentu określona została odrębnie dla każdego z modułów minimalna próbka, która podlegać może recenzji w systemie eksperckim. Dla pozostałych treści (tj. nie wskazanych jako próbka do testów) Zamawiający zastrzega sobie prawo ich weryfikacji w dowolnym momencie realizacji Umowy i w przypadku wykrycia błędów Wykonawca zobowiązany jest do wprowadzenia stosownych modyfikacji. Zamawiający może zlecić zewnętrznym ekspertom przeprowadzenie recenzji merytorycznej dostarczonego kontentu zgodnie z zasadami krytyki naukowej. 4.3.1. Przeprowadzenie testów ID PZP.TES.26 Nazwa cechy Opis Kolejność testów Zamawiający wymaga, aby kolejność testów prowadzonych przez Wykonawcę w ramach testów akceptacyjnych wydania, uwzględniała poniższe wytyczne: a. b. c. d. Testy instalacji wydania mogą się rozpocząć wyłącznie po zakończonych wynikiem pozytywnym testach asemblacji. Testy: i. funkcjonalne, ii. pozafunkcjonalne, iii. integracyjne, iv. regresji mogą się rozpocząć wyłącznie po zakończonych wynikiem pozytywnym testach instalacji wydania. Testy procesowe mogą się rozpocząć wyłącznie po zakończonych wynikiem pozytywnym testach funkcjonalnych i integracyjnych. Testy wydajnościowe mogą się rozpocząć wyłącznie po Strona 58 z 81 Proces Zarządczo-Produkcyjny e. zakończonych wynikiem pozytywnym testach integracyjnych oraz testach funkcjonalnych Testy procedur utrzymaniowych mogą się rozpocząć wyłącznie po zakończonych wynikiem pozytywnym testach funkcjonalnych i pozafunkcjonalnych. Testy bezpieczeństwa mogą się rozpocząć po zakończeniu wszystkich pozostałych testów z wynikiem pozytywnym. PZP.TES.27 Wymagalność testów Jeśli dla danego typu oprogramowania/produktu nie jest zasadne przeprowadzanie danego typu testów (np. testów asemblacji dla programowania standardowego-komercyjnego) Zamawiający nie będzie wymagał ich przeprowadzenia. Zamawiającemu musi jednak zostać przedstawiona propozycja typów testów, które zostaną wykonane dla poszczególnych typów oprogramowania/produktów (w podziale na Etapy Techniczne). Przedstawiona Zamawiającemu propozycja podlega jego akceptacji. PZP.TES.28 Środowisko przeprowadzenia testów Wszystkie testy (w tym wewnętrzne) prowadzone do czasu dostarczenia Zamawiającemu przez Wykonawcę odpowiednich środowisk – będą realizowane na środowisku Wykonawcy. Wszystkie testy (za wyjątkiem wewnętrznych) prowadzone po dostarczeniu Zamawiającemu przez Wykonawcę odpowiednich środowisk – będą prowadzone na środowisku Zamawiającego. PZP.TES.29 Scenariusze testowe Zamawiający wymaga, aby dla testów akceptacyjnych wydania (za dla testów wyjątkiem autorecenzji kontentu) zostały przygotowane akceptacyjnych i przedstawione do akceptacji Zamawiającego scenariusze testowe. wydania PZP.TES.30 Kompletność i Za kompletność i spójność scenariuszy oraz przypadków testowych spójność scenariuszy odpowiada Wykonawca. testowych PZP.TES.31 Nagrywanie testów Realizacja każdego przypadku testowego składającego się na testy realizowane z poziomu interfejsu użytkownika (np. testy procesowe) musi być nagrana na filmiku prezentującym działanie użytkownika oraz zachowanie systemu (w tym pojawiające się błędy). Ww. filmiki muszą zostać dołączone do „Raportu z testów”. Odtworzenie nagranych filmików nie może wymagać posiadania płatnego oprogramowania, a ich jakość musi umożliwiać odczytanie treści prezentowanych na formatkach i wprowadzanych przez użytkownika (w tym np. w pasku adresu przeglądarki). Filmiki muszą być tak oznaczone przez Wykonawcę, aby było możliwe ich łatwe powiązanie ze scenariuszem i danymi testowymi, których w jego trakcie użyto. Wymaganie nie dotyczy testów wewnętrznych. Strona 59 z 81 Proces Zarządczo-Produkcyjny PZP.TES.32 Realizacja testów na W przypadku, gdy w trakcie testów wewnętrznych lub akceptacyjnych tej samej wersji wydania Wykonawca dokonał modyfikacji wersji systemu dostępnej na systemu środowisku, na którym są przeprowadzane testy – wszystkie dotąd przeprowadzone testy muszą zostać powtórzone. Intencją Zamawiającego jest to, aby wszystkie testy były przeprowadzone na tej samej wersji systemu (która – w przypadku testów realizowanych na interfejsie użytkownika – musi być przez cały czas widoczna dla użytkownika). PZP.TES.33 Rozpoczęcie testów Rozpoczęcie testów akceptacyjnych wydania będzie możliwe dopiero akceptacyjnych po dostarczeniu przez Wykonawcę „Raportu z testów wewnętrznych”. wydania Raport ten musi poświadczać, że testy wewnętrzne zostały zakończone wynikiem pozytywnym tj. brak jest błędów w testowanym oprogramowaniu. PZP.TES.34 Uznanie przypadku testowego za zakończony z wynikiem negatywnym W przypadku wykrycia jakiegokolwiek błędu w trakcie realizacji danego przypadku testowego, dany przypadek testowy zostanie uznany za zakończony z wynikiem negatywnym (dotyczy to również błędów w etykietach na formatkach). PZP.TES.35 Uznanie testów akceptacyjnych wydania za zakończone z wynikiem negatywnym Jeśli w trakcie testów akceptacyjnych wydania (nie obejmujących autorecenzji kontentu) zidentyfikowano co najmniej jeden błąd – testy te automatycznie uznane zostaną za zakończone z wynikiem negatywnym i wymagają powtórzenia (po dokonaniu przez Wykonawcę odpowiednich modyfikacji systemu). Ww. zapisy dotyczą testów akceptacyjnych wydania nie obejmujących autorecenzji kontentu. Oznacza to w szczególności, że: a. b. testy akceptacyjne wydania zostaną uznane za zakończone wynikiem pozytywnym wówczas, gdy wszystkie składające się na nie testy (z wyłączeniem autorecenzji kontentu) zakończyły się pozytywnie, choć weryfikacja kontentu dokonywana za pomocą autorecenzji kontentu zakończyła się wynikiem negatywnym, weryfikacja kontentu dokonywana za pomocą autorecenzji kontentu uznana zostanie za zakończona wynikiem pozytywnym, choć testy akceptacyjne wydania (z wyłączeniem autorecenzji kontentu) zakończyły się wynikiem negatywnym. PZP.TES.36 Uczestnictwo Zamawiającego testach Zamawiający zastrzega sobie prawo do obserwowania realizacji testów w prowadzonych przez Wykonawcę (za wyjątkiem testów wewnętrznych oraz autorecenzji kontentu). Uczestnictwo Zamawiającego w ww. testach może być niezapowiedziane. Wykonawca zobowiązany jest w takiej sytuacji zapewnić uczestnictwo Zamawiającego i/lub Inżyniera Kontraktu w odbywających się danego dnia testach. PZP.TES.37 Testy prowadzone w W ET 5 Wykonawca musi przeprowadzić testy o zakresie Etapie Technicznym odpowiadającym sumie testów akceptacyjnych zaplanowanych do 5 realizacji w ET2-ET5 – tj. obejmujących pełen zakres systemu. Testy te będą podstawą akceptacji Systemu oraz odbioru Etapu Zarządczego 1. Strona 60 z 81 Proces Zarządczo-Produkcyjny Ww. wymaganie nie dotyczy autorecenzji kontentu. Testy stanowiące autorecenzję kontentu w ET 5 będą realizowane dla zakresu wskazanego dla tego etapu technicznego. PZP.TES.38 Przekazywanie informacji postępie testów Wykonawca jest zobowiązany do pozyskiwania i przekazywania o Zamawiającemu informacji o postępie testów, w tym: a. przekazywania wartości wskaźników pozwalających na ocenę intensywności prowadzonych testów, b. przekazywania wartości wskaźników pozwalających na ocenę szybkości usuwania błędów, c. przekazywania wartości wskaźników pozwalających na ocenę skuteczności usuwania błędów. Ponadto, Wykonawca zobowiązany jest korzystać z narzędzia do zarządzania błędami udostępnionego przez Zamawiającego. W narzędziu tym muszą być rejestrowane wszystkie zidentyfikowane w trakcie testów błędy. Po podpisaniu Umowy Zamawiający przekaże Wykonawcy wszelkie informacje dot. ww. narzędzia. PZP.TES.39 Raport z testów Wykonawca musi przygotować i przeprowadzić testy wewnętrzne, a wewnętrznych następnie przekazać Zamawiającemu „Raport z testów wewnętrznych”. Testy wewnętrzne muszą obejmować co najmniej scenariusze testów akceptacyjnych wydania (wymagających akceptacji Zamawiającego) oraz weryfikować pokrycie kodu testami. PZP.TES.40 Raport z testów Wykonawca po wykonaniu poniższych testów: a. akceptacyjnych wydania, b. powdrożeniowych musi przekazać Zamawiającemu :”Raport z testów”. „Raport z testów” dla testów akceptacyjnych wydania musi zawierać informacje nt. każdego z rodzajów przeprowadzonych testów (o których mowa w wymaganiu PZP.TES.13). PZP.TES.41 Raport z testów akceptacyjnych a akceptacja produktu przez Zamawiającego Przekazanie przez Wykonawcę produktu do akceptacji - dla produktu typu oprogramowanie - wymaga dołączenia do niego „Raportu z testów” dla przeprowadzonych testów akceptacyjnych wydania, który to raport poświadczy brak występowania błędów w testowanym oprogramowaniu. W przypadku, gdy w oprogramowaniu Wykonawca stwierdzi błędy – produkt taki nie może zostać przekazany Zamawiającemu do akceptacji. PZP.TES.42 Weryfikacja oprogramowania w ramach procedury przeglądu jakości Dla produktu/podproduktu z kategorii oprogramowanie (nie dotyczy oprogramowania standardowego dostarczanego jako element sprzętu, np. sterowniki) w ramach weryfikacji stanowiącej część przeglądu jakości Zamawiający: a. dokona jego weryfikacji metoda próbkowania. Próbka będzie obejmowała co najmniej 10% scenariuszy testowych. Testy Strona 61 z 81 Proces Zarządczo-Produkcyjny wytypowanej próbki będą realizowane przez Wykonawcę w obecności Zamawiającego lub reprezentującego go Inżyniera Kontraktu. będzie miał prawo przeprowadzić testy swobodne i/lub niezależne obejmujące całość lub część testowanego systemu. Zamawiający w trakcie ww. testów może być reprezentowany przez Inżyniera Kontraktu lub inny podmiot. Wynik tych testów musi zostać uwzględniony w podsumowaniu danych testów. b. 4.3.2. Dokumentacja testowa ID SOW.DTES.01 SOW.DTES.02 Nazwa cechy Opis Dokumentacja testów Wykonawca opracuje dokumentację testów, na która składać się musi: Plan testów zakres a. Plan testów, b. Scenariusze testowe, c. Przypadki testowe (scenariusz testowy oraz dedykowane mu dane testowe), d. Mapowanie przypadków testowych na wymagania i przypadki użycia (w tym wymagania szczegółowe i szczegółowe przypadki użycia), e. Testy automatyczne, f. Notatkę z testów - podsumowującą dany dzień testów (nie dotyczy testów trwających tylko jeden dzień), g. Raport z testów (dla każdego typu testów). „Plan testów” musi obejmować co najmniej: a. środowisko niezbędne do przeprowadzenia testów: i. opis przeznaczenia środowisk w trakcie testów, ii. konfigurację środowisk, iii. harmonogram wykorzystania środowisk b. sposób przygotowania i przeprowadzenia testów, c. harmonogram przeprowadzenia testów, w tym: i. terminy rozpoczęcia i zakończenia zadań testowych, ii. podział przypadków testowych pomiędzy poszczególne dni, d. uczestników testów, e. szablony dokumentów wykorzystywanych podczas testów, f. scenariusze testowe, przypadki testowe, Strona 62 z 81 Proces Zarządczo-Produkcyjny SOW.DTES.03 g. macierz pokrycia wymagań i przypadków użycia (w tym wymagań szczegółowych i szczegółowych przypadków użycia) scenariuszami testowymi, h. dane testowe. Przekazanie kodu Wykonawca opracuje i przekaże Zamawiającemu kody źródłowe, dane źródłowego, dane i testowe, dokumentację dla testów automatycznych, spełniające dokumentacje następujące wymagania: testów a. opracowane testy automatyczne będą niezależne od danych w testowanym oprogramowaniu, przeprowadzenie testów nie może wymagać szczególnych przygotowań danych w oprogramowaniu, b. sposób przygotowania testów automatycznych musi zapewnić możliwość ich wielokrotnego powtarzania, w tym bez wymogu powtarzania instalacji środowiska na którym są przeprowadzane testy i konfiguracji do testów, każde kolejne wykonanie tego samego testu nie może wymagać dodatkowych akcji konfiguracyjnych, zmiany danych testowych (ani w oprogramowaniu, ani w systemach symulowanych), c. testy automatyczne muszą zapewniać symulację wszystkich systemów zewnętrznych względem testowanego oprogramowania, d. testy automatyczne nie mogą wymagać do ich uruchomienia innych systemów niedostarczonych razem z testami, e. testy automatyczne nie mogą wymagać, aby przed każdym testem importować dane z systemów symulowanych, f. testy automatyczne muszą być w pełni zautomatyzowane – od uruchomienia do wygenerowania raportu wyników, g. generowany raport musi jednoznacznie określać wynik testu automatycznego: i. wynik testu automatycznego musi zawierać informacje o powodzeniu lub niepowodzeniu każdego przypadku testowego oraz podsumowanie dla całego przebiegu testów automatycznych; ii. nie jest dopuszczalne, aby określenie czy test automatyczny się powiódł czy nie, wymagało jakiejkolwiek dodatkowej analizy ze strony użytkownika; h. musi być dostępny automatycznymi”, „Raport pokrycia kodu testami i. testy automatyczne muszą być udokumentowane tak, aby po zapoznaniu się z dokumentacją można było je uruchomić bez dodatkowej wiedzy – dokumentacja musi zawierać całą wiedzę potrzebną do skonfigurowania środowiska na którym będą Strona 63 z 81 Proces Zarządczo-Produkcyjny wykonywane, testów; uruchomienia testów, pobrania wyników j. dokumentacja musi określać, który element testu automatycznego wykonuje który przypadek testowy, określać w jaki sposób należy przygotować środowisko testowe, w jaki sposób obsługiwać narzędzie, określać możliwe błędy, które mogą się pojawić w trakcie testów, k. pliki konfiguracyjne nie mogą zawierać logiki testów automatycznych ani danych testowych zaś procedura konfiguracji nie może wymagać kroków zmiany danych testowych; l. wymagane jest pokrycie testami automatycznymi co najmniej 50% funkcjonalności. SOW.DTES.04 Przekazanie praw Wykonawca przekaże Zamawiającemu prawa autorskie do danych autorskich do testowych wykorzystywanych w trakcie testów. danych testowych SOW.DTES.05 Scenariusze testowe Scenariusze dla testów muszą być tak przygotowane, aby mogły być – sposób opisu wykonane przez osoby spoza personelu Wykonawcy (nie dotyczy testów bezpieczeństwa). SOW.DTES.06 Sposób przygotowania scenariuszy testowych Sposób przygotowania scenariuszy testowych musi pozwolić na zweryfikowanie pokrycia nimi wymagań szczegółowych oraz szczegółowych przypadków użycia. W szczególności musi istnieć możliwość łatwego: a. zidentyfikowania wymagań szczegółowych weryfikowanych przez scenariusz, b. zidentyfikowania wymagań z Umowy weryfikowanych przez scenariusz, c. zidentyfikowania szczegółowych przypadków użycia, których realizacja jest weryfikowana przez scenariusz. d. zidentyfikowania przypadków użycia z Umowy, których realizacja jest weryfikowana przez scenariusz. Prezentacja pokrycia musi być wykonana przy użyciu macierzy pokrycia. SOW.DTES.07 Scenariusz testowy – Scenariusz testowy musi zawierać: zakres informacji a. unikalny identyfikator scenariusza – umożliwiający jego łatwą i bezbłędną identyfikację, b. wskazanie testowanego zakresu oraz odniesienia do dokumentacji systemu, w szczególności listę weryfikowanych wymagań szczegółowych Zamawiającego oraz realizowanego przypadku użycia (nie dotyczy testów bezpieczeństwa), c. warunki wejściowe – lista warunków, jakie muszą być spełnione, aby można było rozpocząć wykonanie scenariusza, Strona 64 z 81 Proces Zarządczo-Produkcyjny d. wskazanie potrzebnego zakresu danych testowych, e. zestaw przypadków testowych składających się na scenariusz. Każdy przypadek testowy musi: i. zawierać opis działań osoby realizującej przypadek testowy w postaci kolejnych kroków, ze wskazaniem danych, których należy użyć. Opis musi być wyrażony w sposób prosty, przystępny dla osoby w ograniczonym stopniu zapoznanej z Systemem, ii. umożliwiać realizację scenariusza testowego w krótkim czasie, bez konieczności czasochłonnej lektury dużych fragmentów tekstu, lub odwoływania się do dokumentów analitycznych przed jego wykonaniem (niedopuszczalne jest stosowanie pojęć typu „wykonać dla wszystkich ról użytkowników na każdym ekranie aplikacji”, „poprawne na wszystkich ekranach w każdym stanie zlecenia”, „odpowiedź poprawna dla każdego typu komunikatu przychodzącego od dowolnego systemu zewnętrznego” i tym podobne), iii. prezentować oczekiwany wynik wykonania każdego kroku, iv. ocenę, czy przypadek testowy pozytywnie lub negatywnie, v. jeżeli dla sprawdzenia wyniku przypadku testowego konieczne jest wykonanie pewnej sekwencji działań, to musi być ona również opisana w postaci kolejnych kroków. zakończył się W przypadku testów bezpieczeństwa wymagania z punktu e. muszą zostać zweryfikowane przez Wykonawcę i dostosowane przez niego do specyfiki przyjętego rozwiązania oraz specyfiki tych testów. Zaproponowana przez Wykonawcę koncepcja musi zostać zaakceptowana przez Zamawiającego. SOW.DTES.08 SOW.DTES.09 Zbiór scenariuszy Zbiór scenariuszy dla określonego zakresu testów musi: a. zapewniać pełne pokrycie wymagań testowanego zakresu – weryfikowane musi być każde wymaganie szczegółowe testowanego zakresu, b. zapewniać pełne pokrycie przypadków użycia – weryfikowany musi być każdy scenariusz (główny i alternatywne) w każdym szczegółowym przypadku użycia wchodzącym w zakres. Scenariusze testów Zamawiający oczekuje, że scenariusze testów funkcjonalnych będą funkcjonalnych budowane na podstawie szczegółowych przypadków użycia (ich zakresu funkcjonalnego i scenariuszy). Strona 65 z 81 Proces Zarządczo-Produkcyjny SOW.DTES.10 SOW.DTES.11 Cechy scenariuszy Każdy scenariusz w zbiorze scenariuszy musi cechować: a. prostota opisu – scenariusz musi być opisany w sposób prosty, zrozumiały dla osoby nie znającej systemu lub zapoznanej z nim w ograniczony sposób, b. powtarzalność – powinno być możliwe wielokrotne wykonanie scenariusza w identyczny sposób na podstawie jego opisu, c. jednoznaczność – scenariusz przy spełnieniu wymagań wejściowych oraz realizacji wg opisu przypadków testowych powinien mieć ten sam przebieg oraz identyczny wynik (z dokładnością do istotnych elementów) przy powtórzeniach realizacji scenariusza na tej samej wersji systemu, d. możliwość automatyzacji – w przypadku scenariuszy, w których automatyzacja ma sens. Scenariusze testowe Wykonawca musi wskazać w „Planie testów” scenariusze testowe w rozbiciu na etapy i właściwe do wykonania ze względu na: obszary a. etap projektu, b. obszar testów. SOW.DTES.12 Testy funkcjonalne Testy funkcjonalne wskazane do przeprowadzenia w danym Etapie dla etapu Technicznym muszą obejmować całą funkcjonalność wskazaną do technicznego realizacji w danym Etapie Technicznym. SOW.DTES.13 Narzędzia testowe Wykonawca przedstawi Zamawiającemu listę narzędzi testowych planowanych do wykorzystywania. SOW.DTES.14 Skrypty testowe Wykonawca przedstawi Zamawiającemu wykorzystywane do automatyzacji testów. SOW.DTES.15 Warunki konieczne Wykonawca zobowiązany jest do określenia warunków, których do przeprowadzenia spełnienie pozwala na rozpoczęcie testów. testów SOW.DTES.16 Dane testowe zakres SOW.DTES.17 Opis testowych SOW.DTES.18 Poprawne planowanie realizacja testów SOW.DTES.19 Notatka z testów skrypty testowe – Dane testowe muszą umożliwiać realizację zaplanowanych dla etapu testów scenariuszy testowych. danych Opis danych testowych wraz ze skryptami je tworzącymi musi umożliwiać ich odtworzenie w razie utraty. Testy muszą być zaplanowane i zrealizowane w sposób, który umożliwi i ich rzetelne przeprowadzenie i zidentyfikowanie maksymalnej liczby błędów. Notatka z testów musi zawierać co najmniej: a. datę przeprowadzenia testów b. uczestników testów c. liczbę zrealizowanych scenariuszy i przypadków testowych (w tym liczba scenariuszy i przypadków zakończonych wynikiem Strona 66 z 81 Proces Zarządczo-Produkcyjny pozytywny i negatywnym) SOW.DTES.20 Raport z testów d. informację, czy były/nie były prowadzone testy swobodne, e. podsumowanie ilościowe zgłoszonych kategorii błędów. „Raport z testów” musi zawierać co najmniej: a. okres przeprowadzenia testów, b. uczestników testów, c. informacje o przebiegu poszczególnych testów, f. przebieg testów (w tym np. liczbę zrealizowanych scenariuszy i przypadków testowych (w tym liczba scenariuszy i przypadków zakończonych wynikiem pozytywny i negatywnym) – w tym również w ujęciu procentowym), g. informację o tym, że były/nie były prowadzone testy swobodne, h. podsumowanie ilościowe zgłoszonych błędów, d. rekomendacje dla testów realizowanych w kolejnych etapach. Załącznikiem do „Raportu z testów” (nie dotyczy testów wewnętrznych) muszą być filmiki nagrane podczas realizacji wszystkich testów realizowanych z poziomu interfejsu użytkownika. SOW.DTES.21 Termin dostarczenia raportu z testów „Raport z testów” musi być dostarczony Zamawiającemu nie później niż ciągu 3 dni roboczych od dnia zakończenia testów. SOW.DTES.22 Zakończenie testów Zamawiającym uzna, że dane testy zostały zakończone pomyślnie jedynie w przypadku, gdy nie zostanie zgłoszony w ich trakcie żadne odchylenie od przyjętych założeń. W przypadku wystąpienia jakiegokolwiek odchylenia – testy zostaną uznane przez Zamawiającego jako zakończone z wynikiem negatywnym. Strona 67 z 81 Proces Zarządczo-Produkcyjny 4.4. Regulamin korzystania z Portalu ID PZP.RP.01 4.5. Nazwa cechy Opis Regulamin Regulamin musi regulować co najmniej następujące zagadnienia: a. definicje wykorzystane w regulaminie. b. informacje ogólne obejmujące w szczególności: i. podstawowe informacje nt. Systemu, ii. podstawowe obowiązki użytkownika, iii. odpowiedzialność Zamawiającego, c. rejestracja (w tym prawa i obowiązki użytkownika związane z rejestracją) d. rodzaje i zakres świadczonych usług, e. ochrona danych osobowych, f. warunki świadczenia usług oraz wymagania techniczne, g. prawa autorskie i pokrewne. Dokumentacja powykonawcza ID PZP.DP.01 Nazwa cechy Opis Dokumentacja powykonawcza Dokumentacja powykonawcza musi obejmować co najmniej: a. dokumentację techniczną zaktualizowany Projekt Wykonawczy oraz całość wiedzy potrzebnej do rozwijania Systemu, w tym: i. schematy baz danych, ii. specyfikację interfejsów (np. WSDL lub analogiczny poziom szczegółowości), iii. szczegółowe informacje nt. montażu i wykonanych podłączeniach urządzeń, iv. szczegółowe informacje o adresacji sieciowej (pełna konfiguracja poszczególnych kart, mapowanie kart na urządzenia, lista LAN-ów i V-LANów z adresacją, opis kontekstu poszczególnych sieci i zasady routowania pakietów), v. zrzuty konfiguracyjne ze sprzętu/opis gdy niemożliwy Strona 68 z 81 Proces Zarządczo-Produkcyjny jest zrzut, b. 4.6. vi. podział macierzy na wolumeny, opisy wolumenów, wykorzystanie wolumenów – przypisanie do ról serwerów, opis wykorzystanych RAID ( konfiguracji wraz z funkcją w systemie) vii. definicje logów i alertów specyficznych dla platformy, viii. dokumentację wygenerowaną na podstawie kodu (np. JavaDoc), w przypadku stosowania języka programowania umożliwiającego tworzenie strukturalizowanych opisów i komentarzy w ramach kodu źródłowego, zawierającą w szczególności udokumentowanie każdej klasy (i interfejsu) na poziomie opisu klasy oraz metod publicznych wraz z parametrami wejścia i wyjścia metody. Politykę Bezpieczeństwa systemu, która musi być spójna z aktualną Polityką Bezpieczeństwa Informacji Zamawiającego. Wdrożenie ID PZP.WD.01 Nazwa cechy Opis Wdrożenie wydania Wdrożenie wydania systemu na środowisko produkcyjne musi nastąpić w: a. b. c. ET 2, ET 3, ET 4. Zasilone w ten sposób środowisko udostępnione klientom (tj. na zewnątrz). PZP.WD.02 Wdrożenie w ET5 produkcyjne nie będzie Wykonawca musi (kolejno): a. b. c. wyczyścić środowisko produkcyjne (w tym jego konfigurację), dokonać ponownej (całościowej) instalacji Systemu na środowisku produkcyjnym (zgodnie z przygotowaną dokumentacją), na tak przygotowanym środowisku produkcyjnym przeprowadzić pełne testy Systemu (sumę wszystkich testów akceptacyjnych dla wszystkich wydań, ale z wyłączeniem autorecenzji kontentu), w szczególności testy bezpieczeństwa. Pozytywny wynik tych testów stanowi podstawę wdrożenia produkcyjnego Systemu, na które składa się ponowne wyczyszczenie środowiska i ostateczne jego zainstalowanie na potrzeby udostępnienia Systemu użytkownikom. Zastosowana podczas wdrożenia konfiguracja systemu nie może się pod żadnym względem różnić od tej, która została Strona 69 z 81 Proces Zarządczo-Produkcyjny zastosowana podczas budowania środowiska na potrzeby przeprowadzenia sumy wszystkich testów dla wszystkich wydań – chyba, że podczas testów bezpieczeństwa wykryto błędy/luki, których wyeliminowanie jest niezbędne przed udostępnieniem Systemu użytkownikom, a ich eliminacja wymaga zmian konfiguracji. 4.7. Instrukcje stanowiskowe ID PZP.IS.01 Nazwa cechy Opis Instrukcje stanowiskowe Wykonawca opracuje instrukcje stanowiskowe dla: a. b. Użytkowników, w skład których wejdą co najmniej: i. instrukcja korzystania z funkcjonalności portalu (w tym np. instrukcja korzystania z narzędzi raportowych, instrukcja zamieszczania danych na portalu, instrukcja budowania ankiet), ii. instrukcja korzystania z narzędzia do budowania kontentu na Wideobanery, iii. instrukcja korzystania z podsystemu GIS Administratora, w skład której wejdą co najmniej: i. instrukcja instalacji, konfiguracji i administracji, ii. instrukcje postępowania w przypadkach szczególnych oraz awarii, w tym odtworzenia oprogramowania, iii. opis obsługi codziennej systemu zabezpieczeń, iv. opis archiwizacji oraz tworzenia kopii zapasowych systemu, v. opis konfiguracji zastosowanego sprzętu, vi. dokumentacja zastosowanej instalacji, vii. procedury instalacji, viii. dokumentacja konfiguracji i parametryzacji, ix. procedury konfiguracji, x. procedury okresowego testowania odtwarzanych danych, wraz z instrukcją obsługi problemów, xi. procedury kontroli zmian oraz instalacji nowych wersji (dla oprogramowania standardowego i dedykowanego), xii. zasady zarządzania użytkownikami, xiii. analiza użytkowania systemu (log działań użytkowników), Strona 70 z 81 Proces Zarządczo-Produkcyjny xiv. analiza pracy administratora (log działań administratora). PZP.IS.02 Instrukcje stanowiskowe Administratora Dostarczone instrukcje stanowiskowe dla Administratora muszą dla umożliwiać Zamawiającemu samodzielne utrzymanie dostarczonego Systemu. PZP.IS.03 Szczegółowy zakres Szczegółowy zakres poszczególnych instrukcji stanowiskowych zostanie poszczególnych uzgodniona z Zamawiającym w trakcie prac projektowych instrukcji prowadzonych przez Wykonawcę. stanowiskowych PZP.IS.04 Procedura eksploatacyjna Każda z procedura eksploatacyjna ujęta w instrukcji stanowiskowej musi zawierać, co najmniej następujące informacje: a. identyfikator - jednoznaczny identyfikator procedury eksploatacyjnej, b. nazwę procedury eksploatacyjnej, c. wydanie (wersja) procedury eksploatacyjnej, d. datę początku obowiązywania procedury eksploatacyjnej, e. cel - opis przeznaczenia procedury eksploatacyjnej, f. obszar stosowania - opis obszaru, w którym procedura eksploatacyjna ma zastosowanie, g. odpowiedzialność - określenie osób/ról ponoszących odpowiedzialność za stosowanie procedury, h. wykaz dokumentów związanych (w tym dokumentów opisujących procedury zależne), i. aplikacje wspomagające - informacje o aplikacjach wspomagających wykonywanie procedur (np. aplikacje zarządzania zmianami), j. definicje i zastosowane skróty - opis użytych w procedurze skrótów i pojęć, k. macierz odpowiedzialności (RACI) - macierz określająca rodzaj odpowiedzialności osób/ról za poszczególne kroki/czynności procedury. W ramach RACI będą używane następujące rodzaje odpowiedzialności: i. R (responsible) – osoba/rola odpowiedzialna za wykonanie czynności ii. A (accountable) – osoba/rola nadzorująca wykonanie czynności iii. C (consulted) – osoba/rola udzielająca konsultacji w trakcie wykonywania czynności iv. I (informed) – osoba/rola informowana, nie mająca bezpośredniego wpływu na przebieg procedury, ale wymagająca określonych informacji o jej przebiegu (np. Strona 71 z 81 Proces Zarządczo-Produkcyjny informacji o postępie wykonywania) l. PZP.IS.05 tryb postępowania - opis kolejnych kroków/czynności procedury eksploatacyjnej zawierający: i. diagram w notacji BPMN obrazujący proces wykonywania procedury. ii. opis poszczególnych czynności procedury (nazwa czynności, dokładny opis czynności z podaniem konkretnych poleceń z parametrami wykonania lub odwołania do skryptu), role powiązane z czynnością, zasoby niezbędne do wykonania czynności). Instrukcje dotyczące Instrukcje dot. kontentu muszą obejmować co najmniej: kontentu a. Instrukcję tworzenia kontentu (dla użytkowników Zamawiającego oraz pracowników jednostek samorządu terytorialnego) z wykorzystaniem wdrożonych narzędzi w ramach Platformy e-DS, b. metodykę aktualizacji i zarządzania ontologiami dziedzinowymi oraz systemowymi, c. procedury i zasady tworzenia kontentu na etapie utrzymania. PZP.IS.06 Instrukcje stanowiskowe PZP.IS.07 Forma dostarczenia Wykonawca wszystkie instrukcje stanowiskowe dostarczy w formie instrukcji podręczników oraz e-learning. stanowiskowych Dodatkowo, instrukcje dla użytkowników muszą zostać opracowane w formie ilustrowanych krótkich broszur opisujących najkrótszą ścieżkę osiągnięcia danego celu biznesowego (np. założenie konta na portalu, publikacja treści na portalu, komentowanie treści). 4.8. Instrukcje stanowiskowe dla użytkowników muszą zawierać całość wiedzy potrzebnej do użytkowania Systemu. Transfer wiedzy ID PZP.TW.01 Nazwa cechy Opis Tematyka instruktaży Wykonawca zobowiązany jest do przygotowania i przeprowadzenia instruktaży: a. przed rozpoczęciem testów uczestniczących w testach: akceptacji dla osób i. czas trwania: nie więcej niż 12 godzin (liczonych bez przerw) ii. liczba uczestników: łącznie 20 osób. W ramach instruktażu Wykonawca dokonuje szczegółowej Strona 72 z 81 Proces Zarządczo-Produkcyjny prezentacji testowanej części Systemu, w zakresie umożliwiającym Zamawiającemu przeprowadzenie testów akceptacji. b. c. d. 4.9. z zakresu funkcjonowania Systemu: i. czas trwania: nie mniej niż 10 godzin (liczonych bez przerw) ii. liczba uczestników: łącznie 20 osób. z zakresu administrowania Systemem na poziomie sprzętowym oraz systemowym: i. czas trwania: nie mniej niż 12 godzin (liczonych bez przerw) ii. liczba uczestników: 5 osób, z zakresu zarządzania kontentem: i. czas trwania: nie mniej niż 10 godzin (liczonych bez przerw) ii. liczba uczestników: 10 osób. Utrzymanie Procedury i produkty związane z pracami wykonawcy Platformy w Etapie Zarządczym 2 zostały opisane w dokumencie „PFU.Z8 Utrzymanie i funkcje operatorskie – specyfikacja wymagań”. 4.10. Zintegrowana Platforma e-DS ID Nazwa cechy Opis PSP.ZPE.01. Produkt główny EZ 1 Zintegrowania Platforma e-DS stanowi produkt główny wytwarzany w - elementy składowe ramach całego Etapu Zarządczego 1. Produkt ten składa się ze wszystkich produktu wytworzone w ramach ET1 – ET 5, ale nie stanowi wyłącznie ich sumy. Produkt główny EZ1 stanowi połączenie (w tym właściwe zintegrowanie) wszystkich produktów w sposób umożliwiający realizację przez Projekt postawionych przed nim celów. PSP.ZPE.02. Akceptacja produktu głównego EZ 1 warunki Warunkiem akceptacji produktu głównego EZ 1 będzie weryfikacja, czy wszystkie składające się na niego produkty właściwie ze sobą współdziałają oraz czy są ze sobą spójne. W związku z powyższym najważniejszym elementem ww. weryfikacji będzie przeprowadzenie całościowych testów Systemu ze szczególnym naciskiem na testy integracji i testy procesowe. Strona 73 z 81 Proces Zarządczo-Produkcyjny PSP.ZPE.03. Akceptacja produktu głównego EZ 1 Akceptacja produktu w tym weryfikacja poprawności integracji jego elementów, realizowana będzie w ramach Etapu Technicznego 5. Strona 74 z 81 Proces Zarządczo-Produkcyjny 5. Narzędzia i standardy wykorzystywane w projekcie 5.1. Narzędzia i standardy wspierające zarządzanie projektem ID Nazwa cechy Opis PZP.NSZ.01 Zgodność z Projekt, w ramach którego będzie realizowany przedmiot niniejszego metodyką PRINCE2 zamówienia musi być zarządzany zgodnie z metodyką PRINCE2™ w wersji z roku 2009, polska wersja językowa (ISBN 978-0-11-3312245). PZP.NSZ.02 Narzędzie wspierające planowanie projektu zgodnie z PRINCE2 5.2. Jeśli Zamawiający udostępni Wykonawcy system wspierający zarządzanie projektem (np. zarządzanie ryzykiem, zgłaszanie zagadnień) Wykonawca zobowiązany będzie korzystać z udostępnionego mu narzędzia. Aktualnie wykorzystywanym przez Zamawiającego tego typu narzędziem jest P2Ware w wersji 3.1. Narzędzia i standardy wspierające prace specjalistyczne ID Nazwa cechy Opis PZP.NSS.01 Narzędzia modelowania projektowania Wykonawca modelowanie oraz projektowanie systemu musi realizować i w narzędziu dedykowanym do takich prac. PZP.NSS.02 Odczyt danych w Wszystkie modele i diagramy dokumentujące System muszą być oprogramowaniu przekazywane Zamawiającemu w postaci modeli do wykorzystania Sparx Enterprise przez narzędzie Sparx Enterprise Architect w wersji 9.3. Architect PZP.NSS.03 Przekazanie repozytorium projektu PZP.NSS.04 Raport z repozytorium Podlegająca odbiorowi dokumentacja zawierająca modele, projekty i specyfikacje Systemu musi powstać jako raport/raporty z repozytorium w narzędziu wykorzystywanym przez Wykonawcę do modelowania systemu. Wszystkie związane z tym treści muszą znajdować się w modelu. PZP.NSS.05 Stosowanie dobrych Wykonawca musi stosować zadeklarowane przez siebie dobre praktyki praktyk i standardów i standardy. Wykonawca przekaże wytworzone przez siebie repozytorium projektu dokumentujące System w formacie XML umożliwiającym wprowadzenie go (poprawne zaimportowanie) do repozytorium w narzędziu Sparx Enterprise Architect w wersji 9.3. Wynik importu musi być identyczny ze stanem, którym dysponował Wykonawca podczas eksportu z wykorzystywanego przez siebie narzędzia. Strona 75 z 81 Proces Zarządczo-Produkcyjny PZP.NSS.06 Notacja diagramów Wszystkie wykonane przez Wykonawcę diagramy: a. opracowane na etapie analizy szczegółowej i projektowania szczegółowego muszą być zgodne z notacją UML w wersji co najmniej 2.3, b. opisujące procedury eksploatacyjne muszą być opracowane w notacji BPMN w wersji 2.0. Strona 76 z 81 Proces Zarządczo-Produkcyjny 6. Procedury akceptacji produktów i odbiorów etapów ID PZP.WAO.01 Nazwa cechy Opis Rodzaje odbiorów W trakcie realizacji Umowy będą stosowane następujące rodzaje odbiorów: a) odbiory częściowe - dotyczą odbioru Etapów Technicznych nr 1-4 i 6-9, b) odbiory końcowe – dotyczą Etapów Zarządczych nr 1 i 2, które obejmą jednocześnie odbiory odpowiednio Etapów Technicznych nr 5 i 10. PZP.WAO.02 Przekazywanie produktów Poszczególne produkty podlegające odbiorowi przekazywane będą Zamawiającemu na podstawie „Protokołu przekazania produktu do akceptacji” opatrzonego prezentatą Zamawiającego. PZP.WAO.03 Protokół przekazania produktu do akceptacji dla dokumentów W przypadku produktów z kategorii „Dokumentacja” Wykonawca zobowiązany jest załączyć do „Protokołu przekazania produktu do akceptacji” wersję papierową dokumentu z metryką, opatrzoną podpisami Koordynatora Zespołu Wykonawcy i autora/autorów dokumentu oraz wersję elektroniczną danego dokumentu. Produkty stanowiące dokumentację projektową muszą zawierać także oświadczenie ww. osób, że dokumentacja została sporządzona zgodnie z obowiązującymi przepisami prawa krajowego i wspólnotowego, normami, zasadami wiedzy technicznej i metodykami projektowymi oraz, że jest wolna od wad i kompletne z punktu widzenia celu, jakiemu mają służyć. Każdy produkt/podprodukt z kategorii „Dokumentacja” musi zostać przekazany Zamawiającemu: PZP.WAO.04 a. w wersji papierowej - w 3 egzemplarzach wydrukowanych w kolorze, dwustronnie, w formacie A4, gdzie na jednej stronie kartki znajdować się będzie wydrukowana jedna strona dokumentu z wersji elektronicznego; kartki wydrukowanego dokumentu musza być ze sobą trwale zespolone, b. w wersji elektronicznej – w 3 egzemplarzach na płycie CD/DVD. Oznaczenia na Każdy produkt/podprodukt projektu (niezależnie od kategorii tj. produktach projektu Dokument, Oprogramowanie, Sprzęt itd.) musi na nośnikach Strona 77 z 81 Proces Zarządczo-Produkcyjny materialnych zawierać oznaczenia oraz elementy promocyjne. Oznaczenia i elementy promocyjne muszą być zgodne z obowiązującymi w danym czasie wytycznymi Instytucji Zarządzającej Regionalnego Programu Operacyjnego Województwa Dolnośląskiego, które są publikowane na stronie internetowej www.rpo.dolnyslask.pl. PZP.WAO.05 Zakończenie prac Zgłoszenie zakończenia prac nad produktem przez Wykonawcę otwiera nad produktem procedurę przeglądu jakości i nie pociąga za sobą automatycznej akceptacji produktu przez Zamawiającego. PZP.WAO.06 Procedura przeglądu Procedurze przeglądu jakości podlegają wyłącznie produkty przekazane jakości – moment Zamawiającemu do akceptacji. stosowania PZP.WAO.07 Podstawy do Akceptacja produktu nastąpi decyzją Zamawiającego. Decyzja ta akceptacji produktu zostanie podjęta na podstawie przeprowadzonej wcześniej procedury (lub procedur – w przypadku, gdy dla produktu wyszczególniono podprodukty) przeglądu jakości. PZP.WAO.08 Procedura przeglądu Zamawiający zastrzega sobie prawo do następujących czasów na jakości - czas na dokonanie weryfikacji w ramach procedury przeglądu jakości: weryfikację a. 60 dni roboczych na zgłaszanie uwag w czasie testów ortofotomapy, b. 20 dni roboczych na zgłaszanie uwag do kontentu, c. 10 dni roboczych na zgłaszanie uwag do każdego innego produktu. W przypadku, gdy na produkt składają się podprodukty z różnych kategorii, czas zastrzeżony na weryfikację tego produktu jest równy najdłuższemu z czasów zastrzeżonych na weryfikację jego podproduktów. Zamawiający nie wyklucza przekazania Wykonawcy uwag do przekazanych mu produktów w krótszym czasie niż wskazane powyżej. PZP.WAO.09 Wynik procedury Procedura przeglądu jakości kończyć się będzie powstaniem „Raportu z przeglądu jakości przeglądu jakości”, do którego zostanie dołączona „Lista uwag” (o ile zostaną zidentyfikowane). Raport ten będzie przedstawiany do wiadomości Wykonawcy. PZP.WAO.10 Weryfikacja Weryfikacja produktów przekazywanych przez Wykonawcę produktów Zamawiającemu może być przeprowadzona przez: przekazanych przez a. reprezentantów Zamawiającego, Wykonawcę b. reprezentantów Inżyniera Kontraktu – na zlecenie Zamawiającego, c. PZP.WAO.11 Protokół reprezentantów innych (niezależnych) podmiotów – na zlecenie Zamawiającego. akceptacji Dokumentem potwierdzającym akceptację produktu przez Zamawiającego jest podpisany przez niego „Protokół akceptacji Strona 78 z 81 Proces Zarządczo-Produkcyjny produktu produktu”. PZP.WAO.12 Odbiory ET a odbiór Odbiór Etapu Technicznego wymaga uprzedniego uzyskania akceptacji produktów dla wszystkich produktów określonych dla tego etapu. PZP.WAO.13 Brak automatycznego odbioru ET PZP.WAO.14 Protokół końcowego „Protokołu końcowego odbioru” może zostać podpisany wyłącznie odbioru – warunki wówczas, gdy Zamawiający podpisał: podpisania a. dla EZ 1: Akceptacja wszystkich produktów składających się na dany Etap Techniczny nie oznacza automatycznego odbioru tego Etapu Technicznego. Zamawiający dokona odbioru Etapu Technicznego po uprzednim sprawdzeniu kompletności procedur akceptacyjnych. i. „Protokoły częściowego odbioru” dla ET 1, 2, 3 oraz 4, ii. „Protokoły akceptacji produktów” bez zastrzeżeń dla wszystkich produktów wskazanych do dostarczenia w ET 5, b. dla EZ 2: i. „Protokoły częściowego odbioru” dla ET 6, 7, 8 oraz 9, iii. „Protokoły akceptacji produktów” dla wszystkich produktów wskazanych do dostarczenia w ET 10. PZP.WAO.15 Brak odbioru Etapu Brak odbioru przez Zamawiającego danego Etapu Technicznego nie Technicznego uniemożliwia realizacji prac Wykonawcy wynikających z kolejnego Etapu Technicznego. PZP.WAO.16 Weryfikacja Odbiór produktu, w określonym stadium jego rozwoju, w ramach produktów a odbiór Etapów Technicznych 1 – 4 nie stoi na przeszkodzie możliwości EZ1 dokonania ponownej jego weryfikacji w ramach odbioru końcowego EZ 1. Zamawiający zastrzega sobie możliwość zgłoszenia na tym etapie uwag do tego produktu. Ujawnione w ten sposób wady będą wpływały na możliwość odbioru EZ1. PZP.WAO.17 Procedura przeglądu Procedura przeglądu jakości składa się z następujących kroków: jakości a. Wykonawca zgłasza Zamawiającemu produkt do akceptacji. b. Zamawiający informuje Wykonawcę o przewidywanym terminie przekazania mu uwag do produktu (zgodnie z czasami weryfikacji określonymi w wymaganiu: PZP.WAO.08). c. Zamawiający dokonuje weryfikacji produktu. d. Zamawiający przekazuje Wykonawcy „Raport z przeglądu jakości” oraz ewentualną „Listę uwag” (załącznik do ww. raportu – o ile wykryte zostaną odstępstwa od wymagań). e. W przypadku przekazania uwag do jakości produktu Wykonawca zobowiązany jest do przeprowadzenia ich analizy oraz wprowadzenia niezbędnych poprawek, tak aby produkt uzyskał wymaganą jakość. f. W przypadku wątpliwości co do zasadności lub zakresu Strona 79 z 81 Proces Zarządczo-Produkcyjny zgłoszonych przez Zamawiającego odstępstw od wymagań jakościowych Wykonawca ma prawo do wnioskowania o przeprowadzenie Narady Przeglądu Jakości Produktu, która musi odbyć się nie później niż w ciągu 3 dni roboczych od daty przekazania wniosku. Wraz z wnioskiem Wykonawca musi przedłożyć szczegółowe pytania lub argumentację uzasadniającą jego stanowisko. W trakcie Narady omówione zostaną wszystkie kwestionowane uwagi i uzgodniony zostanie ich status. Statusy jakie mogą uzyskać uwagi po Naradzie Przeglądu Jakości Produktu to: i. Do uwzględnienia – Zamawiający podtrzymuje swoje stanowisko; w przypadku uwag o statusie „Do uwzględnienia” dodatkowo należy określić w jaki sposób uwaga zostanie przez Wykonawcę uwzględniona, ii. Odrzucona – uwaga nieaktualna (po wyjaśnieniach udzielonych przez Wykonawcę nie wymaga się zmian/uzupełnień w produkcie). PZP.WAO.18 Przeglądy jakości – Procedura przeglądu jakości jest powtarzana do czasu osiągnięcia przez liczba iteracji i produkt wymaganej jakości. Liczba iteracji, w trakcie których wskazywanie próbki realizowane będą weryfikacje produktu (w ramach przeglądu jakości), zależy od jakości produktu dostarczonego przez Wykonawcę do akceptacji. Podczas każdej iteracji Zamawiający ma prawo do wskazania innej próbki, która w danej iteracji będzie podlegała weryfikacji. PZP.WAO.19 Weryfikacja Weryfikacja produktu prowadzona przez Zamawiającego lub jego produktu na reprezentantów w ramach przeglądu jakości wykonywana jest w podstawie próbki oparciu o wytypowaną przez Zamawiającego próbkę produktu. PZP.WAO.20 Wizje lokalne PZP.WAO.21 Macierz spełnienia Wykonawca wraz z „Protokołem przekazania produktu do akceptacji” wymagań musi przekazać opracowaną przez siebie „Macierz spełnienia wymagań” opracowaną osobno dla przekazywanego produktu oraz wszystkich jego podproduktów (o ile zostały zdefiniowane). Każda „Macierz spełnienia wymagań” musi prezentować wszystkie wymagania, które są zdefiniowane w Umowie dla danego produktu oraz informacje o tym, które z podproduktów realizują każde z wymagań określonych dla tego produktu. PZP.WAO.22 Raport z dostawy „Raport z dostawy podproduktu” dedykowany jest wyłącznie do podproduktu potwierdzenia faktu dostarczenia Zamawiającemu przez Wykonawcę danego podproduktu w określonej postaci, w określonej ilości, w określonym dniu. Ponadto Raport ten musi zawierać informację Przeprowadzenie wizji lokalnej przez Zamawiającego może być działaniem niezależnym w stosunku do procedury przeglądu jakości i może być wykonane przez Zamawiającego (lub reprezentujący go podmiot) w dowolnym czasie. W przypadku wykrycia podczas wizji lokalnej nieprawidłowości i zgłoszenia Wykonawcy - Wykonawca musi je usunąć na swój koszt oraz w sposób niezaburzający aktualnie obowiązującego harmonogramu projektu. Strona 80 z 81 Proces Zarządczo-Produkcyjny wskazującą produkt, którego elementem składowym jest dostarczony podprodukt. „Raport z dostawy podproduktu” ma wyłącznie charakter protokołu zdawczo-odbiorczego i musi być wykorzystywany wyłącznie w sytuacji, gdy przekazanie pełnego produktu w jednym miejscu i jednym czasie byłoby utrudnione np. ze względów logistycznych. Podpisanie przez strony „Raportu przekazania podproduktu”: PZP.WAO.23 Dostępność Zamawiającego a. nie uruchamia procedury weryfikacji jego jakości, b. nie jest tożsame z podpisaniem „Protokołu przekazania produktu do akceptacji”. Wszelkie czynności w szczególności: wymagające interakcji z Zamawiającym, a. przekazania produktów, b. czynności wiązane z weryfikacją i akceptacją produktów, c. czynności związane z odbiorem przedmiotu niniejszej Umowy będą realizowane przez Zamawiającego (lub jego reprezentantów) w godzinach jego pracy, chyba że zostanie to każdorazowo odmiennie ustalone przez strony. Strona 81 z 81