Specyfikacja/ Załacznik nr 2 „Audyt kod ABAP w projekcie...

Zapytanie o cenę – „Audyt kod ABAP w projekcie GTS Printing”

Audyt kod ABAP w projekcie GTS PrintingSpecyfikacja_Zalacznik nr 2

Wszystkie wydrukowane kopie są niekontrolowane

2017-05-22

© innogy BS

Strona 1 z 15

Specyfikacja/ Załacznik nr 2

„Audyt kod ABAP w projekcie GTS Printing”

Copyright © innogy BS. Any use or form of reproduction, in whole or part, of any material whether by

photocopying or storing in any medium by electronic means or otherwise requires the written permission of

an authorised representative of innogy BS and may then only be used or reproduced in accordance with

written permission given.


Zapytanie o cenę – „Audyt kod ABAP w projekcie GTS Printing


2017-05-22

© innogy BS

Strona 2 z 15

1 Spis treści

1 Spis treści ........................................................................................................................................................ 2

2 Słownik pojęć .................................................................................................................................................. 4

3 Wprowadzenie ................................................................................................................................................ 4

3.1 Cel zapytania .......................................................................................................................................... 5

3.2 Przedmiot zapytania ........................................................................... Błąd! Nie zdefiniowano zakładki.

3.3 Proces wyboru oferty ......................................................................... Błąd! Nie zdefiniowano zakładki.

3.4 Kluczowe kamienie milowe ................................................................................................................. 10

3.5 Kryteria oceny ..................................................................................... Błąd! Nie zdefiniowano zakładki.

4 Architektura rozwiązania .............................................................................................................................. 10

5 Wymagania funkcjonalne dla rozwiązania ................................................... Błąd! Nie zdefiniowano zakładki.

5.1 Opis sposobu potwierdzania realizacji wymagań ............................... Błąd! Nie zdefiniowano zakładki.

6 Wymagania pozafunkcjonalne dla rozwiązania ............................................................................................ 10

6.1 Technologia realizacji rozwiązania ...................................................................................................... 10

6.2 Bezpieczeństwo rozwiązania ............................................................................................................... 10

6.3 Wydajność rozwiązania ....................................................................................................................... 11

6.4 Skalowalność rozwiązania ................................................................................................................... 11

6.5 Dostępność i niezawodność rozwiązania ............................................................................................. 11

6.6 Rozszerzalność rozwiązania ................................................................................................................. 11

6.7 Zarządzalność rozwiązania................................................................................................................... 11

6.8 Testowalność rozwiązania .................................................................. Błąd! Nie zdefiniowano zakładki.

6.9 Integracja rozwiązania ......................................................................................................................... 12

6.10 Wymagania prawne i regulacyjne ....................................................................................................... 12

6.11 Zasady licencjonowania rozwiązania ................................................................................................... 12

7 Wymagania dla szkoleń ................................................................................................................................. 12

8 Wymagania dla procesu obsługi błędów ..................................................... Błąd! Nie zdefiniowano zakładki.

8.1 Zasady obsługi błędów podczas testów .............................................. Błąd! Nie zdefiniowano zakładki.

8.2 Zasady obsługi błędów podczas stabilizacji ........................................ Błąd! Nie zdefiniowano zakładki.

8.3 Zasady obsługi błędów na produkcji ................................................... Błąd! Nie zdefiniowano zakładki.

9 Wymagania formalne .................................................................................................................................... 12

9.1 Referencje ............................................................................................................................................ 12

9.2 Dokument odpowiedzi ........................................................................................................................ 13

9.3 Zespół wdrożeniowy ............................................................................................................................ 13

9.4 Utrzymanie systemu ........................................................................... Błąd! Nie zdefiniowano zakładki.




2017-05-22

© innogy BS

Strona 3 z 15

9.5 Warunki płatności ............................................................................... Błąd! Nie zdefiniowano zakładki.

9.6 Zapewnienie jakości ............................................................................................................................. 13

9.7 Inne ...................................................................................................................................................... 14

10 Załączniki .................................................................................................................................................. 14




2017-05-22

© innogy BS

Strona 4 z 15

2 Słownik pojęć

Pojęcie Opis

MUSI, NIE MOŻE,

WYMAGANE,

ZABRONIONE

Ilekroć w dokumencie występuje wyraz MUSI lub WYMAGANE lub NIE MOŻE lub

ZABRONIONE lub odpowiadające im formy oznacza to, że istnieje obowiązek

bezwzględnego zastosowania się do treści zapisu w oferowanym rozwiązaniu.

POWINNO, NIE

POWINNO,

ZALECANE,

NIEZALECANE

Ilekroć w dokumencie występuje wyrażenie POWINNO lub ZALECANE lub NIE POWINNO

lub NIEZALECANE lub odpowiadające im formy oznacza to, że dopuszczalne jest

niezastosowanie się do treści zapisu, ale wtedy i tylko wtedy, gdy na podstawie

uprzednio wykonanej analizy dla określonego przypadku wykazano, że zastosowanie się

