Proces Zarządczo-Produkcyjny - BIP Urząd Marszałkowski

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