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 WDROENIA

Standardowa metodyka procesu wytwarzania systemw e-Commerce w DC S.A. opartych zarwno o oprogramowanie dedykowane, jak i narzdzia 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 projektw e-commerce, zesp DC S.A. realizuje zaoenia z nastpujcych dyscyplin: Dyscypliny inynierskie (Engineering Disciplines): Modelowanie biznesowe (Business Modeling) Wymagania (Requirements) Analiza i projekt (Analysis & design) Implementacja (Implementation) Testowanie (Test) Wdroenie i odbir (Deployment & acceptance)

Dyscypliny pomocnicze (Supporting Disciplines): Zarzdzanie zmianami oraz konfiguracj (Configuration & Change Management) rodowisko (Environment) Narzdzia (Tools)

Podejcie w realizacji zada w dyscyplinach: Implementacja i Testowanie ma charakter iteracyjny i czciowo rwnolegy, tzn. dyscypliny te realizowane s w kilku podejciach: Modelowanie biznesowe i wymagania Analiza i projekt (w tym szata graficzna, patrz poniej) Iteracja 1 + Testowanie 1 Iteracja 2 + Testowanie 2 ... Iteracja N + Testowanie N Wdroenie i odbir

Poniszy rysunek zawiera graficzne odwzorowanie procesu wytwrczego:

Cay projekt wdroenia Magento podzielony jest na szereg grup zada. W kadej grupie zadania realizowane s zarwno przez klienta jak i DC S.A. 1.1.1 Modelowanie biznesowe (BM) Modelowanie biznesowe procesw ma na celu odwzorowanie potrzeb biznesowych organizacji klienta i opisanie ich w formie modeli, zrozumiaych przez inynierw programowania. Celem modelowania biznesowego jest opracowanie wsplnego jzyka i procesu komunikacji pomidzy biznesem (tzw. business engineering), a programistami autorami rozwizania informatycznego. Podejcie takie pozwala inynierom oprogramowania zrozumie struktur, dynamik oraz problemy biznesowe w organizacji klienta. Zdefiniowane i jednakowo rozumiane przez stron biznesow i programistyczn zagadnienia pozwol na budow takiego rozwizania informatycznego, ktre rzeczywicie usprawnieni dziaanie organizacji klienta. Modelowanie obejmuje opis sekwencji dziaa oraz schemat procesu. W projektach DC S.A. do graficznej prezentacji i dokumentacji procesw uywana jest notacja BPMN (Business Process Management Notation). Notacja BPMN opisuje zarwno atrybuty jak i sekwencj dziaa (obieg informacji), jest standardem dobrze rozumianym przez wiat biznesu jak i informatyki. To sprawia, e jest chtnie uywana przez konsultantw, analitykw biznesowych oraz projektantw przy budowie systemw informatycznych. 1.1.2 Wymagania (R) Najprociej ujmujc celem Wymaga jest opisanie tego co system powinien robi. Wymagania zbierane s w wyniku dyskusji i uzgodnie pomidzy twrcami systemu a klientem i dokumentowane przez analitykw. Dokument opisujcy wymagania zawiera identyfikacj aktorw (actors) reprezentujcych uytkownikw i inne systemy mogce mie wpyw na wytwarzany system. Wymagania identyfikuj rwnie przypadki uycia (use cases), ktre reprezentuj zachowanie systemu. Kady przypadek uycia jest opisany w szczegach. Opis przypadkw uycia obrazuje krok po kroku interakcj systemu z aktorami (podmiotami procesu) oraz okrela co jest realizowane

przez system. Przypadki uycia s jednolite w caym cyklu wytwarzania systemu, tzn. ten sam model przypadku uycia jest uywany podczas wymaga, analizy i projektu, testu. Dziki uyciu graficznego projektowania poszczeglnych krokw dziaania systemu (tzw. Storyboardy/wire-framey), wynik dziaa dyscypliny Wymaga zrozumiay jest zarwno dla inynierw oprogramowania jak i dla pracownikw biznesowych klienta. 1.1.3 Analiza i projekt (A&D) Celem A&D jest pokazanie jak system bdzie zrealizowany w fazie implementacji. Wedug metodyki, ma to by system ktry: Oparty jest o ustalon szat graficzn Realizuje zadania i funkcjonalno okrelone w przypadkach uycia Spenia wszystkie wymagania zdefiniowane w definicji wymaga Jest zaprojektowany w sposb umoliwiajcy 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 czci klienckiej oraz sprecyzowaniu ktre funkcjonalnoci Magento wykorzystywane bd do realizacji zaoonych zada i funkcjonalnoci, a w szczeglnoci: Jakie dodatki (extensions) Magento zostan wykorzystane Czy jest konieczno programowania dodatkowych dodatkw W jaki sposb instancja Magento zostanie sparametryzowana Jaka dokadnie szata graficzna bdzie wykorzystana we frontowych (do klienta) czciach systemu