do treści zapisu jest niemożliwe lub inne obiektywnie uzasadnione czynniki sprawiają, że

zastosowanie się jest zbędne albo nieefektywne.

OPCJONALNIE,

NIE MOŻE

Ilekroć w dokumencie występuje wyrażenie OPCJONALNIE lub MOŻE lub odpowiadające

im formy oznacza to, że dopuszczalne jest niezastosowanie się do treści zapisu,

konieczne jest podanie przyczyny niezastosowania i sposobu alternatywnego

rozwiązania kwestii opisywanych w akapicie.

3 Wprowadzenie

Dokument opisuje cel przeprowadzenia audytu:

1. kodu ABAP zgodnie z „Harmonized ABAP Guidelines 2.0”

2. wykonania optymalizacji i harmonizacji formularzy w oparciu o

„Analiza_biznesowa_ADS_GTS_Printing_v1 8” stanowiącej RFP projektu GTS Printing

3. wydajności oprogramowania dostarczonego w ramach projektu GTS Printing




2017-05-22

© innogy BS

Strona 5 z 15

Powyżej wymienione dokumenty są załącznikami do niniejszego zapytania.

3.1 Przedmiot zapytania

3.1.1 Audyt kodu ABAP

Audyt kodu ABAP wykonanego w projekcie GTS Printing do dokumentu zgodnie z Harmonized ABAP Guidelines

2.0” w którym zawarte są standardy kodowania w języku ABAP dla projektów grupy innogy. Audyt musi zostać

wykonana narzędziem Code Inspector .

3.1.2 Audyt wykonania optymalizcji i hamornizacji formularzy

Weryfikację kodu utworzonych w projekcie GTS Printing formularzy aplikacyjnych z dotychczas obowiązującymi

formularzami aplikacyjnymi. Celem audytu będzie weryfikacja wykonania przez Dostawcę założonych

wymagań odnośnie harmonizacji i optymalizacji zawartych w dokumencie

„Analiza_biznesowa_ADS_GTS_Printing_v1 8” będących RFP projektu.

Fragmenty RFP traktujące wymaganą optymalizacje i harmonizację:

Numer Nazwa Opis

Z001 Optymalizacja struktury

Forms obsługujących

faktury – obecnie WO, MO i

TPA

Wdrożenie formularzy obsługujących wydruk faktur w nowej technologii ze

szczególnym uwzględnieniem uspójnienia i optymalizacji technicznej kodu

Z002 Dostosowania po stronie

ISU wykraczające poza

zakres forms

Zmiany wymagane ze względu na optymalizację struktury i kodu forms

obsługujących wydruk faktur.

Z004 Dostosowanie formularzy

pozostałych formularzy

Zmiana technologii wydruku i optymalizacja techniczna wszystkich formularzy

wydruku

4 Formularze wydruku (RF05, RF25)

Layout wydruków powinien zostać niezmieniony co do wyglądu docelowego, poza zgłoszonymi w tym dokumencie i na

etapie analizy zmianami. Wymagana jest przede wszystkim zmiana podejścia technicznego. Poza przejściem na nową

technologię konieczne jest również wykonanie zmian organizacyjnych w procedurach pozyskiwania i przetwarzania danych

do wygenerowania wydruku zgodnie z zaleceniami audytu formularzy jaki został przeprowadzony w przedsiębiorstwie.

Głównym celem jest pogrupowanie składników wspólnych w moduły je obsługujące i wykorzystanie tych samych modułów

we wszystkich formularzach stosowanych w RWE przy równoczesnej optymalizacji transformacji danych.

Jeżeli wykonawca napotka na etapie analizy lub przygotowania wdrożenia na problemy interpretacyjne wymagań

funkcjonalnych, zapisów dokumentu lub natrafi na niespójności lub sytuacje niejednoznaczne powinien przedstawić analizę

problemu i zgłosić potrzebę doprecyzowania ustaleń w uzgodnieniu ze stroną biznesową RWE Polska i działem IT w

reprezentowanym przez RWE GBS.

4.1.3 Architektura przetwarzania




2017-05-22

© innogy BS

Strona 6 z 15

Docelowy model architektury przetwarzania danych dla potrzeb wydruku należy oprzeć na wzorcu MVC, gdzie poszczególne

części procesu generowania dokumentu wydruku będą kolejno realizowane poprzez:

1. HIERARCHIA. Formularz aplikacji definiowany w EFRM. Należy zbudować hierarchię, do której zostaną

pobrane wszystkie dane konieczne do wydruku. Na tym poziomie nie dokonujemy żadnych transformacji danych.

Zaczytane bezpośrednio z bazy danych informacje przekazywane są do dalszej obróbki w module obsługi

Interfejsu.

2. INTERFEJS. Dane pobrane w kroku 1 przetwarzane powinny być następnie w Interfejsie zdefiniowanym

w SFP. Na tym poziomie zawarta musi być cała logika transformacji danych na potrzeby wygenerowania

