METODYKA. Metodyka Budowy Internetowej Platformy Handlowej. Data: r. Wersja 1.0. Dokument przygotowany przez zespół DC S.A.

Transkrypt

1 METODYKA Metodyka Budowy Internetowej Platformy Handlowej Data: r. Wersja 1.0 Dokument przygotowany przez zespół DC S.A. Odbiorca Klient Biznesowy

2 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:

3 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 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 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

4 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 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 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.

5 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 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 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 Ś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.

6 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 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ń 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 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 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.

7 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

8 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:

9 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. Referencja Wymaganie Funkcjonalne Uwagi Standard Magento Extension Programowanie Templates Programowanie Prace Dodatkowe Obszar "Konfiguracja platformy technicznej" Zarządzanie położeniem boksów (same boksy zdefiniowane w momencie implementacji) x x Zarządzanie formularzami kontaktowymi (adresy docelowe i pola) - patrz też Zarządzanie treścią (strona główna, strony pomocnicze) x 1.4 Zarządzanie bazą multimediów (zdjęcia, thumbnails...) x Obszar "Produkty" 2.1 Interfejs backoffice do zarządzania produktami: lista, szczegóły, edycja x 2.2. Interfejs backoffice do zarządzania produktami: wyszukiwarka x 2.3 Zarządzanie autorami i podpinanie do produktów x Obszar "Użytkownicy" Moduł użytkowników - definicja i implementacja uprawnień w systemie 3.1 Aitec Advanced x Permissions 3.2 Zarządzanie autorami i podpinanie do produktów x x 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.

10 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:

11 1. Komitet Sterujący 2. Sponsor Projektu 3. Dyrektor Projektu 4. Kierownik Projektu Zamawiającego 5. Kierownik Projektu Wykonawcy 6. Architekt Rozwiązania 7. Kontroler Jakości 8. Konsultanci/Programiści 9. 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 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 Sponsor Projektu Sponsor Projektu Zamawiającego odpowiada za:

12 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 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 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

13 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 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 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

14 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ń 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 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 Konsultanci/Programiści Konsultanci są pracownikami Wykonawcy i powoływani są przez Kierownika Projektu Wykonawcy. Do zakresu ich obowiązków należy:

15 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 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 i do kontaktu telefonicznego Mobile: (48) lub mailowego: dariusz.kakol@dc.com.pl