1.1.4 Implementacja (I) Cele implementacji s nastpujce: Instalacja systemu i jego wstpna konfiguracja Wdroenie docelowej szaty graficznej w jzyku HTML i templateach Magento Zainstalowanie dodatkw (extensions) Implementacja klas i obiektw w zakresie dodatkowych extensions (pliki rdowe, pliki binarne, pliki wykonywalne i inne) Parametryzacja systemu w zakresie obsugi procesw biznesowych klienta Przeprowadzenie testw jednostkowych Integracja rezultatw wytworzonych przez indywidualnych programistw (lub zespoy) w jeden, spjny i dziaajcy system.

1.1.5 Testy (T) Testy finalne systemu odbywaj si na serwerze pre-produkcyjnym i obejmuj cao funkcjonalnoci platformy. Cele testw s nastpujce: Weryfikacja interakcji pomidzy obiektami Weryfikacja waciwej integracji pomidzy wszystkimi systemami zintegrowanymi z platform Weryfikacja czy wszystkie wymagania zostay prawidowo zaimplementowane w systemie Weryfikacja czy wszystkie bdy systemu zostay usunite

1.1.6 Wdroenie i odbir (D&A) Celem D&A jest wytworzenie wersji dystrybuowanej produktu i dostarczenie jej do uytkownika kocowego. Wdroenie obejmuje nastpujce czynnoci: Wytworzenie wersji produkcyjnej oprogramowania, tzw. Releases Instalacja oprogramowania na ostatecznym serwerze (+ wsparcie w zakresie instalacji komponentw infrastrukturalnych: serwer web, instalacja certyfikatu SSL, parametry Drobne poprawki funkcjonalne problemw zauwaonych podczas wdroenia Dostarczenie wsparcia dla uytkownikw (dokumentacja)

Na tym etapie nastpuje odbir prac przez klienta i rozpoczta jest opcjonalna faza wsparcia.

1.2 DYSCYPLINY POMOCNICZE

Oprcz dyscyplin gwnych (inynierskich), w trakcie projektu realizowane s rwnie zaoenia dyscyplin pomocniczych opisanych poniej 1.2.1 Zarzdzanie zmianami oraz konfiguracj (C&CM) Zarzdzanie zmianami opisuje jak zarzdza artefaktami produkowanymi przez wielu ludzi pracujcych we wsplnym projekcie. Narzdzia, ktre zostan wykorzystane w projekcie, zostay opisane w dalszej czci dokumentu. 1.2.2 rodowisko (E) Celem rodowiska jest umiejscowienie wytwarzanego oprogramowania razem z oprogramowaniem rodowiska dostarczajc procesy i narzdzia niezbdne do realizacji poszczeglnych produktw.

1.3 NARZDZIA
Aby umoliwi kontrolowany przebieg projektu, nasza firma proponuje wdroenie narzdzi sucych do przechowywania i dokumentowania produktw procesu oraz kontroli komunikacji pomidzy stronami. Na potrzeby Pastwa projektu proponujemy zestaw narzdzi uywanych tradycyjnie we wszystkich projektach DC S.A.. Koszty zwizane z narzdziami (ewentualne licencje, infrastruktura projektowa) s w caoci pokryte przez DC S.A. przez cay czas trwania projektu. 1.3.1 Komunikacja: listy dyskusyjne Listy dyskusyjne (mailing lists) s narzdziem do wymiany informacji pomidzy stronami. Dla potrzeb kadego projektu, nasza firma zakada jedn lub wicej list dyskusyjnych na serwerze dostpnym przez sie Internet, dla kadego uczestnika projektu w takim zakresie jaki wynika z jego uprawnie. Filozofia realizacji projektw DC S.A. zakada maksymalne wykorzystanie tego narzdzia do wymiany wiadomoci pomidzy czonkami projektu. Rozwizuje to problem ustale rwnolegych, gdzie niezalenie w projekcie tocz si dyskusje na ten sam temat i dochodzi do sprzecznych ustale. 1.3.2 Narzdzia komunikacji natychmiastowej Wymiany e-mailowe nie zawsze nadaj si do szybkiego uzgadniania precyzyjnych punktw, bez znaczenia dla strategii projektu. Wtedy preferujemy szybk wymian dziki narzdziom komunikacji natychmiastowej. W DC S.A. uywamy narzdzia Microsoft Lync do zintegrowanego zarzdzania obecnoci/statusem/chatem/voice i wideo. Z klientami wykorzystywany jest zarwno Microsoft Lync jak i narzdzie Skype. 1.3.3 Projektowanie aplikacji: wireframes W wypadku aplikacji biznesowych, dobre zrozumienie potrzeb i procesw klienta jest podstaw do zapewnienia odpowiednich wynikw projektu. Dlatego te gwnym narzdziem do zbierania wymaga jest aplikacja do realizacji tzw. wireframes, czyli wizualnego przedstawienia ekranw docelowej aplikacji. Aplikacja pozwala na eksport zestawu wireframes do prototypu w jzyku HTML, dajc tym samym moliwo szybkiego sprawdzenia poszczeglnych funkcjonalnoci przez osoby biznesowe, bez wiedzy technicznej. 1.3.4 Zarzdzanie zmianami i konfiguracj: subversion Cao kodu rdowego aplikacji znajduje si pod kontrol systemu zarzdzania zmianami Subversion (SVN). Narzdzie moe by zainstalowane u klienta, lub na serwerze DC S.A. Pozwala to osobom z czci technicznej Pastwa zespou na biec kontrol jakoci prac naszej firmy.

1.3.5 Extranet projektu Kady projekt DC S.A. uywa zintegrowanego narzdzia Redmine jako podstawa extranetu projektu. Redmine uywany jest jako: - - - - Baza wiki do dokumentacji projektu i notatek po spotkaniach Wizualizacja rde (podczona w czasie rzeczywistym do SVN) Zarzdzanie zmianami i anomaliami za pomoc wbudowanego issue trackera Roadmapa czytelny widok stanu projektu i zada do wykonania

2 TYPOWY SPOSB REALIZACJI

Poniej przedstawiony zosta przykadowy scenariusz sposobu realizacji dziaa projektowych: Przygotowanie projektu o Zawizanie projektu, komitet pilotaowy 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 funkcjonalnoci 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 Wdroenie i odbir o Testy integracyjne o Poprawki po testach integracyjnych o Wdroenie na produkcji o Szkolenia administratorw o Wsparcie powdroeniowe

2.1 KWALIFIKACJA OBSZARW REALIZACYJNYCH

Kady projekt e-commerce zawiera wymagania ktre mog by zrealizowane rnymi rodkami; aplikacj Magento lub poza ni. W DC mapujemy obszary funkcjonalne okrelone zakresem projektowym na Sposoby Realizacji, jakimi bd wykonane w ramach projektu. Wyrniamy nastpujce klasy Sposoby Realizacji:

1. Standard Magento Oznacza, e dana funkcjonalno moe by zrealizowana standardowymi rodkami Mogento (wybranej edycji: Enterprise lub Community). Wdroenie tej funkcjonalnoci wymaga jedynie parametryzacji Systemu. 2. Extension Oznacza konieczno zakupu licencji wskazanego Magento Extension i jego wdroenia oraz parametryzacji. 3. Programowanie Templates oznacza usugi programistyczne w warstwie wizualizacji z wykorzystaniem narzdzi HTML/CSS/JS oraz szablony Magento w PHP 4. Programowanie Oglne oznacza prace programistyczne prowadzce do rozszerzenia lub modyfikacji funkcjonalnoci podstawowych systemu Magento 5. Prace dodatkowe prace wymagane do realizacji poza rodowiskiem Magento Proces mapowania zobrazowany jest w tabeli, ktrej przykadowa struktura zaprezentowana zostaa poniej.
Standard Magento Programowanie Templates Programowanie x x x Prace Dodatkowe

Referencja

Wymaganie Funkcjonalne

Uwagi

Extension

Obszar "Konfiguracja platformy technicznej" Zarzdzanie pooeniem boksw (same boksy zdefiniowane w 1.1 momencie implementacji) Zarzdzanie formularzami kontaktowymi (adresy email 1.2 docelowe i pola) - patrz te 5.2 1.3 Zarzdzanie treci (strona gwna, strony pomocnicze) 1.4 Zarzdzanie baz multimediw (zdjcia, thumbnails...) Obszar "Produkty" Interfejs backoffice do zarzdzania produktami: lista, szczegy, 2.1 edycja 2.2. Interfejs backoffice do zarzdzania produktami: wyszukiwarka 2.3 Zarzdzanie autorami i podpinanie do produktw Obszar "Uytkownicy" Modu uytkownikw - definicja i implementacja uprawnie w systemie 3.1

x x x x x

3.2 Zarzdzanie autorami i podpinanie do produktw

Aitec Advanced Permissions

Metodyka oraz sposb realizacji opisane powyej s punktem wyjcia do oceny pracochonnoci projektu, wymaganych zasobw wasnych i podwykonawczych.

3 ORGANIZACJA PROJEKTU
Poniej przedstawilimy Struktur Organizacyjn Projektu. Celem powoania jej jest zapewnienie sprawnego obiegu informacji i elementarnego podziau odpowiedzialnoci pomidzy czonkami zespou projektowego. Proponowana struktura organizacyjna jest tzw. struktur lekk, zapewniajc wszystkie potrzebne funkcje projektowe ale eliminujc zbdne elementy biurokratyczne.

3.1 STRUKTURA ORGANIZACYJNA

Na poniszym rysunku pokazano struktur organizacyjn projektu. Opis rl i odpowiedzialnoci opisany jest w dalszej czci rozdziau.
Komitet Sterujcy Sponsor Projektu Dyrektor Projektu

Kierownik Projektu Zamawiajcego

Kierownik Projektu Wykonawcy

Kontroler Jakoci

Biuro Projektu

Architekt Rozwizania

Uytkownicy Kluczowi

Konsultanci/Programici

3.2 ROLE PROJEKTOWE

Wypenieniem Struktury Organizacyjnej Projektu jest przypisanie poszczeglnym jej elementom tzw. Rl projektowych. Role powinny by zdefiniowane na pocztku projektu i jednoznacznie przypisane do konkretnych osb. Na potrzeby niniejszego Planu Projektu poszczeglne role projektowe zostay zdefiniowane nastpujco:

1. 2. 3. 4. 5. 6. 7. 8. 9.

Komitet Sterujcy Sponsor Projektu Dyrektor Projektu Kierownik Projektu Zamawiajcego Kierownik Projektu Wykonawcy Architekt Rozwizania Kontroler Jakoci Konsultanci/Programici Uytkownicy Kluczowi

Dodatkowo, w celu zapewnienia kontroli jakoci po stronie Zamawiajcego okrelono role tzw. Kontrolera Jakoci (rola odpowiedzialna za wydawanie rekomendacji dot. realizowanego produktu. 3.2.1 Komitet Sterujcy Komitet Sterujcy powoany na wniosek Zarzdu Zamawiajcego - jest organem decyzyjnym we wszystkich sprawach dotyczcych przebiegu prac projektowych. Decyzje Komitetu Sterujcego wi Strony i stanowi podstaw do dania zawarcia okrelonych w decyzji umw lub aneksw. Do zada Komitetu Sterujcego nale: 1. Wyznaczanie oglnych dyrektyw wykonywania poszczeglnych prac. 2. Podejmowanie decyzji o zatwierdzaniu wynikw prac poszczeglnych etapw projektu. 3. Akceptacja okresowych raportw dotyczcych stanu projektu przedstawianych przez Kierownika Projektu Wykonawcy i Kierownika Projektu Zamawiajcego. 4. Podejmowanie decyzji rozwizujcych pojawiajce si powane problemy i zagroenia dla powodzenia caego projektu. 5. Akceptacja proponowanych przez Kierownikw Projektu zmian w zakresie harmonogramu i budetu. 6. Delegowanie uprawnie decyzyjnych na poziom Kierownikw Projektu. Spotkania Komitetu Sterujcego projektu odbywa si bd raz na miesic. W przypadku zaistnienia wanych problemw, na wniosek Kierownika Projektu Zamawiajcego i Kierownika Projektu Wykonawcy; spotkanie moe zosta zwoane w dodatkowym terminie. Za zgod obu Stron spotkania Komitetu Sterujcego mog odbywa si zdalnie, z wykorzystaniem urzdze do telekonferencji. W skad Komitetu Sterujcego wejd: Sponsor Projektu Zamawiajcego, Kierownicy Projektw Stron i inne osoby wskazane i umocowane przez Strony Umowy. 3.2.2 Sponsor Projektu Sponsor Projektu Zamawiajcego odpowiada za:

1. Informowanie Komitetu Sterujcego o zmianach organizacyjnych Zamawiajcego, majcych wpyw na proces realizacji projektu. 2. Biece informowanie kierownictwa Zamawiajcego o stanie zaawansowania prac projektu 3. Zapewnienie dostpnoci odpowiednich funduszy, 4. Zatwierdzanie zmian w projekcie ze strony Zamawiajcego, w zakresie okrelonym przez Komitet Sterujcy. 5. Wnioskowanie o zwoywanie posiedze Komitetu Sterujcego. 6. Sponsor Projektu Zamawiajcego jest czonkiem Komitetu Sterujcego 3.2.3 Dyrektor Projektu Dyrektor Projektu Wykonawcy odpowiada za: 1. Informowanie Komitetu Sterujcego o zmianach organizacyjnych Wykonawcy majcych wpyw na proces realizacji projektu. 2. Biece informowanie kierownictwa Zamawiajcego o stanie zaawansowania prac projektu 3. Zapewnienie dostpnoci odpowiednich zasobw projektowych po stronie Wykonawcy, 4. Zatwierdzanie zmian w projekcie ze strony Zamawiajcego, w zakresie okrelonym przez Komitet Sterujcy. 5. Wnioskowanie o zwoywanie posiedze Komitetu Sterujcego. 6. Dyrektor Projektu Wykonawcy jest czonkiem Komitetu Sterujcego 3.2.4 Kierownik Projektu Zamawiajcego Kierownik Projektu Zamawiajcego odpowiada za: 1. Biec wspprac z Wykonawc poprzez Kierownika Projektu Wykonawcy - w przygotowaniu, modyfikacji i koordynacji planu projektu, 2. Informowanie Komitetu Sterujcego o zmianach organizacyjnych Zamawiajcego, majcych wpyw na proces realizacji projektu. 3. Zapewnienie dostpnoci odpowiednich funduszy, 4. Zatwierdzanie zmian w projekcie ze strony Zamawiajcego, w zakresie okrelonym przez Komitet Sterujcy. 5. Zagwarantowanie kompetentnego skadu zespou projektowego po stronie Zamawiajcego 6. Zagwarantowanie dostpnoci oddelegowanych do projektu pracownikw Zamawiajcego

7. Zagwarantowanie dostpnoci i udostpnienie odpowiednich zasobw ze strony Zamawiajcego (infrastruktury i sprztu, pomieszcze etc.), na warunkach ustalonych z Wykonawc, 8. Monitorowanie i kontrol kosztw, harmonogramu, problemw technicznych, zakresu, priorytetw projektu i podejmowanie odpowiednich dziaa 9. Informowanie Komitetu Sterujcego o postpach Wdroenia w stosunku do zatwierdzonego planu oraz wykorzystania budetu projektu

3.2.5 Kierownik Projektu Wykonawcy Kierownik Projektu Zamawiajcego odpowiada za: 1. Informowanie Komitetu Sterujcego o zmianach organizacyjnych Wykonawcy majcych wpyw na proces realizacji projektu. 2. Zapewnienie dostpnoci odpowiednich zasobw projektowych po stronie Wykonawcy, 3. Zatwierdzanie zmian w projekcie ze strony Zamawiajcego, w zakresie okrelonym przez Komitet Sterujcy. 4. Biec wspprac z Zamawiajcym poprzez Kierownika Projektu Zamawiajcego 5. Kierowanie prac zespou wdroeniowego i monitorowanie dziaa zwizanych z realizacj projektu 6. Przygotowanie, modyfikacj i koordynacj realizacji planu projektu, 7. Opracowanie harmonogramu i innych dokumentw projektowych zgodnych z przyjt metodyk projektu 8. Planowanie niezbdnych zasobw, zarzdzanie zasobami ludzkimi po stronie Wykonawcy 9. Monitorowanie i kontrol kosztw, harmonogramu, problemw technicznych, zakresu, priorytetw projektu i podejmowanie odpowiednich dziaa 10. Monitorowanie ryzyka w procesie 11. Informowanie Komitetu Sterujcego o postpach Wdroenia w stosunku do zatwierdzonego planu oraz wykorzystania budetu projektu

3.2.6 Architekt Rozwizania Architekt Rozwizania posiada kilka zakresw odpowiedzialnoci w projekcie. 1. Zadaniem Architekta Rozwizania jest systematyczna weryfikacja architektury i funkcjonalnoci powstajcego rozwizania ze wzgldu na: a. przyjte zaoenia wyjciowe architektury projektu b. biece zmiany uwarunkowa istotnych dla projektu, c. wymagane powizania wdraanego rozwizania z innymi systemami

2. Do obowizkw Architekta Rozwizania naley opiniowanie dokumentacji okrelajcej architektur i kluczowe funkcjonalnoci rozwizania 3. Architekt Rozwizania wsppracuje z Kierownikiem Projektu Zamawiajcego i Wykonawcy oraz innymi osobami zaangaowanymi w realizacj projektu w czasie i zakresie niezbdnym do realizacji swoich zada 3.2.7 Kontroler Jakoci Kontroler Jakoci odpowiada za: 1. Systematyczn weryfikacj architektury i funkcjonalnoci powstajcego rozwizania ze wzgldu na: a. przyjte zaoenia wyjciowe architektury projektu b. biece zmiany uwarunkowa istotnych dla projektu, c. wymagane powizania wdraanego rozwizania z innymi systemami d. normy jakoci wynikajce z polityki jakoci stosowanej w Projekcie i normy jakoci definiowane przez Zamawiajcego 2. Do obowizkw Kontrolera Jakoci naley opiniowanie dokumentacji okrelajcej architektur i kluczowe funkcjonalnoci rozwizania i wydawanie rekomendacji do ich akceptacji 3. Kontroler Jakoci wsppracuje z Kierownikiem Projektu Zamawiajcego i Wykonawcy (w zakresie pozyskiwania materiaw i produktw do weryfikacji) a swoje rekomendacje przedstawia Komitetowi Sterujcemu celem dokonywania akceptacji jakociowych, merytorycznych i formalnych 3.2.8 Uytkownicy Kluczowi Uytkownicy Kluczowi s pracownikami Zamawiajcego i powoywani s przez Kierownika Projektu Zamawiajcego. Do zakresu ich obowizkw naley: 1. wsppraca z konsultantami Wykonawcy w ramach zespow wdroeniowych w trakcie caego Wdroenia 2. zdobywanie dowiadczenia w uytkowaniu systemu i przekazywanie swojej wiedzy pozostaym pracownikom Zamawiajcego 3. przygotowanie danych historycznych dla potrzeb migracji do wdraanego systemu 4. testowanie opracowanych procesw, raportw i interfejsw; wspudzia w okreleniu i przygotowaniu danych i scenariuszy na potrzeby testw akceptacyjnych, przeprowadzenie testw 3.2.9 Konsultanci/Programici Konsultanci s pracownikami Wykonawcy i powoywani s przez Kierownika Projektu Wykonawcy. Do zakresu ich obowizkw naley:

1. wsppraca z Uytkownikami Kluczowymi w ramach zespow wdroeniowych w trakcie caego Wdroenia 2. realizacja prac projektowych wynikajcych z metodyki prowadzenia projektu i zakresu merytorycznego przedsiwzicia 3. migracji danych do wdraanego systemu 4. wspudzia w testowaniu opracowanych procesw, raportw i interfejsw; okrelenie i przygotowanie danych i scenariuszy na potrzeby testw akceptacyjnych, wsparcie Uytkownikw Kluczowych w przeprowadzeniu testw. 3.2.10 Biuro Projektu Biuro Projektu jest meta-zespoem ktrego rol jest skadowanie efektw pracy zespou projektowego Wykonawcy i Zamawiajcego. Peni rol opiekuna Repozytorium Dokumentacji Projektowej. Najczciej strony deleguj do Biura Projektu osoby zajmujce 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: dariusz.kakol@dc.com.pl