dokumentu wydruku. Algorytmy przetwarzania muszą zawierać aktualnie zastosowaną logikę z uwzględnieniem

jak największego uspójnienia przetwarzania grup danych powiązanych: dane adresowe, pomiarowe,

rozliczeniowe, należności i inne. Wszystkie funkcje wyliczające wartości do wydruku i dokonujące transformacji

danych testowych lub wyznaczające teksty dodatkowe do naniesienia na wydruk należy umieścić w warstwie

Interfejsu. Do warstwy Formularza muszą trafiać już gotowe wartości, które ewentualnie mogą być tylko

dostosowane pod względem formatu drukowanych liczb.

3. FORMULARZ. Wszystkie przygotowane dane do umieszczenia na wydruku pobiera Formularz wykonany

w technologii Adobe Print Forms przygotowany w transakcji SFP. W ramach wypełniania układu danymi z

Interfejsu należy uwzględnić dodatkowo informacje przygotowane w ramach funkcji ustawiania parametrów

wydruku opisanej w rozdziale 3.3.2 Prognozowanie materiałów i ustawienie parametrów wydruku Każdy wydruk

dotyczy konkretnego KU i na tej podstawie należy dobrać w chwili generowania wydruku do pliku PDF

odpowiednie parametry do stworzenia layoutu. Mamy tutaj dwie kategorie treści:

a. Do wydruku musi być wykorzystany odpowiedni poddruk dla poszczególnych stron zgodnie ze wzorami

zapisanymi w plikach PDF dla poddruków.

b. W ramach generowania pliku PDF z wydrukiem należy również uwzględnić dodatkowe strony wydruku

związane z insertami wynikającymi z przypisanych do KU insertami drukowanymi.

Dostawca musi zapewnić aby podział na 3 warstwy przetwarzania nie spowodował spadku wydajności przetwarzania

wydruków.

4.1.6 Elementy graficzne

W ramach generowania wydruków wykorzystywane mogą być dodatkowe elementy graficzne umieszczane na wydruku.

Należy opracować mechanizm pozwalający na konfigurację tych elementów i logiki ich umieszczania umożliwiający

sterowanie funkcjonalnością przez użytkowników.

4.3 Formularze FICA i korespondencji

W ramach poniższej analizy sprawdzono funkcjonalność wydruków wykorzystywanych w SAP FI-CA, zarówno w zakresie

obsługi należności, jak i windykacji. Celem dokumentu jest ustalenie zakresu prac w projekcie GTS Printing dla dokumentów

FI-CA.

Głównymi kryteriami przeprowadzonej weryfikacji była złożoność kodu wykorzystanego do pobierania i przetwarzanych

danych wyświetlanych na dokumencie, złożoność wydruku / layoutu, możliwość zastosowania mechanizmów do

generowania podobnych danych przy użyciu tych samych narzędzi programistycznych, w szczególności przejście na

programowanie obiektowe oraz wykorzystanie wspólnych klas i metod programistycznych w wydrukach.

W ogólności scenariusze zmian przedstawiają się następująco:

1. Nie zmieniamy nic w zakresie dokumentów FI-CA;

2. Zmieniamy warstwę prezentacyjną poprzez zastosowanie Adobe Forms, ale całą logikę obsługi danych

zostawiamy bez zmian;

3. Częściowo przepisujemy kod i logikę pozyskiwania danych oraz wprowadzamy nową warstwę wydruku

wykorzystującą Adobe Forms;

4. Tworzymy formularze od nowa – z nową logiką pozyskiwania danych oraz nową warstwą prezentacji

Adobe Forms.

W wyborze jednego z powyższych scenariuszy uwzględniamy pracochłonność oraz użyteczność wprowadzonych

zmian. Użyteczność jest tu rozumiana jako wpływ zmiany na system, w szczególności czy wydruki będą tworzyły

się szybciej, czy wzrośnie czytelność kodu, a także łatwość modyfikacji i późniejszej obsługi suportowej.




2017-05-22

© innogy BS

Strona 7 z 15

4.3.12 Wymagane zmiany/optymalizacje

Proponowane rekomendacje

Dążąc do standaryzacji wydruków oraz ujednolicenia kodu programów drukujących, najlepszym proponowanym

rozwiązaniem jest zastosowanie technologii Adobe Forms dla wszystkich wydruków oraz zbudowanie czytelnej,

pozbawionej niespójności logiki formularzy.

Cel może być osiągnięty po spełnieniu następujących warunków:

1) Utworzenie formularzy wydruków w technologii Adobe Forms.

2) Ujednolicenie logiki wyboru tych samych danych w poszczególnych formularzach, w szczególności:

a) Adresy teleadresowe RWE,

b) Adresy Partnera, w tym adres siedziby („Klient umowny”) oraz adres do korespondencji,

c) Dane w stopkach i nagłówkach,

d) Data wystawienia dokumentu,

e) Zarządzanie statystykami wydruków, w tym obsługa korespondencji, segmentacja, realizacja kampanii

