Metodyka Wdrożenia Magento

Transcript

            METODYKA       Metodyka Budowy Internetowej Platformy Handlowej Data: 20.04.2012r. Wersja 1.0 Dokument przygotowany przez zespół DC S.A.         Odbiorca Klient Biznesowy          1 METODYKA  REALIZACJI  WDROŻENIA     Standardowa  metodyka  procesu  wytwarzania  systemów  e-­‐Commerce  w  DC  S.A.  opartych   zarówno  o  oprogramowanie  dedykowane,  jak  i  narzędzia  e-­‐commerce,  takie  jak  Magento,   SugarCRM,  Drupal  i  ez  Publish  oparty  jest  o  filozofię  „zwinną”  (ang.  Agile)  i  bazuje  na   zasadach  metodologii  RUP  (Rational  Unified  Process).     W  przypadku  projektów  e-­‐commerce,  zespół  DC  S.A.  realizuje  założenia  z  następujących   dyscyplin:   Dyscypliny  inżynierskie  (Engineering  Disciplines):   • • • • • • Modelowanie  biznesowe  (Business  Modeling)   Wymagania  (Requirements)   Analiza  i  projekt  (Analysis  &  design)   Implementacja  (Implementation)   Testowanie  (Test)   Wdrożenie  i  odbiór  (Deployment  &  acceptance)   Dyscypliny  pomocnicze  (Supporting  Disciplines):   • • • Zarządzanie  zmianami  oraz  konfiguracją  (Configuration  &  Change  Management)   Środowisko  (Environment)   Narzędzia  (Tools)   Podejście  w  realizacji  zadań  w  dyscyplinach:  Implementacja  i  Testowanie  ma  charakter   iteracyjny  i  częściowo  równoległy,  tzn.  dyscypliny  te  realizowane  są  w  kilku  podejściach:       • • • • • • Modelowanie  biznesowe  i  wymagania   Analiza  i  projekt  (w  tym  szata  graficzna,  patrz  poniżej)   Iteracja  1  +  Testowanie  1   Iteracja  2  +  Testowanie  2   ...  Iteracja  N  +  Testowanie  N   Wdrożenie  i  odbiór   Poniższy  rysunek  zawiera  graficzne  odwzorowanie  procesu  wytwórczego:            Cały  projekt  wdrożenia  Magento  podzielony  jest  na  szereg  grup  zadań.  W  każdej  grupie   zadania  realizowane  są  zarówno  przez  klienta  jak  i  DC  S.A.     1.1.1 Modelowanie  biznesowe  (BM)   Modelowanie  biznesowe  procesów  ma  na  celu  odwzorowanie  potrzeb  biznesowych   organizacji  klienta  i  opisanie  ich  w  formie  modeli,  zrozumiałych  przez  inżynierów   programowania.     Celem  modelowania  biznesowego  jest  opracowanie  wspólnego  języka  i  procesu  komunikacji   pomiędzy  biznesem  (tzw.  business  engineering),  a  programistami  –  autorami  rozwiązania   informatycznego.  Podejście  takie  pozwala  inżynierom  oprogramowania  zrozumieć  strukturę,   dynamikę  oraz  problemy  biznesowe  w  organizacji  klienta.  Zdefiniowane  i  jednakowo   rozumiane  przez  stronę  biznesową  i  programistyczną  zagadnienia  pozwolą  na  budowę   takiego  rozwiązania  informatycznego,  które  rzeczywiście  usprawnieni  działanie  organizacji   klienta.     Modelowanie  obejmuje  opis  sekwencji  działań  oraz  schemat  procesu.  W    projektach  DC  S.A.   do  graficznej  prezentacji  i  dokumentacji  procesów  używana  jest  notacja  BPMN  (Business   Process  Management  Notation).  Notacja  BPMN  opisuje  zarówno  atrybuty  jak  i  sekwencję   działań  (obieg  informacji),  jest  standardem  dobrze  rozumianym  przez  świat  biznesu  jak  i   informatyki.  To  sprawia,  że  jest  chętnie  używana  przez  konsultantów,  analityków   biznesowych  oraz  projektantów  przy  budowie    systemów  informatycznych.   1.1.2 Wymagania  (R)   Najprościej  ujmując  celem  Wymagań  jest  opisanie  tego  co  system  powinien  robić.   Wymagania  zbierane  są  w  wyniku  dyskusji  i  uzgodnień  pomiędzy  twórcami  systemu  a   klientem  i  dokumentowane  przez  analityków.   Dokument  opisujący  wymagania  zawiera  identyfikację  aktorów  (actors)  reprezentujących   użytkowników  i  inne  systemy  mogące  mieć  wpływ  na  wytwarzany  system.  Wymagania   identyfikują  również  przypadki  użycia  (use  cases),  które  reprezentują  zachowanie  systemu.   Każdy  przypadek  użycia  jest  opisany  w  szczegółach.  Opis  przypadków  użycia  obrazuje  krok  po   kroku  interakcję  systemu  z  aktorami  (podmiotami  procesu)  oraz  określa  co  jest  realizowane        przez  system.  Przypadki  użycia  są  jednolite  w  całym  cyklu  wytwarzania  systemu,  tzn.  ten  sam   model  przypadku  użycia  jest  używany  podczas  wymagań,  analizy  i  projektu,  testu.  Dzięki   użyciu  graficznego  projektowania  poszczególnych  kroków  działania  systemu  (tzw.   Storyboardy/wire-­‐frame’y),  wynik  działań  dyscypliny  Wymagań  zrozumiały  jest  zarówno  dla   inżynierów  oprogramowania  jak  i  dla  pracowników  biznesowych  klienta.   1.1.3 Analiza  i  projekt  (A&D)   Celem  A&D  jest  pokazanie  jak  system  będzie  zrealizowany  w  fazie  implementacji.  Według   metodyki,  ma  to  być  system  który:   • • • • Oparty  jest  o  ustaloną  szatę  graficzną   Realizuje  zadania  i  funkcjonalność  określone  w  przypadkach  użycia   Spełnia  wszystkie  wymagania  zdefiniowane  w  definicji  wymagań   Jest  zaprojektowany  w  sposób  umożliwiający  łatwą  jego  zmianę  w  przypadku  gdy   zmienią  się  wymagania  funkcjonalne.     W  przypadku  realizacji  systemu  opartego  o  gotowe  pakiety  (np.  Magento)  dyscyplina  A&D   koncentruje  się  na  wizualizacji  części  klienckiej  oraz    sprecyzowaniu  które  funkcjonalności   Magento  wykorzystywane  będą  do  realizacji  założonych  zadań  i  funkcjonalności,  a  w   szczególności:   • • • • Jakie  dodatki  (extensions)  Magento  zostaną  wykorzystane   Czy  jest  konieczność  programowania  dodatkowych  dodatków   W  jaki  sposób  instancja  Magento  zostanie  sparametryzowana   Jaka  dokładnie  szata  graficzna  będzie  wykorzystana  we  frontowych  (do  klienta)   częściach  systemu   1.1.4 Implementacja  (I)   Cele  implementacji  są  następujące:   • • • • • • • Instalacja  systemu  i  jego  wstępna  konfiguracja   Wdrożenie  docelowej  szaty  graficznej  w  języku  HTML  i  template’ach  Magento   Zainstalowanie  dodatków  (extensions)   Implementacja  klas  i  obiektów  w  zakresie  dodatkowych  extensions  (pliki  źródłowe,   pliki  binarne,  pliki  wykonywalne  i  inne)   Parametryzacja  systemu  w  zakresie  obsługi  procesów  biznesowych  klienta   Przeprowadzenie  testów  jednostkowych   Integracja  rezultatów  wytworzonych  przez  indywidualnych  programistów  (lub   zespoły)  w  jeden,  spójny  i    działający  system.        1.1.5 Testy  (T)   Testy  finalne  systemu  odbywają  się  na  serwerze  pre-­‐produkcyjnym  i  obejmują  całość   funkcjonalności  platformy.  Cele  testów  są  następujące:   • • • • Weryfikacja  interakcji  pomiędzy  obiektami   Weryfikacja  właściwej  integracji  pomiędzy  wszystkimi  systemami  zintegrowanymi  z   platformą   Weryfikacja  czy  wszystkie  wymagania  zostały  prawidłowo  zaimplementowane  w   systemie   Weryfikacja  czy  wszystkie  błędy  systemu  zostały  usunięte   1.1.6 Wdrożenie  i  odbiór  (D&A)   Celem  D&A  jest  wytworzenie  wersji  dystrybuowanej  produktu  i  dostarczenie  jej  do   użytkownika  końcowego.  Wdrożenie  obejmuje  następujące  czynności:   • • • • Wytworzenie  wersji  produkcyjnej  oprogramowania,  tzw.  Releases   Instalacja  oprogramowania  na  ostatecznym  serwerze  (+  wsparcie  w  zakresie  instalacji   komponentów  infrastrukturalnych:  serwer  web,  instalacja  certyfikatu  SSL,  parametry   Drobne  poprawki  funkcjonalne  problemów  zauważonych  podczas  wdrożenia   Dostarczenie  wsparcia  dla  użytkowników  (dokumentacja)   Na  tym  etapie  następuje  odbiór  prac  przez  klienta  i  rozpoczęta  jest  opcjonalna  faza  wsparcia.   1.2 DYSCYPLINY  POMOCNICZE   Oprócz  dyscyplin  głównych  (inżynierskich),  w  trakcie  projektu  realizowane  są   również  założenia  dyscyplin  pomocniczych  opisanych  poniżej   1.2.1 Zarządzanie  zmianami  oraz  konfiguracją  (C&CM)   Zarządzanie  zmianami  opisuje  jak  zarządzać  artefaktami  produkowanymi  przez  wielu  ludzi   pracujących  we  wspólnym  projekcie.  Narzędzia,  które  zostaną  wykorzystane  w  projekcie,   zostały  opisane  w  dalszej  części  dokumentu.   1.2.2 Środowisko  (E)   Celem  Środowiska  jest  umiejscowienie  wytwarzanego  oprogramowania  razem  z   oprogramowaniem  środowiska  –  dostarczając  procesy  i  narzędzia  niezbędne  do  realizacji   poszczególnych  produktów.          1.3  NARZĘDZIA   Aby  umożliwić  kontrolowany  przebieg  projektu,  nasza  firma  proponuje  wdrożenie  narzędzi   służących  do  przechowywania  i  dokumentowania  produktów  procesu  oraz  kontroli   komunikacji  pomiędzy  stronami.  Na  potrzeby  Państwa  projektu  proponujemy  zestaw   narzędzi  używanych  tradycyjnie  we  wszystkich  projektach  DC  S.A..  Koszty  związane  z   narzędziami  (ewentualne  licencje,  infrastruktura  projektowa)  są  w  całości  pokryte  przez  DC   S.A.  przez  cały  czas  trwania  projektu.   1.3.1 Komunikacja:  listy  dyskusyjne   Listy  dyskusyjne  (mailing  lists)  są    narzędziem  do  wymiany  informacji  pomiędzy  stronami.  Dla   potrzeb  każdego  projektu,  nasza  firma  zakłada  jedną  lub  więcej  list  dyskusyjnych  na  serwerze   dostępnym  przez  sieć  Internet,  dla  każdego  uczestnika  projektu  w  takim  zakresie  jaki  wynika   z  jego  uprawnień.     Filozofia  realizacji  projektów  DC  S.A.  zakłada  maksymalne  wykorzystanie  tego  narzędzia  do     wymiany  wiadomości  pomiędzy  członkami  projektu.  Rozwiązuje  to  problem  „ustaleń   równoległych”,  gdzie  niezależnie  w  projekcie  toczą  się  dyskusje  na  ten  sam  temat  i  dochodzi   do  sprzecznych  ustaleń.     1.3.2 Narzędzia  komunikacji  natychmiastowej   Wymiany  e-­‐mailowe  nie  zawsze  nadają  się  do  szybkiego  uzgadniania  precyzyjnych  punktów,   bez  znaczenia  dla  strategii  projektu.  Wtedy  preferujemy  szybką  wymianę  dzięki  narzędziom   komunikacji  natychmiastowej.  W  DC  S.A.  używamy  narzędzia  Microsoft  Lync  do   zintegrowanego  zarządzania  obecnością/statusem/chatem/voice  i  wideo.  Z  klientami   wykorzystywany  jest  zarówno  Microsoft  Lync  jak  i  narzędzie  Skype.   1.3.3 Projektowanie  aplikacji:  wireframes   W  wypadku  aplikacji  biznesowych,  dobre  zrozumienie  potrzeb  i  procesów  klienta  jest   podstawą  do  zapewnienia  odpowiednich  wyników  projektu.  Dlatego  też  głównym   narzędziem  do  zbierania  wymagań  jest  aplikacja  do  realizacji  tzw.  wireframes,  czyli   wizualnego  przedstawienia  ekranów  docelowej  aplikacji.  Aplikacja  pozwala  na  eksport   zestawu  wireframes  do  prototypu  w  języku  HTML,  dając  tym  samym  możliwość  szybkiego   sprawdzenia  poszczególnych  funkcjonalności  przez  osoby  biznesowe,  bez  wiedzy  technicznej.   1.3.4 Zarządzanie  zmianami  i  konfiguracją:  subversion   Całość  kodu  źródłowego  aplikacji  znajduje  się  pod  kontrolą  systemu  zarządzania  zmianami   Subversion  (SVN).  Narzędzie  może  być  zainstalowane  u  klienta,  lub  na  serwerze  DC  S.A.     Pozwala  to  osobom  z  części  technicznej  Państwa  zespołu  na  bieżącą  kontrolę  jakości  prac   naszej  firmy.        1.3.5 Extranet  projektu   Każdy  projekt  DC  S.A.  używa  zintegrowanego  narzędzia  Redmine  jako  podstawa  extranetu   projektu.  Redmine  używany  jest  jako:   -­‐ -­‐ -­‐ -­‐       Baza  wiki  –  do  dokumentacji  projektu  i  notatek  po  spotkaniach   Wizualizacja  źródeł  (podłączona  w  czasie  rzeczywistym  do  SVN)   Zarządzanie  zmianami  i  anomaliami  za  pomocą  wbudowanego  issue  trackera   Roadmapa  –  czytelny  widok  stanu  projektu  i  zadań  do  wykonania        2 TYPOWY  SPOSÓB  REALIZACJI   Poniżej  przedstawiony  został  przykładowy  scenariusz  sposobu  realizacji  działań   projektowych:   • Przygotowanie  projektu   o Zawiązanie  projektu,  komitet  pilotażowy   o Środowisko  testowe   o Konfiguracja  ekstranetu  projektu   Business  modeling   o Warsztaty  BM   o Realizacja  dokumentacji   Wymagania   o Spotkania   o Storyboardy     o Analiza  dokumentacji  integracyjnej   o Realizacja  dokumentu  wymagań   Analiza  i  projekt   o Mapowanie  funkcjonalności  na  sposoby  realizacyjne  w  obszarze  aplikacji   Magento  lub  poza  nią   o Szata  graficzna   o Poprawki  do  szaty  graficznej   o Projekt  techniczny  Magento   o Projekt  techniczny  integracji   Implementacja  i  Testy   o Tutaj  wszystkie  zadania  implementacyjne     Wdrożenie  i  odbiór   o Testy  integracyjne   o Poprawki  po  testach  integracyjnych   o Wdrożenie  na  produkcji   o Szkolenia  administratorów   o Wsparcie  powdrożeniowe   • • • • •   2.1 KWALIFIKACJA  OBSZARÓW  REALIZACYJNYCH   Każdy  projekt  e-­‐commerce  zawiera  wymagania  które  mogą  być  zrealizowane  różnymi   środkami;  aplikacją  Magento  lub  poza  nią.  W  DC  mapujemy  obszary  funkcjonalne  określone   zakresem  projektowym  na  Sposoby  Realizacji,  jakimi  będą  wykonane  w  ramach  projektu.   Wyróżniamy  następujące  klasy  Sposoby  Realizacji:        1. Standard  Magento  –  Oznacza,  że  dana  funkcjonalność  może  być  zrealizowana   standardowymi  środkami  Mogento  (wybranej  edycji:  Enterprise  lub  Community).   Wdrożenie  tej  funkcjonalności  wymaga  jedynie  parametryzacji  Systemu.   2. Extension  –  Oznacza  konieczność  zakupu  licencji  wskazanego  Magento  Extension  i  jego   wdrożenia  oraz  parametryzacji.     3. Programowanie  Templates  –  oznacza  usługi  programistyczne  w  warstwie  wizualizacji  z   wykorzystaniem  narzędzi  HTML/CSS/JS  oraz  szablony  Magento  w  PHP     4. Programowanie  Ogólne  –  oznacza  prace  programistyczne  prowadzące  do  rozszerzenia   lub  modyfikacji  funkcjonalności  podstawowych  systemu  Magento         5. Prace  dodatkowe  –  prace  wymagane  do  realizacji  poza  środowiskiem  Magento     Proces  mapowania  zobrazowany  jest  w  tabeli,  której  przykładowa  struktura  zaprezentowana   została  poniżej.                     Standard  Magento           Programowanie   Templates       Programowanie       x                           x           x           Prace  Dodatkowe                                                       Referencja Wymaganie  Funkcjonalne Uwagi   Extension   Obszar  "Konfiguracja  platformy  technicznej"   Zarządzanie  położeniem  boksów  (same  boksy  zdefiniowane  w   1.1   momencie  implementacji)       Zarządzanie  formularzami  kontaktowymi  (adresy  email   1.2   docelowe  i  pola)  -­‐  patrz  też  5.2   1.3   Zarządzanie  treścią  (strona  główna,  strony  pomocnicze)   1.4   Zarządzanie  bazą  multimediów  (zdjęcia,  thumbnails...)       Obszar  "Produkty"   Interfejs  backoffice  do  zarządzania  produktami:  lista,  szczegóły,   2.1   edycja   2.2.   Interfejs  backoffice  do  zarządzania  produktami:  wyszukiwarka   2.3   Zarządzanie  autorami  i  podpinanie  do  produktów       Obszar  "Użytkownicy"   Moduł  użytkowników  -­‐  definicja  i  implementacja  uprawnień  w   systemie   3.1                                                   x   x   x       x   x                                                       x                                   3.2   Zarządzanie  autorami  i  podpinanie  do  produktów                       x           Aitec   Advanced   Permissions                         Metodyka  oraz  sposób  realizacji  opisane  powyżej  są  punktem  wyjścia  do  oceny   pracochłonności  projektu,  wymaganych  zasobów  własnych  i  podwykonawczych.          3 ORGANIZACJA  PROJEKTU   Poniżej  przedstawiliśmy  Strukturę  Organizacyjną  Projektu.  Celem  powołania  jej  jest   zapewnienie  sprawnego  obiegu  informacji  i  elementarnego  podziału  odpowiedzialności   pomiędzy  członkami  zespołu  projektowego.   Proponowana  struktura  organizacyjna  jest  tzw.  strukturą  „lekką”,  zapewniającą  wszystkie   potrzebne  funkcje  projektowe  ale  eliminującą  zbędne  elementy  biurokratyczne.   3.1 STRUKTURA  ORGANIZACYJNA   Na  poniższym  rysunku  pokazano  strukturę  organizacyjną  projektu.  Opis  ról  i   odpowiedzialności  opisany  jest  w  dalszej  części  rozdziału.     Komitet  Sterujący Sponsor  Projektu Dyrektor  Projektu Kierownik  Projektu Zamawiającego Kierownik  Projektu Wykonawcy Kontroler  Jakości Biuro  Projektu Architekt  Rozwiązania Użytkownicy  Kluczowi Konsultanci/Programiści     3.2 ROLE  PROJEKTOWE   Wypełnieniem  Struktury  Organizacyjnej  Projektu  jest  przypisanie  poszczególnym  jej   elementom  tzw.  Ról  projektowych.  Role  powinny  być  zdefiniowane  na  początku  projektu  i   jednoznacznie  przypisane  do  konkretnych  osób.   Na  potrzeby  niniejszego  Planu  Projektu  poszczególne  role  projektowe  zostały  zdefiniowane   następująco:        1. 2. 3. 4. 5. 6. 7. 8. 9. Komitet  Sterujący   Sponsor  Projektu     Dyrektor  Projektu     Kierownik  Projektu  Zamawiającego     Kierownik  Projektu  Wykonawcy   Architekt  Rozwiązania   Kontroler  Jakości   Konsultanci/Programiści   Użytkownicy  Kluczowi     Dodatkowo,  w  celu  zapewnienia  kontroli  jakości  po  stronie  Zamawiającego  określono  role   tzw.  Kontrolera  Jakości  (rola  odpowiedzialna  za  wydawanie  rekomendacji  dot.  realizowanego   produktu.     3.2.1 Komitet  Sterujący   Komitet  Sterujący  –  powołany  na  wniosek  Zarządu  Zamawiającego  -­‐  jest  organem   decyzyjnym  we  wszystkich  sprawach  dotyczących  przebiegu  prac  projektowych.  Decyzje   Komitetu  Sterującego  wiążą  Strony  i  stanowią  podstawę  do  żądania  zawarcia    określonych  w   decyzji  umów  lub  aneksów.  Do  zadań  Komitetu  Sterującego  należą:   1. Wyznaczanie  ogólnych  dyrektyw  wykonywania  poszczególnych  prac.   2. Podejmowanie   decyzji   o   zatwierdzaniu   wyników   prac   poszczególnych   etapów   projektu.   3. Akceptacja   okresowych   raportów   dotyczących   stanu   projektu   przedstawianych   przez  Kierownika  Projektu  Wykonawcy  i  Kierownika  Projektu  Zamawiającego.   4. Podejmowanie   decyzji   rozwiązujących   pojawiające   się   poważne   problemy   i   zagrożenia  dla  powodzenia  całego  projektu.   5. Akceptacja   proponowanych   przez   Kierowników   Projektu   zmian   w   zakresie   harmonogramu  i  budżetu.   6. Delegowanie  uprawnień  decyzyjnych  na  poziom  Kierowników  Projektu.   Spotkania  Komitetu  Sterującego  projektu  odbywać  się  będą  raz  na  miesiąc.  W  przypadku   zaistnienia  ważnych  problemów,  na  wniosek  Kierownika  Projektu  Zamawiającego  i   Kierownika  Projektu  Wykonawcy;  spotkanie  może  zostać  zwołane  w  dodatkowym  terminie.   Za  zgodą  obu  Stron  spotkania  Komitetu  Sterującego  mogą  odbywać  się  zdalnie,  z   wykorzystaniem  urządzeń  do  telekonferencji.   W  skład  Komitetu  Sterującego  wejdą:  Sponsor  Projektu  Zamawiającego,  Kierownicy   Projektów  Stron  i  inne  osoby  wskazane  i  umocowane  przez  Strony  Umowy.       3.2.2 Sponsor  Projektu   Sponsor  Projektu  Zamawiającego  odpowiada  za:        1. Informowanie   Komitetu   Sterującego   o   zmianach   organizacyjnych   Zamawiającego,   mających  wpływ  na  proces  realizacji  projektu.   2. Bieżące  informowanie  kierownictwa  Zamawiającego  o  stanie  zaawansowania  prac   projektu   3. Zapewnienie  dostępności  odpowiednich  funduszy,   4. Zatwierdzanie   zmian   w   projekcie   ze   strony   Zamawiającego,   w   zakresie   określonym  przez  Komitet  Sterujący.   5. Wnioskowanie  o  zwoływanie  posiedzeń  Komitetu  Sterującego.   6. Sponsor  Projektu  Zamawiającego  jest  członkiem  Komitetu  Sterującego     3.2.3 Dyrektor  Projektu   Dyrektor  Projektu  Wykonawcy  odpowiada  za:   1. Informowanie   Komitetu   Sterującego   o   zmianach   organizacyjnych   Wykonawcy   mających  wpływ  na  proces  realizacji  projektu.     2. Bieżące  informowanie  kierownictwa  Zamawiającego  o  stanie  zaawansowania  prac   projektu   3. Zapewnienie   dostępności   odpowiednich   zasobów   projektowych   po   stronie   Wykonawcy,   4. Zatwierdzanie   zmian   w   projekcie   ze   strony   Zamawiającego,   w   zakresie   określonym  przez  Komitet  Sterujący.   5. Wnioskowanie  o  zwoływanie  posiedzeń  Komitetu  Sterującego.   6. Dyrektor  Projektu  Wykonawcy  jest  członkiem  Komitetu  Sterującego       3.2.4 Kierownik  Projektu  Zamawiającego     Kierownik  Projektu  Zamawiającego  odpowiada  za:   1. Bieżącą   współpracę   z   Wykonawcą   –   poprzez   Kierownika   Projektu   Wykonawcy   -­‐   w   przygotowaniu,  modyfikacji  i  koordynacji  planu  projektu,     2. Informowanie   Komitetu   Sterującego   o   zmianach   organizacyjnych   Zamawiającego,   mających  wpływ  na  proces  realizacji  projektu.   3. Zapewnienie  dostępności  odpowiednich  funduszy,   4. Zatwierdzanie   zmian   w   projekcie   ze   strony   Zamawiającego,   w   zakresie   określonym  przez  Komitet  Sterujący.   5. Zagwarantowanie   kompetentnego   składu   zespołu   projektowego   po   stronie   Zamawiającego   6. Zagwarantowanie   dostępności   oddelegowanych   do   projektu   pracowników   Zamawiającego        7. Zagwarantowanie  dostępności  i  udostępnienie  odpowiednich  zasobów  ze  strony   Zamawiającego   (infrastruktury   i   sprzętu,   pomieszczeń   etc.),   na   warunkach   ustalonych  z  Wykonawcą,     8. Monitorowanie   i   kontrolę   kosztów,   harmonogramu,   problemów   technicznych,   zakresu,  priorytetów  projektu  i  podejmowanie  odpowiednich  działań     9. Informowanie   Komitetu   Sterującego   o   postępach   Wdrożenia   w   stosunku   do   zatwierdzonego  planu  oraz  wykorzystania  budżetu  projektu     3.2.5 Kierownik  Projektu  Wykonawcy   Kierownik  Projektu  Zamawiającego  odpowiada  za:   1. Informowanie   Komitetu   Sterującego   o   zmianach   organizacyjnych   Wykonawcy   mających  wpływ  na  proces  realizacji  projektu.     2. Zapewnienie   dostępności   odpowiednich   zasobów   projektowych   po   stronie   Wykonawcy,   3. Zatwierdzanie   zmian   w   projekcie   ze   strony   Zamawiającego,   w   zakresie   określonym  przez  Komitet  Sterujący.   4. Bieżącą   współpracę   z   Zamawiającym   –   poprzez   Kierownika   Projektu   Zamawiającego   5. Kierowanie  pracą  zespołu  wdrożeniowego  i  monitorowanie  działań  związanych  z   realizacją  projektu   6. Przygotowanie,  modyfikację  i  koordynację  realizacji  planu  projektu,     7. Opracowanie   harmonogramu   i   innych   dokumentów   projektowych   zgodnych   z   przyjętą  metodyką  projektu         8. Planowanie   niezbędnych   zasobów,   zarządzanie   zasobami   ludzkimi   po   stronie   Wykonawcy   9. Monitorowanie   i   kontrolę   kosztów,   harmonogramu,   problemów   technicznych,   zakresu,  priorytetów  projektu  i  podejmowanie  odpowiednich  działań     10. Monitorowanie    ryzyka  w  procesie     11. Informowanie   Komitetu   Sterującego   o   postępach   Wdrożenia   w   stosunku   do   zatwierdzonego  planu  oraz  wykorzystania  budżetu  projektu     3.2.6 Architekt  Rozwiązania     Architekt  Rozwiązania  posiada  kilka  zakresów  odpowiedzialności  w  projekcie.   1. Zadaniem   Architekta   Rozwiązania   jest   systematyczna   weryfikacja   architektury   i   funkcjonalności  powstającego  rozwiązania  ze  względu  na:   a. przyjęte  założenia  wyjściowe  architektury  projektu   b. bieżące  zmiany  uwarunkowań  istotnych  dla  projektu,     c. wymagane  powiązania  wdrażanego  rozwiązania  z  innymi  systemami        2. Do   obowiązków   Architekta   Rozwiązania   należy   opiniowanie   dokumentacji   określającej  architekturę  i  kluczowe  funkcjonalności  rozwiązania     3. Architekt   Rozwiązania   współpracuje   z   Kierownikiem   Projektu   Zamawiającego   i   Wykonawcy   oraz   innymi   osobami   zaangażowanymi   w   realizację   projektu   w   czasie   i   zakresie  niezbędnym  do  realizacji  swoich  zadań   3.2.7 Kontroler  Jakości     Kontroler  Jakości  odpowiada  za:   1. Systematyczną   weryfikację   architektury   i   funkcjonalności   powstającego   rozwiązania   ze  względu  na:   a. przyjęte  założenia  wyjściowe  architektury  projektu   b. bieżące  zmiany  uwarunkowań  istotnych  dla  projektu,     c. wymagane  powiązania  wdrażanego  rozwiązania  z  innymi  systemami   d. normy   jakości   wynikające   z   polityki   jakości   stosowanej   w   Projekcie   i   normy   jakości  definiowane  przez  Zamawiającego   2. Do   obowiązków   Kontrolera   Jakości   należy   opiniowanie   dokumentacji   określającej   architekturę  i  kluczowe  funkcjonalności  rozwiązania  i  wydawanie  rekomendacji  do  ich   akceptacji   3. Kontroler  Jakości  współpracuje  z  Kierownikiem  Projektu  Zamawiającego  i  Wykonawcy   (w   zakresie   pozyskiwania   materiałów   i   produktów   do   weryfikacji)   a   swoje   rekomendacje   przedstawia   Komitetowi   Sterującemu   celem   dokonywania   akceptacji   jakościowych,  merytorycznych  i  formalnych   3.2.8 Użytkownicy  Kluczowi     Użytkownicy  Kluczowi  są  pracownikami  Zamawiającego  i  powoływani  są  przez  Kierownika     Projektu  Zamawiającego.  Do  zakresu  ich  obowiązków  należy:   1. współpraca   z   konsultantami   Wykonawcy   w   ramach   zespołów   wdrożeniowych   w   trakcie  całego  Wdrożenia     2. zdobywanie   doświadczenia   w   użytkowaniu   systemu   i   przekazywanie   swojej   wiedzy  pozostałym  pracownikom  Zamawiającego   3. przygotowanie   danych   historycznych   dla   potrzeb   migracji   do   wdrażanego   systemu   4. testowanie   opracowanych   procesów,   raportów   i   interfejsów;   współudział   w   określeniu   i   przygotowaniu   danych   i   scenariuszy   na   potrzeby   testów   akceptacyjnych,  przeprowadzenie  testów   3.2.9 Konsultanci/Programiści     Konsultanci  są  pracownikami  Wykonawcy  i  powoływani  są  przez  Kierownika    Projektu   Wykonawcy.  Do  zakresu  ich  obowiązków  należy:        1. współpraca  z  Użytkownikami  Kluczowymi  w  ramach  zespołów  wdrożeniowych  w   trakcie  całego  Wdrożenia     2. realizacja   prac   projektowych   wynikających   z   metodyki   prowadzenia   projektu   i   zakresu  merytorycznego  przedsięwzięcia   3. migracji  danych  do  wdrażanego  systemu   4. współudział   w   testowaniu   opracowanych   procesów,   raportów   i   interfejsów;   określenie   i   przygotowanie   danych   i   scenariuszy   na   potrzeby   testów   akceptacyjnych,  wsparcie  Użytkowników  Kluczowych  w  przeprowadzeniu  testów.     3.2.10 Biuro  Projektu     Biuro  Projektu  jest  meta-­‐zespołem  którego  rolą  jest  składowanie  efektów  pracy  zespołu   projektowego  Wykonawcy  i  Zamawiającego.  Pełni  rolę  opiekuna  Repozytorium   Dokumentacji  Projektowej.  Najczęściej  strony  delegują  do  Biura  Projektu  osoby  zajmujące   się  logistyką  i  sprawami  organizacyjnymi.  Szefem  Biura  Projektu  jest  Kierownik  Projektu   Wykonawcy.       Zapraszamy  do  odwiedzenia  naszej  strony  www.dc.com.pl  i  do  kontaktu  telefonicznego     Mobile:  (48)  517  517  601  lub  mailowego:  [email protected]