Procedury dostawy, akceptacji i odbioru produktów

Transkrypt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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