marketingowych i obsługa zgód marketingowych,

f) Wyliczanie wartości podatku, zaokrąglanie kwot,

g) Obsługa SPOOL.

3) Powyższa harmonizacja wydruków powinna mieć miejsce w oparciu o utworzenie klas i metod programistycznych

do obsługi wspólnych danych (sekcji) formularzy.

4) Zmniejszenie parametryzacji formularzy, mające na celu ograniczenie liczby wersji wydruków, aby sposób

działania programu nie zależał w tak znacznym stopniu od konkretnych wartości pól (np. typu partnera, cyklu

rozliczeniowego, grupy umów).

5) W zakresie operacji matematycznych:

a) ograniczenie ilości operacji matematycznych realizowanych w formularzach, w szczególności związanych z

wyznaczaniem wartości kwot i zaokrągleń,

b) zachowanie spójnego algorytmu wyliczania kwot i podsumowań w różnych formularzach / rodzajach

dokumentów,

c) przeniesienie (tam, gdzie to będzie możliwe) operacji matematycznych z poziomu formularza do właściwych

modułów (FI-CA, Billing).

6) Maksymalne wykorzystanie tabel konfiguracyjnych i słowników, mające na celu wyniesienie części logiki programu

drukującego z formularzy do tablic zewnętrznych w systemie.

7) Ograniczenie zapisu danych z formularza do tabel, np. poprzez przeniesienie realizacji procesu odsetkowania do

modułu FI-CA.

8) Obsługa wyjątków, w szczególności uwzględnienie w formularzach kontroli danych wrażliwych dla procesu

wydruku (np. brak miejsca dostawy PPE i wirtualnego konta bankowego) z zapisem informacji do logu.

9) Przeniesienie funkcjonalności DocMonitora i SreamServe’a do SAP ISU zgodnie z pkt 3.

10) Zapewnienie archiwum wydruków zgodnie z pkt 3

11) Zachowanie dostępu do formularzy wydrukowanych w „starym” środowisku StreamServe’a. W tym celu

proponuje się rozważyć przeniesienie archiwum dokumentów z systemu nScale do nowego środowiska, np. SAP Content

Server.

12) Udostępnienie Użytkownikowi możliwości weryfikacji bieżącego statusu archiwizacji dokumentu bez użycia

DocMonitora zgodnie z pkt 3

13) W formularzach zastosowane są rozwiązania do prowadzenia statystyk wysyłania danych. Należy te mechanizmy

przenieść zgodnie z logiką Adobe Forms. Do sterowania wydrukiem można wykorzystać set_metadata – metodę z klasy

IF_FP_PDF_OBJECT (do weryfikacji).




2017-05-22

© innogy BS

Strona 8 z 15

14) Utworzenie formularzy pozbawionych błędów merytorycznych i rachunkowych, bez niespójności mogących

wynikać z zaokrągleń kwot.

15) Zapewnienie odpowiedniego nazewnictwa obiektów technicznych, komentarzy w programach, w szczególności

opisu nietypowych rozwiązań – zgodnie z 6.1.5 Standardy RWE w zakresie wykonania.

4.3.13 Podsumowanie

Zastosowana w formularzach nowa technologia Adobe Forms powinna pozwolić na tworzenie i wydruk dokumentów o

skomplikowanym wyglądzie/layoucie oraz atrakcyjnej grafice, spełniając przy tym zróżnicowane, rosnące wymagania

marketingowe.

Realizacja powyższych wymagań powinna pozytywnie wpłynąć na wydajność i elastyczność funkcjonalności wydruków SAP

ISU, w tym przyspieszenie operacji generowania i wydruku masowego, jak również sprawniejsze i tańsze wprowadzanie

zmian w przyszłości.

4.4.3 Pobieranie parametrów dla wydruków dokumentów rozliczeniowych ISU

We wszystkich formularzach przypisanych do KU muszą być wykorzystane wspólne exity do zebrania wszystkich

parametrów sterujących wygenerowaniem wydruku oraz przygotowaniem danych do naniesienia na dokumenty wydruku.

Pobieranie parametrów dla wydruku i danych do wydruku odbywać się musi poprzez nowe exity z uwzględnieniem

kryteriów danych jakie będą one obsługiwały:

1. /RWS/PRNT_GET_PARAMS – Ustalone w ramach przypisania parametrów wydruku informacje na poziomie KU

zapisane w tabeli /RWS/PRNT_KU_PAR:

a. Wynikające z kampanii marketingowej poddruki i inserty drukowane,

b. Zgody na KU (lub PH powiązanym z KU), które sterują samym przetwarzaniem informacji na wydruku i jego

layoutem: zgoda na eFakturę, zgoda na wyświetlanie akcyzy, zgoda na blankiet do faktury, zgoda na ofertowanie produktów

podmiotów powiązanych.

2. /RWS/PRNT_GET_CUST – Informacje pozyskiwane z tabel skastomizowanych wykorzystywanych w systemie SAP

ISU w RWE, takich jak nazwy produktów, nazwy cen indywidualnych, opis naliczonych składników, definicje stref itp.

3. /RWS/PRNT_GET_DATA – Wszystkie informacje zgromadzone w tabelach standardowych przechowujących dane o

dokumentach rozliczeniowych, zaliczkach, monitach, odsetkach, fakturach SD, umowach itp.

Poszczególne grupy pobieranych w HIERARCHII (patrz 4.1.3 Architektura przetwarzania) informacji zostały opisane w

kolejnych podrozdziałach.

W ramach uspójnienia modułu do pobierania danych na etapie HIERARCHII powinny powstać exity podane powyżej

(zgodnie z grupami kryteriów), a aktualnie wykorzystywane exity powinny zostać dezaktywowane. Lista exitów do

dezaktywacji obejmuje:

• ZRWS_AF_FORM_TOP

• Z_RWS_NF_WO_ZBIOR_FORM_TOP

• Z_RWS_BI_BILL_AGGR_EXIT_050

• Z_RWS_BI_BILL_COVER_EXIT_050

• Z_RWS_BI_BILL_GUDSF01

• Z_RWS_BI_BILL_GUD_S_EXIT_050

• Z_RWS_BI_BILL_MO_EXIT_050

• Z_RWS_BI_BILL_TPAF01

• Z_RWS_BI_BILL_TPA_EXIT_050

• Z_RWS_BI_BILL_WOF01

W ramach prac wdrożeniowych należy zweryfikować czy exity podlegające dezaktywacji nie są wykorzystywane jeszcze w

innych programach oprócz formularzy wydruku i jeżeli są należy podjąć się dalszej analizy możliwości ich dezaktywacji.




2017-05-22

© innogy BS

Strona 9 z 15

4.4.3.1 Exit dla /RWS/PRNT_GET_DATA

Exit powinien obsłużyć pobieranie wszystkich informacji z tabel standardowych SAP ISU dotyczących drukowanego

dokumentu rozliczenia oraz obiektach danych podstawowych powiązanych z dokumentem, które nie są inicjalnie

przekazywane w chwili wywołania formularza wydruku. Listę tych parametrów należy potwierdzić na etapie analizy, tak aby

zbiór był zgodny z zapotrzebowaniem na informacje konieczne do wydrukowania.

Dane konieczne do wygenerowania informacji o kliencie, adresach dostawy i korespondencji, zużyciu, wynikach pomiarów,

rozliczeniu, zaliczkach należy pobrać zgodnie z aktualnie wykorzystywanymi algorytmami generowania formularzy wydruku,

przy czym ograniczamy się w tym exit tylko do pobrania danych. Wszystkie wyliczenia dodatkowe, przekształcenia tekstów i

inne transformacje danych wykonane powinny zostać w warstwie Interfejsu (patrz 4.1.3 Architektura przetwarzania).

4.4.3.2 Exit dla /RWS/PRNT_GET_PARAMS

Wydruk realizowany jest z wykorzystaniem poddruków jako tło faktur lub rewersu zaliczki. Do dokumentów rozliczeniowych

generowane mogą być dodatkowo inserty bezpośrednio do pliku PDF. W ramach wyprowadzenia kodów kontrolnych dla

maszyny dokładającej inserty dodatkowe (książeczki, broszury i inne) oraz do procesu kopertowania i skanowania

przygotowanych do wysyłki listów konieczne jest pobranie przypisania parametrów wydruku dla poszczególnych KU.

Wszystkie te parametry przechowywane będą w tabeli dodatkowej /RWS/PRNT_KU_PAR. W ramach tego exita należy

pobrać odpowiednie informacje.

4.4.3.3 Exit dla /RWS/PRNT_GET_CUST

Wydruk wielu pozycji dokumentu rozliczeniowego w odniesieniu do szczegółów danych pomiarowych lub linii dokumentu

rozliczenia często odwołuje się do zdefiniowanych w ramach skastomizowanych w RWE nazw przechowywanych w

dodatkowych tabelach.

Należy zachować obecną logikę pobierania tekstów dla obsługi tych wymagań. Wszystkie tego typu informacje powinny być

pobrane w exit /RWS/PRNT_GET_CUST. Należeć będą do nich informacje opisane w kolejnych punktach.

3.1.3 Audyt wydajności rozwiązania

Wykonanie audytu wydajności oprogramowania dostarczonego w ramach projektu GTS Printing poprzez:

Identyfikację i prześledzenie składowych procesu wydruku masowego,

Weryfikację poprawności architektury zbudowanego rozwiązania pod kątem wydajności oraz

standardu SAP,

Weryfikację wydajności poszczególnych składowych w procesie wydruku masowego,

Rekomendację optymalizacji poszczególnych komponentów dostarczonego oprogramowania

obsługującego proces wydruku masowego.

Oczekiwanym produktem zapytania będzie :

1.Przeprowadzenie audytu w zakresie opisanym w pkt. 3.1.1-3.1.3.,

2.Utworzenie raportu z wynikami audytu oraz rekomendacjami optymalizacji i zmian w zakresie opisanym w

pkt. 3.1.1-3.1.3.,

3. Wariant programu Code Insector do dokonywania kolejnych inspekcji przez innogy

Ze względu na to że nie planuje się rozbudowy infrastruktury systemów w których dokonano konfiguracji

projektu GTS Printing w tym roku, Oferent MUSI potwierdzić realizowalność projektu na aktualnej architekturze

fizycznej, lub alternatywnie określić wpływ/wymagania na architekturę fizyczną i sprzętową.

W ramach oferty do niniejszego zapytania oczekiwane jest przedstawienie :




2017-05-22

© innogy BS

Strona 10 z 15

1. oferty cenowej FixPrice na realizację zakresu prac,

2. harmonogramu wraz z propozycją kroków milowych, przy uwzględnieniu kamieni milowych

zaproponowanych przez zamawiającego.

3.2 Kluczowe kamienie milowe

Zamawiający oczekuje, że harmonogram Oferenta będzie zawierał wymienione poniżej kamienie milowe i

uwzględniał zaproponowane przez Zamawiającego daty.

Numer Nazwa Data Czas akceptacji przez

Zamawiającego

KM1 Kick-off Projektu 22.05.2017 Nie dotyczy

KM2 Zakończona faza analizy 1 tydzień po KM1 1 tydzień

KM3 Zakończona faza testów 1 tydzień po KM2 1 tydzień

KM4 Zakończona faza audytu zaraz po zakończeni KM3 1 tydzień

4 Architektura rozwiązania

Brak wymagań w tym zakresie

5 Wymagania pozafunkcjonalne dla rozwiązania

5.1 Technologia realizacji rozwiązania

Wdrażane rozwiązanie POWINNO być zgodne ze standardami technologicznymi Zamawiającego. Standardy te

załączone są jako zestaw osobnych dokumentów do zapytania ofertowego. W przypadku, gdy proponowane

przez Oferenta rozwiązanie nie jest zgodne z którymś ze standardów Zamawiającego Oferent MUSI zaznaczyć

to w swojej ofercie.

Szczegółowe wymagania dla rozwiązania zostały przedstawione w załączonym dokumencie analizy biznesowej.

5.2 Bezpieczeństwo rozwiązania

Wdrażane rozwiązanie POWINNO być zgodne ze standardami bezpieczeństwa Zamawiającego. Standardy te



to w swojej ofercie. Poniżej znajdują się krytyczne dla Zamawiającego wymagania:

Rozwiązanie MUSI realizowało automatyczne uwierzytelnianie przy pomocy konta domenowego oraz MUSI

współdziałać z mechanizmami SSO Zamawiającego (zgodnie z załączonymi standardami),




2017-05-22

© innogy BS

Strona 11 z 15

Rozwiązanie POWINNO posiadać mechanizm uprawnień oparty na rolach (tzw. Role Base Access Control –

RBAC). Więcej informacji ogólnych o uprawnieniach opartych na rolach można znaleźć tu:

http://en.wikipedia.org/wiki/Role-based_access_control,

Rozwiązanie MUSI być przygotowane do przetwarzania danych wrażliwych (zgodnie z definicją GIODO).


Zamawiający zastrzega sobie prawo do wykonania niezależnych testów penetracyjnych rozwiązania po oddaniu

rozwiązania do testów lub po wdrożeniu. Oferent MUSI, niezależnie od momentu zgłoszenia błędu/podatności,

usunąć ją bez dodatkowych kosztów ze strony Zamawiającego. Dotyczy to błędów/podatności oznaczonych

jako krytyczne i wysokie przez niezależne testy penetracyjne. W przypadku niejasności co do interpretacji

poziomów błędów/podatności rozwiązania, do ich rozwiązania stosuje się OWASP Risk Rating Methodology

(https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology).

5.3 Wydajność rozwiązania

Wdrażane rozwiązanie POWINNO zapewnić optymalną wydajność przy założeniu dostępnej architektury

fizycznej.

5.4 Skalowalność rozwiązania

Wdrażane rozwiązanie POWINNO być zgodne ze standardami skalowalności Zamawiającego. Standardy te




5.5 Dostępność i niezawodność rozwiązania

Wdrażane rozwiązanie POWINNO być zgodne ze standardami dostępności i niezawodności Zamawiającego,

przy założeniu, że poziom dostępności i niezawodności dla rozwiązania jest HA (High Availability) – więcej

szczegółów w załączonych do zapytania standardach) - szczegółowe wymagania dla rozwiązania zostały

przedstawione w załączonym dokumencie analizy biznesowej.

W przypadku, gdy rozwiązanie Oferenta nie może działać na infrastrukturze Zamawiającego, która spełnia

powyższe standardy dostępności i niezawodności Oferent powinien zaproponować własną architekturę, w

której będzie zapewniona dostępność i niezawodność na wymaganym poziomie.

5.6 Rozszerzalność rozwiązania

Wdrażane rozwiązanie POWINNO być łatwo rozszerzalne/modyfikowalne w warstwie integracji.


5.7 Zarządzalność rozwiązania

Wdrażane rozwiązanie POWINNO być zgodne ze standardami zarządzalności Zamawiającego. Standardy te





http://en.wikipedia.org/wiki/Role-based_access_control




2017-05-22

© innogy BS

Strona 12 z 15

5.8 Integracja rozwiązania

Wdrażane rozwiązanie powinno być zgodne ze standardami integracyjnymi zamawiającego. Standardy te




5.9 Wymagania prawne i regulacyjne

System MUSI zapewnić zgodność w zakresie polskiego prawa.

5.10 Zasady licencjonowania rozwiązania

Poniżej są wymienione zasady licencjonowania, jakie Oferent może wziąć pod uwagę podczas przygotowywania

oferty.

Licencja MUSI obejmować następujące środowiska i narzędzia:

o Środowisko produkcyjne,

o Środowisko testowe,

o Środowisko developerskie,

o Narzędzia programistyczne,

o Kod źródłowy rozwiązania, jeżeli jest ono dedykowane dla Zamawiającego lub kod

parametryzacji/konfiguracji rozwiązania wykonany na potrzeby projektu dla Zamawiającego.

Licencje MUSZĄ zapewniać Zamawiającemu prawo do udostępniania do modyfikacji rozwiązania wraz ze

związanym z nim wszystkimi produktami, które powstaną w ramach projekty firmom trzecim

współpracującym z Zamawiającym.

Zamawiający dopuszcza następujący sposób licencjonowania:

o Możliwość licencjonowania na pojedyncze stanowisko, z podziałem na użytkownika zwykłego,

zaawansowanego, administratora i programistę,

o Licencjonowanie sieciowe bez ograniczenia liczby stanowisk, na których może być zainstalowana

dana aplikacja),

Zamawiający preferuje możliwość udzielenia licencji korporacyjnej (dla nieograniczonej liczby

użytkowników pracujących jednocześnie).

6 Wymagania dla szkoleń

W ramach projektu nie oczekiwane jest przeprowadzenie szkoleń dla użytkowników.

7 Wymagania formalne

Poniżej są przedstawione wymagania formalne dla systemu.

7.1 Referencje

Do uczestnictwa w postępowaniu uprawnione są podmioty, które:




2017-05-22

© innogy BS

Strona 13 z 15

Wdrożyły przynajmniej 3 audyty kodu systemu SAP w oparciu o standard SAP (wdrożenia zakończone) i

przedstawią referencje dotyczące tych wdrożeń.

Dodatkowym atutem będzie doświadczenie z wdrożeniami w technologii Adobe Forms obsługującej procesy

masowe.

7.2 Dokument odpowiedzi

Dokument odpowiedzi na niniejsze zapytanie ofertowe MUSI spełniać następujące warunki:

MUSI być przygotowana w języku polskim,

MUSI być przygotowany w formacie możliwym do odczytania w MS Office 2003/2007,

MUSI zostać dostarczony w dwóch wersjach: papierowej i elektronicznej,

MUSI być przygotowany w oparciu o załącznik „Szablon odpowiedzi na zapytanie”,

warunki finansowe MUSZĄ być przedstawione w oparciu o dokument „Szablon wyceny kosztów”,

MUSI zawierać wykaz dostarczanych produktów w ramach projektu,

MUSI zawierać wymagania względem Zamawiającego,

MUSI zawierać harmonogram dostarczania poszczególnych produktów/funkcjonalności, który:

o jest zgodny z kamieniami milowymi zaproponowanymi przez Zamawiającego,

o zawiera propozycję podział na zadania realizowane przez Oferenta i Zamawiającego,

o zawiera propozycję terminów zakupu sprzętu (zamawiający zakłada, że nie jest konieczne

zakupywanie całości sprzętu na początku projektu),

o w precyzyjny sposób pokaże poszczególne fazy realizowane w ramach projektu wraz ze wszystkimi

kluczowymi produktami poszczególnych faz ich zakresem oraz sposobem ich odbioru,

MUSI zawierać rekomendację docelowej architektury logicznej i fizycznej obejmującej całe rozwiązanie

zgodnej z wymaganiami do architektury zamieszczonymi w niniejszej specyfikacji i standardami

Zamawiającego,

MUSI zawierać listę niezgodności ze standardami Zamawiającego,

wycena MUSI obejmować pełen zakres prac wymaganych przez Zamawiającego,

wycena MUSI być przygotowana na możliwie wysokim poziomie szczegółowości z uwzględnieniem

zależności funkcjonalnej pomiędzy modułami.

7.3 Zespół wdrożeniowy

Oferent musi przedstawić skład personalny zespołu wdrożeniowego wraz z opisem doświadczenia

zawodowego każdego z członków zespołu.

Oferent powinien zapewnić niezmienność zespołu wdrożeniowego w trakcie wdrożenia.

Każda zmiana składu zespołu wdrożeniowego musi być uzgodniona z Zamawiającym.

7.4 Zapewnienie jakości

Oferent POWINIEN przedstawić metodykę, procesy, najlepsze praktyki oraz narzędzia stosowane przez

firmę w celu zapewnienia jakości produktów w projekcie oraz bezpieczeństwa. Zaznaczone powinno być

które procesy będą miały zastosowanie w planowanym projekcie.




2017-05-22

© innogy BS

Strona 14 z 15

Oferent POWINIEN przedstawić posiadane certyfikaty zarządzania jakością, monitorowania i doskonalenia

procesów wewnętrznych oraz bezpieczeństwa ( np. takie jak standardy ISO, BS, CMMI, Six Sigma, ITIL, etc).

Zamawiający zastrzega sobie prawo do przeprowadzenia audytu w celu oceny systemu jakości. Oferent

zobowiązuje się przedstawić wymaganą dokumentację procesów, raporty z audytów zewnętrznych oraz

wykaz i ocenę podjętych działań usprawniających. Oferent przedstawi proces i wyniki ciągłego

doskonalenia.

Oferent w ramach prowadzenia prac projektowych POWINIEN być gotowy na uczestnictwo w spotkaniach

zbierania doświadczeń.

Oferent w ramach prowadzenia prac projektowych POWINIEN być gotowy na uczestnictwo w spotkaniach

audytowych i weryfikujących status realizacji projektu i jego produktów.

W przypadku zidentyfikowania obszarów do poprawy lub usprawnień Oferent przedstawi plan realizacji.

Dokładny zakres działań w ramach zapewnienia jakości w projekcie zostanie zdefiniowany na początku prac

projektowych.

7.5 Inne

Wymaganiem Zamawiającego jest, aby Oferent potwierdził mailowo chęć uczestnictwa w procesie

przetargowym.

Wymaganiem Zamawiającego jest, aby Oferent mógł rozpocząć prace projektowe po podpisaniu listu

intencyjnego i przed podpisaniem finalnej umowy.

Wymaganiem Zamawiającego jest, aby oferty obejmowały pełny zakres prac i produktów wymienionych

powyżej. Oferty cząstkowe NIE BĘDĄ brane pod uwagę.

Wymaganiem Zamawiającego jest, aby żadna część dostarczanego rozwiązania NIE BYŁA powierzona do

realizacji podwykonawcom bez pisemnej zgody Zamawiającego.

Wymaganiem Zamawiającego jest, aby oferty były ważne przez 90 dni.

Oferent MUSI przygotować ofertę uwzględniającą realizację wszystkich wymagań Zamawiającego oferty,

które nie będą realizować, któryś z przedmiotów zamówienia nie będą brane pod uwagę.

Oferent w ramach procedury ofertowej MUSI być gotowy na przeprowadzenie prezentacji docelowego

rozwiązania. Zamawiający decyduje o potrzebie prezentacji.

Oferent w ramach procedury ofertowej POWINIEN być gotowy na zorganizowanie wizyty referencyjnej

wdrożonego i działającego rozwiązania. Zamawiający decyduje o potrzebie wizyty referencyjnej.

Oferent MUSI zapewnić w ramach oferty dostawę następujących produktów i przeniesienia praw

autorskich na Zamawiającego:

o Struktura bazy danych wraz z dokumentacją opisującą zależności,

o Kodu źródłowego rozwiązania lub kodu parametryzacji/konfiguracji rozwiązania wykonanego na

potrzeby projektu Zamawiającego.

Oferent MUSI przygotować ofertę zgodą ze standardami technologicznymi zamawiającego stanowiącymi

załącznik niniejszych wymagań. W każdym miejscu, w którym oferta Oferenta nie jest zgodna ze

standardami Zamawiającego MUSI być to jednoznacznie napisane w Ofercie.

Zamawiający zastrzega sobie prawo zakończenia projektu po dowolnym z etapów.

8 Załączniki




2017-05-22

© innogy BS

Strona 15 z 15

Poniżej jest przedstawiona pełna lista załączników powiązanych z dokumentem.

Poniższe dokumenty zostaną przesłane oferentom, którzy zgłoszą się do przetargu.

Dokument Opis

Harmonized ABAP Guidelines 2.0

The purpose of this document is to articulate a common and mutually valid set of standards and procedures for naming, development and documentation of SAP ABAP – applications with the goal of maximizing the quality, value, and maintainability of new or existing ABAP development. It is intended as a resource for all ABAP development team members from developers to quality managers delivering solutions for the Group both internally and externally

Analiza_biznesowa_ADS_GTS_Printing_v1 8

RFP projektu GTS Printing

Date post:	31-Mar-2019
Category:	Documents
Upload:	lehanh
View:	219 times
Download:	0 times

Specyfikacja/ Załacznik nr 2 „Audyt kod ABAP w projekcie...

Documents