docMetia Order Management
download 
Reklamacja Transkrypt
Metia Order Management
Dokumentacja projektowa Piotr Błędowski Mateusz Ginstrowski Bogdan Jezierski Maciej Pawlak Projekt elektronicznego systemu składania zamówień Metia Order Management Dokumentacja zarządzania projektem Wersja 1.0 Dokumentacja zarządzania realizacją projektu Metia OM Strona 1 z 33 Dokumentacja projektowa Spis treści 1 Wstęp................................................................................................................................................4 2 Zakres Projektu ................................................................................................................................5 2.1 Cele projektu ............................................................................................................................5 2.1.1 Aspekt biznesowy ............................................................................................................5 2.1.2 Aspekt użytkowy...............................................................................................................5 2.1.3 Aspekt techniczny.............................................................................................................6 2.2 Wymagania funkcjonalne..........................................................................................................7 2.3 Wymagania niefunkcjonalne.....................................................................................................7 3 Organizacja projektu.........................................................................................................................9 3.1 Komitet sterujący......................................................................................................................9 3.2 Kierownik projektu ................................................................................................................11 3.3 Zespoły projektowe ................................................................................................................12 3.3.1 Lider zespołu ..................................................................................................................12 3.3.2 Członek zespołu .............................................................................................................12 3.3.3 Zespół analityków...........................................................................................................13 3.3.4 Zespół projektantów.......................................................................................................14 3.3.5 Zespół developerów ......................................................................................................15 3.3.6 Zespół testerów..............................................................................................................16 4 Procedury sterowania i kontroli projektu.......................................................................................17 4.1 Procedury komunikacji...........................................................................................................17 4.1.1 Komunikacja wewnętrzna...............................................................................................17 4.1.2 Komunikacja zewnętrzna................................................................................................18 4.2 Procedury zapewnienia jakości...............................................................................................19 4.3 Procedury kontroli postępów prac i wykorzystania budżetu..................................................20 4.4 Procedury kontroli zmian........................................................................................................22 4.4.1 Zmiany wewnętrzne........................................................................................................22 4.4.2 Zmiany zewnętrzne.........................................................................................................23 4.5 Procedury rozwiązywania problemów....................................................................................24 5 Plan projektu...................................................................................................................................25 5.1 Etapy projektu.........................................................................................................................25 5.1.1 Zbieranie wymagań.........................................................................................................25 5.1.2 Analiza biznesowa...........................................................................................................26 5.1.3 Analiza techniczna..........................................................................................................26 5.1.4 Projektowanie..................................................................................................................26 5.1.5 Implementacja.................................................................................................................26 5.1.6 Testowanie i integracja....................................................................................................27 5.1.7 Wdrożenie.......................................................................................................................27 5.1.8 Utrzymanie systemu i wsparcie......................................................................................27 5.2 Harmonogram prac.................................................................................................................28 5.2.1 Haronogram czasu trwania poszczególnych etapów.......................................................28 5.2.2 Harmonogram dostępności pracowników ......................................................................28 6 Analiza ryzyk..................................................................................................................................29 6.1 Spis znanych ryzyk.................................................................................................................29 6.2 Macierz ryzyk.........................................................................................................................30 6.3 Zdefiniowanie pradopodobnych zagrożeń..............................................................................30 Dokumentacja zarządzania realizacją projektu Metia OM Strona 2 z 33 Dokumentacja projektowa 7 Słownik użytych pojęć...................................................................................................................31 Autorzy • • • • Piotr Błędowski Mateusz Ginstrowski Bogdan Jezierski Maciej Pawlak Data modyfikcji Opis modyfikacji 29.04.2011 Utworzenie dokumentu 30.04.2011 Opis zespołów projektowych i ryzyk 02.05.2011 Dodanie analizy ryzyka 09.05.2011 Poprawki: działania prewencyjne dla prawdopodobnych zagrożeń Dokumentacja zarządzania realizacją projektu Metia OM Strona 3 z 33 Dokumentacja projektowa 1 Wstęp Celem dokumentu jest przedstawienie zarządzania realizacją projektu systemu Order Management dla firmy telekomunikacyjnej Metia sp. z o. o. Firma świadczy usługi telekomunikacyjne, w postaci dostępu do internetu szerokopasmowego, telewizji cyfrowej, telefonii naziemnej oraz mobilnej. Wraz z rozrostem firmy problemem stało się zarządzanie zamówieniami składanymi przez klientów indywidualnych na nowe usługi, dezaktywację już posiadanych lub ich modyfikację, szczególnie ze względu na dość rozbudowaną sieć systemów towarzyszących. Z powodów opisanych powyżej podjęta została decyzja o realizacji systemu typu Order Management dla firmy Metia przez firmę Elka Soft. System zrealizowany zostanie zgodnie z wymaganiami biznesowymi i będzie obsługiwać wszystkie opisane wyżej sytuacje. System będzie zarówno wygodny dla klientów indywidualnych, jak i dla pracowników, udostępniając specjalistyczne narzędzia podglądu stanu zamówień oraz umożliwiając ekipie technicznej łatwe diagnozowanie możliwych problemów. Udostępni także odpowiedni interfejs dla pracowników pracujących na stanowiskach help-desku. System umożliwiać będzie wszystkie wymagania biznesowe związane z prawem telekomunikacyjnym, takim jak przewidziany w prawie okres karencji i możliwość płynnego odstąpienia od umowy przez klientów w jego okresie. Order Management łączyć będzie wszystkie systemy związane poprzez platformę integracyjną opartą na SOAP. Dokumentacja zarządzania realizacją projektu Metia OM Strona 4 z 33 Dokumentacja projektowa 2 Zakres Projektu 2.1 Cele projektu 2.1.1 Aspekt biznesowy Dzięki wdrożeniu systemu OM dla firmy Metia możliwe będzie osiągnięcie poniższych korzyści biznesowych: • Diametralne zwiększenie ilości realizowanych zleceń, co przyczyni się do wzrostu efektywności i wydajności, a tym samym umożliwi pozyskanie większej ilości klientów • Powiększenie przewagi technologicznej nad konkurencją, dzięki zastosowaniu najnowszych technologii przy realizacji nowego systemu • Łatwiejsze tworzenie statystyk i analiz, dzięki czemu możliwe będzie lepsze zarządzanie firmą • Lepsza kontrola nad realizacją zamówień, dzięki czemu w przypadku wystąpienia błędów możliwa jest natychmiastowa reakcja i kontakt z klientem 2.1.2 Aspekt użytkowy System Order Management dla firmy Metia będzie umożliwiał: • Odpowiednie katalogowanie wszystkich dostępnych produktów biznesowych wraz z dostępnymi dla nich opcjami • Możliwość modyfikacji posiadanych produktów jak np. Zmianę szybkości posiadanego łącza szerokopasmowego. System dzięki odpowiedniej bazie produktów będzie w stanie dokładnie określić jakie modyfikacje są dozwolone, a jakie nie. • Dokładne sprawdzenie zamówienia pod kątem ich poprawności, dzięki czemu niemożliwe będzie obsłużenie zamówienia niepoprawnego z punktu widzenia Dokumentacja zarządzania realizacją projektu Metia OM Strona 5 z 33 Dokumentacja projektowa biznesowego • Generowanie statystyk popytu na konkretne usługi • Odpowiednie panele obsługi administracyjnej, podzielone wedle obowiązków obsługujących je pracowników – inne dla obsługi technicznej, pracowników front office, pomocy telefonicznej itp 2.1.3 Aspekt techniczny System oparty będzie na modelu trójwarstwowym, czyli: • Bazie danych, w której przechowywane będą wszystkie dane związane z przetwarzanym zamówieniem, konteksty oraz stany pośrednie realizowanego zamówienia. • Serwerach zajmujących się obsługą zamówienia, podzielonych na dedykowane serwery dla dekompozycji zamówienia, startowania odpowiednich procesów związanych z realizacją cząstkowych aspektów zamówienia, komunikacji z systemami zewnętrznymi oraz notyfikacjami idącymi do klienta. • Konsolach klienckich, służących do śledzenia realizacji zamówienia i ingerowania w jego realizację przez pracowników w przypadku wystąpienia czynników zewnętrznych Ze względu na złożoność systemu, będzie on działać na wielu niezależnych maszynach, dedykowanych dla konkretnych zadań. Przyjmuje się możliwość realizacji 4 000 zamówień na godzinę, przez co ważne będą aspekty wydajnościowe realizowanego systemu Dokumentacja zarządzania realizacją projektu Metia OM Strona 6 z 33 Dokumentacja projektowa 2.2 Wymagania funkcjonalne • Możliwość składania zamówień poprzez stronę internetową firmy albo w placówkach przy udziale pracownika. Przez zamówienie rozumie się kupno nowych usług, sprzętów, ich modyfikację, rezygnację z posiadanych usług. • Należy zagwarantować możliwość anulowania zlecenia w czasie jego realizacji, zarówno w przypadku jego kompletowania, jak i w późniejszym okresie karencji • Monitorowanie postępu zamówienia w trakcie jego realizacji • Przechowywanie historii zrealizowanych zamówień • Integracja z systemami zewnętrznymi poprzez platformę integracyjną oraz komunikacja z nimi w ramach realizacji zamówienia • Sprawdzanie poprawności zamówień w oparciu o reguły biznesowe i odrzucanie zamówień niepoprawnych 2.3 Wymagania niefunkcjonalne • System powinien umożliwiać obsługę 4 000 zamówień na godzinę • Awaria któregoś z serwerów nie powinna skutkować paraliżem systemu, a jedynie chwilowym spadkiem wydajności • Każde z zamówień powinno móc zostać przerwane w dowolnym momencie realizacji i automatycznie przywrócone do dalszego procesowania w dowolnym momencie • System powinien zapewnić bezpieczeństwo przechowywanych danych i umożliwiać dostęp do zastrzeżonych informacji tylko powołanym do tego osobom Dokumentacja zarządzania realizacją projektu Metia OM Strona 7 z 33 Dokumentacja projektowa • System powinien działać w oparciu o synchronizowane bazy danych, tak aby uszkodzenie jednej z nich nie spowodowało utracenia krytycznych danych ani zaprzestania działania systemu • System Order Management powinien komunikować się innymi systemami poprzez platformę integracyjną opartą o SOAP Dokumentacja zarządzania realizacją projektu Metia OM Strona 8 z 33 Dokumentacja projektowa 3 Organizacja projektu 3.1 Komitet sterujący Do obowiązków komitetu sterującego należy czuwanie nad prawidłowym kierunkiem rozwoju systemu, podejmowanie strategicznych decyzji w odniesieniu do realizowanego projektu oraz poszczególnych etapów jego realizacji. Skład komitetu sterującego będzie następujący: Stanowisko Pracownik Przewodniczą Ezekiel Abbacki, cy komitetu prezes firmy "Elka sterującego: Soft" Obowiązki • Odpowiedzialny za realizację celów strategicznych realizowanego projektu w odniesieniu do strategii firmy Elka Soft • Odpowiedzialny za zapobieganie sytuacjom kryzysowym związanych z realizowanym projektem • Podejmuje kluczowe decyzje i zatwierdza działania podczas realizacji projektu • Odpowiedzialny za rozwiązywanie sytuacji kryzysowych Sponsor projektu Żyraf Babacki, prezes spółki „Metia” • Osoba wspierająca projekt i znające cele realizacji projektu • Odpowiedzialny za przydzielanie środków finansowych na realizację projektu Kierownik projektu Ambroży Kowalski, Delivery Manager • Wymagania i obowiązki zostały opisane w rozdziale 3.2 Dokumentacja zarządzania realizacją projektu Metia OM Strona 9 z 33 Dokumentacja projektowa „Elka Soft” Główny użytkownik systemu Konsultanci techniczni Mścisław Koniecpolski, analityk biznesowy spółki „Metia” • Udziela odpowiednich analiz i porad pod kątek użytkowania systemu Powoływanie wedle zapotrzebowania • Wykonywanie niezależnego audytu i ekspertyz projektu realizowanego systemu • Przekazuje przewodniczącemu komitetu sterującego wnioski od przyszłych użytkowników • Wyjaśnianie kwestii spornych i użyteczności odpowiednich technologii Dokumentacja zarządzania realizacją projektu Metia OM Strona 10 z 33 Dokumentacja projektowa 3.2 Kierownik projektu Wymagania względem Kierownika • Zdolności w podejmowaniu decyzji i analizie bieżących sytuacji Obowiązki Kierownika Projektu • Śledzenie postępów prac realizowanego projektu • Analiza i zarządzanie ryzykiem • Doświadczenie w zarządzaniu kadrą pracowniczą • Przygotowanie planu projektu • Bardzo dobra znajomość technologii wykorzystanych przy realizacji projektu • Kierowanie i koordynacja prac poszczególnych zespołów projektowych • Duże doświadczenie przy realizacji i kierowaniu realizacją projektów informatycznych • Wykrywanie i przeciwdziałanie sytuacjom kryzysowym • Posiadanie umiejętności w zarządzaniu zasobami ludzkimi i szacowaniu kosztów • Znajomość metodyk zarządzania ryzykiem • Identyfikacja oraz rozwiązywanie sytuacji konfliktowych w zespołach • Przygotowanie i realizacja harmonogramu realizacji projektu • Pośredniczenie między kierownikami projektu oraz komitetem sterującym • Dobór kompetentnych członków zespołu projektowanego i przydzielanie im zadań • Określanie zasad komunikacji, raportowania prac i ich dokumentowania Dokumentacja zarządzania realizacją projektu Metia OM Strona 11 z 33 Dokumentacja projektowa 3.3 Zespoły projektowe Każdy z zespołów projektowych powinien składać się z lidera oraz co najmniej dwóch członków zespołu projektowego 3.3.1 Lider zespołu Wymagania względem Lidera Obowiązki Lidera Zespołowego • Sumienność i zdolności w kierowaniu zespołem • Raportowanie postępu prac kierownikowi projektu • Doświadczenie w wykonywaniu zadań realizowanych przez zespół • Rozwiązywanie problemów na poziomie swojego zespołu projektowego • Zarządzanie realizacją przydzielonej zespołowi pracy nad częścią projektu 3.3.2 Członek zespołu Wymagania względem członka zespołu Obowiązki członka zespołu • Doświadczenie w realizowaniu zadań, które członek zespołu projektowego będzie wykonywał podczas trwania projektu • Realizacja powierzonych zadań • Znajomość technik i metodyk opisanych w dalszej części dokumentu • Sygnalizowanie sytuacji kryzysowych oraz problemów przy realizacji otrzymanych zadań • Raportowanie postępu prac liderowi zespołu Dokumentacja zarządzania realizacją projektu Metia OM Strona 12 z 33 Dokumentacja projektowa 3.3.3 Zespół analityków Zespół analityków zajmuje się wykonywaniem analizy biznesowej oraz technicznej, czego efektem są dokumenty wysokiego poziomu. Dodatkowo, każdy z analityków świadczy wsparcie projektantom i testerom podczas wykonywania przez nich zadań, określonych przez ich obowiązki Wymagane kwalifikacje • Znajomość technik i metodyk tworzenia systemów informatycznych • Doświadczenie w zadaniach analitycznych • Umiejętność analitycznego myślenia i rozwiązywania problemów • Umiejętność tworzenia dokumentów wysokiego poziomu realizacji systemów informatycznych ( HLD ) Obowiązki • Rozpoznanie i zdefiniowanie procesów które ulegać będą informatyzacji • Stworzenie kompletnej i spójnej specyfikacji wymagań • Współpraca z zespołem projektantów, programistów i testerów w obrębie wyjaśniania założeń wstępnych • Udzielanie analiz zespołom projektowym w czasie realizacji systemu oraz jego testowania • Tworzenie dokumentacji biznesowej i technicznej wysokiego poziomu • Stworzenie planu testów systemu Skład zespołu analitycznego: a) Ścibór Dadacki: lider zespołu analitycznego, analityk biznesowy b) Sławosz Eacki: analityk biznesowy c) Dobromir Eacki: analityk techniczny d) Dobiesław Fafacki: analityk techniczny Dokumentacja zarządzania realizacją projektu Metia OM Strona 13 z 33 Dokumentacja projektowa 3.3.4 Zespół projektantów Zespół projektantów zajmuje się tworzeniem niskopoziomwej koncepcji rozwiązania, czego efektem jest dokumentacja techniczna niskiego poziomu, zawierająca już dokładny opis modelów baz danych, klas itp. Projektanci świadczą wsparcie podczas etapu implementacji dla developerów. Wymagane kwalifikacje Obowiązki • Znajomość technik i metodyk projektowania systemów informatycznych • Stworzenie kompletnego i szczegółowego projektu systemu informatycznego • Doświadczenie w projektowaniu systemów informatycznych • Wybór odpowiednich metod i technologii realizacji systemu • Stworzenie modelu bazy danych • Umiejętność przenoszenia projektu wysokiego poziomi realizacji systemu informatycznego na projekt niskiego poziomu ( LLD ) • Udzielanie analiz zespołom projektowym w czasie realizacji systemu oraz jego testowania • Tworzenie dokumentacji technicznej niskiego poziomu Skład zespołu projektantów: a) Brodzisz Gagacki: lider zespołu projektantów b) Bożydar Hahacki: projektant c) Radomysł Ijacki: projektant Dokumentacja zarządzania realizacją projektu Metia OM Strona 14 z 33 Dokumentacja projektowa 3.3.5 Zespół developerów Zespół developerów składa się z programistów, którzy na podstawie dokumentacji technicznej niskiego poziomu, przygotowanej przez projektantów, implementują poszczególne moduły systemu. Developerzy mają dostęp również do dokumentów wysokiego poziomu, aby w razie nieprecyzyjnego określenia pewnych kwestii w dokumencie niskiego poziomu, móc szukać tam potrzebnych informacji. Wymagane kwalifikacje • Znajomość języka programowania C# oraz relacyjnych baz danych, języka PL/SQL Obowiązki • Implementacja kodu oraz bazy danych wedle stworzonego projektu systemu • Wstępne przetestowanie stworzonego kodu • Znajomość UML • Wsparcie zespołu testowego oraz wprowadzanie poprawek do kodu wskutek wykrytych błędów Skład zespołu developerskiego: a) Pączesław Jajcki: lider zespołu developerskiego b) Krzesław Kakacki: developer baz danych c) Drogomił Lalcki: developer C# d) Monesław Mamacki: developer Dokumentacja zarządzania realizacją projektu Metia OM Strona 15 z 33 Dokumentacja projektowa 3.3.6 Zespół testerów Zespół testerów składa się z osób projektujących testy jednostkowe dla systemu, implementujących je oraz tworzących raporty z wynikami testów. Zespół testerów komunikuje się z zespołem analitycznym i projektowym, w celu wykrywania nieprawidłowości. Wymagane kwalifikacje Obowiązki • Znajomość metodyk testowych • Opracowanie scenariuszy testsowych dla testów jednostkowych • Znajomość języka C# • Implementacja testów jednostkowych oraz testów systemowych opracowanych przez analityków • Szeroka wiedza z zakresu kontroli jakości oprogramowania • Znajomość metod testowych • Weryfikacja wymagań funkcjonalnych • Raportowanie błędów zespołowi analitycznemu • Raportowanie wyników przeprowadzonych testów Skład zespołu developerskiego: a) Wyszomir Nanacki: lider zespołu testowego b) Zbysław Oacki: tester c) Ziemowid Papacki: tester Dokumentacja zarządzania realizacją projektu Metia OM Strona 16 z 33 Dokumentacja projektowa 4 Procedury sterowania i kontroli projektu 4.1 Procedury komunikacji 4.1.1 Komunikacja wewnętrzna W czasie trwania projektu przewidziane są cotygodniowe spotkania w każdy poniedziałek wewnątrz zespołów w celach raportowania postępów prac, określaniu ryzyk i sytuacji kryzysowych oraz nakreślenia prac w nadchodzącym tygodniu. Spotkania przewidziane są na godzinę 10.00, jednak godzina ta może zostać przesunięta na wniosek lidera zespołu. Indywidualny rozdział zadań oraz raportowanie dziennego postępu prac przez członka zespołu odbywać się będzie indywidualnie na płaszczyźnie lider zespołu – członek zespołu. Cotygodniowe spotkania liderów zespołów z kierownikiem odbywać się będą w każdy poniedziałek o godzinie 12.00, gdzie raportowane będą postępy prac poszczególnych zespołów zbiorczo i nakreślane ryzyka. Ustalana będzie strategia na następny tydzień w odniesieniu do wszystkich zespołów na podstawie ich wzajemnych korelacji. Spotkania te mają charakter formalny i należy po każdym spotkaniu utworzyć notatkę ze spotkania z opisem i harmonogramem realizacji postanowień ze spotkania. Każdy członek zespołu projektowego posiada firmowego mejla tj. np. [email protected]. Mejle stanowią podstawowe źródło przepływu informacji wewnątrz projektu i deklaracje składane tym kanałem komunikacyjnym należy traktować obligatoryjnie. Każdy członek zespołu zapisany jest też na skrzynkę grupową swojego zespołu np. [email protected] Kod źródłowy oraz dokumentacja projektowa znajdują się na firmowym repozytorium pod adresem https://svn.elkateam.pl/metia/ Dokumentacja zarządzania realizacją projektu Metia OM Strona 17 z 33 Dokumentacja projektowa 4.1.2 Komunikacja zewnętrzna Pod koniec każdego miesiąca kierownik projektu powinien przedłożyć raport o stanie prac komitetowi sterującemu oraz osobom reprezentującym interesy klienta. Podczas formalnego spotkania należy: • Przedstawić stan realizacji zakładanych prac w odniesieniu do objętego harmonogramu • Przedstawić stan wykorzystania budżetu oraz zasobów Prawo reprezentowania firmy Elka Soft i komunikacji z klientem posiada jedynie Kierownik Projektu i wyznaczonego przez niego osoby. Poza tymi osobami żaden z pracowników i członków zespołów projektowych nie może reprezentować firmy Elka Soft w stosunku do klienta ani przyjmować deklaracji obligujących do podjęcia działań. Dokumentacja zarządzania realizacją projektu Metia OM Strona 18 z 33 Dokumentacja projektowa 4.2 Procedury zapewnienia jakości Komitet Sterujący powołuje pełnomocnika do spraw zapewnienia jakości. Do jego zadań należy: • Ocenianie raportów i pracy Kierownika Projektu pod kątem jakościowym • Kontrolę systemu pod kątem spełnienia wymagań funkcjonalnych i niefunkcjonalnych. • Kompletność i jakość dokumentacji analitycznej i technicznej • Zgodność postępów prac pod kątem przyjętego harmonogramu • Zgodność wykorzystania zasobów i budżetu względem przyjętego kosztorysu i oceny pracochłonności 4.2.1 Procedura zapewnienia jakości kodu i dokumentacji Procedura zapewnienia jakości oparta jest o mierzalne współczynniki jakości. Należą do nich: Współczynnik Opis Czytelność Zrozumiałość kodu przez innych programistów Modyfikowalność Stopień możliwości modyfikowania kodu, jego elastyczność Poprawność Współczynnik określający stopień spełnienia wymogów formalnych do danej częsci systemu, realizowanej przez niego funkcjonalności Stopień udokumentowania Określenie w jakim stopniu napisany kod jest udokumentowany i jak czytelna i dokładna jest dokumentacja Uniwersalność Stopień uniwersalności kodu, przez co rozumie się możliwość jego wykorzystania w innych częściach systemu i projektach Testowalność Współczynnik określający jak łatwo kod jest testowalny Wydajność W jakim stopniu kod spełnia wymogi wydajnościowe i w jakim stopniu jest on zoptymalizowany 4.2.2 Procedura zapewnienia jakości systemu poprzez testy Procedura zapewnienia jakości systemu jest realizowana za pomocą testów jednostkowych, systemowych oraz wydajnościowych. Raport z przeprowadzenia tych testów dostarcza Kierownik Projektu, Pełnomocnikowi ds. Zapewnienia jakości. Na ich podstawie Pełnomocnik ocenia stopień zaawansowania konstrukcji systemu Dokumentacja zarządzania realizacją projektu Metia OM Strona 19 z 33 Dokumentacja projektowa względem harmonogramu i spełnienie przez system wymogów zawartych w umowie z klientem. Przeprowadzane będą poniższe testy: Rodzaj testu Opis Testy jednostkowe Testy stworzone na podstawie scenariuszy testów jednostkowych tworzonych przez zespół testowy, mające na celu jak najszersze pokrycie kodu Testy systemowe Testy tworzone na podstawie scenariuszy testowych przygotowanych przez projektantów, mające na celu wychwycić potencjalne błędy i anomalie w działaniu i komunikacji poszczególnych modułów systemu Testy integracyjne Tworzone na podstawie scenariuszy przygotowanych przez analityków biznesowych, mające na celu symulację komunikacji przygotowywanego systemu OM z innymi systemami zewnętrznymi Testy wydajnościowe Testy tworzone przez analityków technicznych, mające za zadanie sprawdzić limity wydajnościowe systemu i spełnienie wymagań klienta 4.2.3 Dokument z przeprowadzenia kontroli jakości Działania pełnomocnika do spraw jakości dokumentowane są w planie jakości. Plan powstaje na podstawie harmonogramu projektu, następnie jest on uzupełniany wraz z postępem prac nad projektem. Plan ma charakter formalny. Wymaganym produktem przeprowadzenia kontroli jakości jest dokument zawierający poniższe informacje: Wymagane pole Opis Data Data przeprowadzenia kontroli jakości Sposób pomiaru Opis formalnego sposóbu przeprowadzenia pomiaru Wynik Opis wyniku przeprowadzonej kontroli jakości oraz porównanie otrzymanych wyników z zakładanymi Zalecenia Lista zaleceń i propozycji służacych poprawie stanu jakościowego na oczekiwany Po zakończeniu każdego etapu projektu weryfikowana jest jego jakość wykonania. W przypadku wykrycia jakichkolwiek niezgodności, informowany jest o Dokumentacja zarządzania realizacją projektu Metia OM Strona 20 z 33 Dokumentacja projektowa tym kierownik projektu, który musi w takim wypadku przygotować plan naprawczy. Jeżeli naruszone zostanie termin zakończenia prac, budżet lub spełnienie wymagań klienta, Kierownik Projektu zobowiązany jest do poinformowania o tym fakcie Komitetu Sterującego. Wykrycie nieprawidłowości powinno wiązać się z poniższymi następstwami: • Analiza nieścisłości przez analityka / projektanta w zależności od poziomu niezgodności, czyli tego czy jest to błąd implementacyjny, systemowy czy też integracyjny • Wprowadzenie zmian w dokumentacji technicznej niskiego i w razie konieczności, wysokiego poziomu • Implementacja zmian w kodzie przez zespół developerski • Wykonanie niezbędnych testów przez zespół testowy • Kontrola mająca na celu sprawdzenie czy wszystkie zalecenia zostały zrealizowane, a uchybienia zlikwidowane. Informacja o efekcie kontroli powinna znaleźć się w dokumencie kontroli opisanym powyżej. • W razie stwierdzenia występowania dalej uchybień, Pełnomocnik powinien nakazać powtórzenie całej procedury i w razie konieczności wyeskalować problem do Kierownika Projektu i Komitetu Sterującego Planowane są trzy etapy kontroli jakości w zależności od poziomu: • Audyt wewnętrzny na poziomie zespołu, mający na celu szybkie wykrycie błędów i ich poprawę z ominięciem formalnej procedury. • Audyt wewnętrzny na poziomie projektu, gdzie Pełnomocnik przeprowadza kontrolę jakości z zachowaniem powyższej procedury • Audyt zewnętrzny, zlecony przez klienta, z zachowaniem powyższej procedury, realizowany w fazie odbioru systemu Dokumentacja zarządzania realizacją projektu Metia OM Strona 21 z 33 Dokumentacja projektowa 4.3 Procedury kontroli postępów prac i wykorzystania budżetu Odpowiedzialność za kontrolę wykorzystania budżetu i postępu prac odpowiedzialny jest Kierownik Projektu, który kontroluje zgodność postępu prac z przyjętym harmonogramem pracy i stopień wykorzystania budżetu. Komitetowi Sterującemu przedkładany jest specjalny raport w razie wykrycia nieprawidłowości, który powinien zawierać: Wymagane pole Opis Skutki i przyczyny Opis skutków wystąpienia nieprawidłowości i przyczyn, które doprowadziły do ich pojawienia się Działania naprawcze Proponowane działania mające na celu naprawę sytacji Lista niezgodności Pełna lista niezgodności jaka wystąpiła Do mierzenia postępu prac i wykorzystania budżetu wykorzysta będzie metoda Earned Value: Całkowity koszt projektu (BAC) powinien zostać podzielony na koszty poszczególnych etapów pracy ujętych w harmonogramie, co umożliwi wyznaczenie wartości prac ( w skrócie BCWS ), które zgodnie z harmonogramem miały być wykonane do danego dnia. Następnie obliczana jest wartość prac ( w skrócie BCWP) faktycznie ukończonych do danego dnia oraz rzeczywisty koszt wykonania zadań ( w skrócie ACWP). Na podstawie obliczonych współczynników obliczamy: • Odchylenie od planowanego harmonogramu ( SV = BCWP – BCWS), przy czym ujemna wartość SV oznacza przekroczenie budżetu • Odchylenie od planowanego kosztu (CV = BCWP – ACWP), przy czym ujemna wartość CV oznacza opóźnienie w stosunku do planu • Wskaźnik wydajności realizacji harmonogramu ( SPI = BCWP / BCWS) • Wskaźnik wydajności realizacji budżetu ( CPI = BCWP / ACWP ) Dokumentacja zarządzania realizacją projektu Metia OM Strona 22 z 33 Dokumentacja projektowa • Wskaźnik wydajności budżetu dla pozostałych do wykonania prac w celu zmieszczenia się w budżecie (TCPI = (BAC – BCWP) / (BAC – ACWP)) Następnie należy oszacować koszty końcowe: EAC = ACWP + ( BAC – BCWP ) / CPI ) Uwzględniając aktualny poziom wykonania oraz kosztów, a także prognoże budżetu, wykreśla się nowy harmonogram w formie linii przewidywanego kosztu kumulowanego ( FCST ) W przypadku stwierdzenia niezgodności kierownik projektu może podjąć działania, po uzgodnieniu ich z Komitetem Sterującym mające na celu poprawę harmonogramu. Są to: • Ustanowienie nadgodzin • Dodanie nowych osób do zespołów • Przesunięcie harmonogramu • Ograniczenie realizowanego zakresu Dokumentacja zarządzania realizacją projektu Metia OM Strona 23 z 33 Dokumentacja projektowa 4.4 Procedury kontroli zmian Wszystkie zmiany powinny zostać udokumentowane. Dokument opisujący zmiany powinien zawierać: Wymagane pole Opis Data Data złożenia propozycji zmiany Dane autora Dane autora propozycji zmiany, tj imię, nazwisko, firma, adres kontantowy oraz zajmowane stanowisko Cel zmiany Opis i uzasadnienie wprowadzenia zmiany Decyzja Ostateczna decyzja o wprowadzeniu zmiany, pole uzupełniane przez Kierownika Projektu Ewidencję zmian prowadzi Kierownik Projektu, do której dostęp mają liderzy zespołów oraz Komitet Sterujący. Zmiany o podobnym charakterze powinny zostać wprowadzone grupowo, tak aby koszty i opóźnienia przez nie spowodowane były jak najmniejsze. O fakcie wprowadzenia zmiany powinny zostać poinformowane wszystkie zainteresowane osoby. 4.4.1 Zmiany wewnętrzne Zmiany wewnętrzne dotyczą zmian w wymaganiach, technologii, uwarunkowaniach prawnych lub gospodarczych i powinny być zgłoszone kierownikowi projektu pisemnie wraz z uzasadnieniem konieczności wprowadzenia zmiany. Kierownik dokonuje analizy propozycji zmiany w wyniku której powstaje dokument zawierający: • Ocenę potrzeby lub korzyści wprowadzenia zmiany • Koszty i konsekwencje związane z wprowadzeniem zmiany • Sposób wprowadzenia zmiany Po wykonaniu analizy, jeżeli wprowadzenie zmiany nie stanowi zagrożenia dla kluczowych aspektów projektu, kierownik podejmuje decyzję o jej wprowadzeniu. Analiza zostaje przedstawiona Komitetowi Sterującemu, który podejmuje decyzję Dokumentacja zarządzania realizacją projektu Metia OM Strona 24 z 33 Dokumentacja projektowa o jej zatwierdzeniu i na tej podstawie powstaje dokument zawierający: • Projekt sposobu wprowadzenia zmiany • Sposób w jaki zmiana zostanie wykonana, a fragmenty realizowanego systemu przerobione • Sposób przetestowania zmiany i jej skutków w innych częściach systemu 4.4.2 Zmiany zewnętrzne Procedura kontroli zmian zewnętrznych jest uzgodniona z Klientem. Zmiany zewnętrzne powinny być zgłoszone nie poźniej niż na trzy miesiące przed zakończeniem projektu. Kierownik projektu zleca rozpatrzenie i zbadanie żądania zmiany, która analizowana jest według następujących kryteriów: • Koszt i konieczność wprowadzenia zmiany • Wpływ zmiany na harmonogram prac • Wpływ na działanie innych części systemu Decyzję odnośnie zmiany podejmuje Komitet Sterujący na podstawie dokonanej analizy. Możliwymi akcjami zarządzonymi przez Komitet Sterujący są: • Decyzja o wykonaniu zmiany • Odrzucenie propozycji zmiany lub odłożenie jej wykonania • Zlecenie bardziej szczegółowej analizy Dokumentacja zarządzania realizacją projektu Metia OM Strona 25 z 33 Dokumentacja projektowa 4.5 Procedury rozwiązywania problemów Każde wykrycie problemu powinno zostać zgłoszone do lidera odpowiedniego zespołu, który przedłoży problem Kierownikowi Projektu. Zgłoszenia mają charakter formalny. Kierownik projektu jest osobą odpowiedzialną za rozwiązywanie problemów. W jego kompetencji leży kwalifikacja problemów na: • Zagrażające realizacji projektu, które zgłaszane są na posiedzeniu Komitetu Sterującego przez Kierownika Projektu. Komitet Sterujący może na podstawie przedłożonej analizy problemu podjąć decyzję o zatwierdzeniu lub odrzuceniu rozwiązania proponowanego przez Kierownika Projektu lub zlecić analizę niezależnemu ekspertowi • Łatwo rozwiązywalne, których rozwiązanie pozostaje w kwestii Kierownika Projektu, jednak powinien on poinformować o zaistniałym problemie Komitet Sterujący na następnym, regularnym spotkaniu Procedura rozwiązywania problemów została podzielona na poniższe etapy: Nazwa etapu Opis Analiza problemu W tej fazie następuje analiza zaistniałego problemu. Zespół analityków bada przyczyny powstania problemu oraz ustala możliwe najefektywniejsze rozwiązanie na wysokim stopniu abstrakcji systemu. Analizowane są również koszta wprowadzenia rozwiązania oraz szacowana jest jego pracochłonność i czas trwania Projektowanie rozwiązania Faza projektowania wprowadzenia rozwiązania do systemu w aktualnym stanie wykonania. Zespół projektantów nanosi zmiany w dokumentacji technicznej Implementacja rozwiązania Zespół developerów dostaje poprawione wersje dokumentacji technicznej i jeżeli już napisany kod wymaga poprawek, zostaje zmieniona jego implementacja Audyt rozwiązania Powołany do audytu zespół sprawdza jakość wprowadzonego rozwiązania oraz bada jego realny wpływ na system Dokumentacja zarządzania realizacją projektu Metia OM Strona 26 z 33 Dokumentacja projektowa 5 Plan projektu 5.1 Etapy projektu Projekt składał się będzie w sumie z 7 etapów, mających na celu zapewnić jak najwyższą jakość dostarczanego systemu. Poniżej zestawienie wszystkich etapów które muszą być zrealizowane, aby udało się stworzyć system wraz z zakładanym czasem trwania i liczbą potrzebnych pracowników Nazwa etapu Czas trwania Liczba pracowników Zbieranie wymagań 3 tygodnie • 2 analityków biznesowych • 1 konsultant zewnętrzny Analiza biznesowa 4 tygodnie • 2 analityków biznesowych Analiza techniczna 3 tygodnie • 2 analityków technicznych • 1 analityk biznesowy ( wsparcie ) Projektowanie 6 tygodni • 3 projektantów • 1 analityk techniczny ( wsparcie) Implementacja 6 tygodni • 4 developerów • 1 projektant ( wsparcie ) • 1 analityk techniczny ( wsparcie ) Testowanie 6 tygodni • 4 testerów • 1 analityk techniczny ( wsparcie ) Wdrożenie 2 tygodnie • 2 developerów • 1 analityk biznesowy ( szkolenie ) • 1 analityk techniczny ( wsparcie ) 5.1.1 Zbieranie wymagań Celem pierwszego etapu jest wyspecyfikowaniu wymagań funkcjonalnych i niefunkcjonalnych. W czasie prac istotnym czynnikiem będzie współpraca z klientem. Istotne jest w tym etapie zebranie pełnego i wyczerpującego zbioru wymagań. W tym celu należy określić zasady współpracy z klientem, tak, aby udało się zebrać kompletny zestaw wymagań dotyczących projektu Przewidywany czas trwania: 3 tygodnie Planowana data rozpoczęcia: 01.06.2011 Dokumentacja zarządzania realizacją projektu Metia OM Strona 27 z 33 Dokumentacja projektowa Planowana data zakończenia: 22.06.2011 5.1.2 Analiza biznesowa W czasie trwania tego etapu, zespół analityków biznesowych analizować będzie zebrane wymagania od klienta i na ich podstawie tworzona będzie dokumentacja biznesowa wysokiego poziomu. W razie wystapienia niejasności, zespół analityków będzie konsultować się z klientem. Przewidywany czas trwania: 4 tygodnie Planowana data rozpoczęcia: 22.06.2011 Planowana data zakończenia: 20.07.2011 5.1.3 Analiza techniczna W czasie trwania tego etapu, zespół analityków technicznych, tworzyć będzie dokument techniczny wysokiego poziomu na podstawie przygotowanej dokumentacji biznesowej. Start etapu zacznie się jeszcze w czasie trwania analizy biznesowej. Przewidywany czas trwania: 3 tygodnie Planowana data rozpoczęcia: 13.07.2011 Planowana data zakończenia: 3.08.2011 5.1.4 Projektowanie W czasie trwania tego etapu, zespół projektowantów przygotowuje projekt systemu i tworzy dokumentację techniczną niskiego poziomu. Etap rozpoczenie się na dwa tygodnie przed zakończeniem analizy technicznej. Przewidywany czas trwania: 6 tygodni Planowana data rozpoczęcia: 3.08.2011 Planowana data zakończenia: 14.09.2011 5.1.5 Implementacja Etap budowy systemu wedle przygotowanwego projektu. Etap wymaga współpracy wszystkich zespołów Dokumentacja zarządzania realizacją projektu Metia OM Strona 28 z 33 Dokumentacja projektowa Przewidywany czas trwania: 6 tygodni Planowana data rozpoczęcia: 7.09.2011 Planowana data zakończenia: 19.10.2011 5.1.6 Testowanie i integracja Zespół do spraw testów będzie dokładnie testować przygotowany system. Na tym etapie ważna jest współpraca z innymi zespołami w ramach poprawny znalezionych błędów. Efektem etapu testowania będzie raport z testów i przeprowadzenie testów akceptacyjnych u Klienta. Przewidywany czas trwania: 6 tygodni Planowana data rozpoczęcia: 14.09.2011 Planowana data zakończenia: 26.10.2011 5.1.7 Wdrożenie Po etapie testów akceptacyjnych, gotowy system zostanie wdrożony i zainstalowany u Klienta. Przeprowadzone zostaną szkolenia pracowników. Przewidywany czas trwania: 2 tygodni Planowana data rozpoczęcia: 26.10.2011 Planowana data zakończenia: 9.11.2011 5.1.8 Utrzymanie systemu i wsparcie Ostatnim etapem jest konserwacja systemu i wsparcie techniczne w okresie 4 lat od oddania gotowego systemu. Przewidywany czas trwania: 4 lata Planowana data rozpoczęcia: 01.01.2012 Planowana data zakończenia: 01.01.2016 Dokumentacja zarządzania realizacją projektu Metia OM Strona 29 z 33 Dokumentacja projektowa 5.2 Harmonogram prac 5.2.1 Haronogram czasu trwania poszczególnych etapów 5.2.2 Harmonogram dostępności pracowników Pracownik 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Analityk biznesowy Analityk techniczny 2 1 1 2 Projektant Developer Tester Dokumentacja zarządzania realizacją projektu Metia OM 1 3 1 4 2 4 Strona 30 z 33 Dokumentacja projektowa 6 Analiza ryzyk 6.1 Spis znanych ryzyk ID Zagrożenie Możliwe skutki Wpływ Prawd. Zaist. Ogromny Niskie Duży Średnie Duży Duże • Dostarczenie wadliwego produktu • Opóźnienia • Kary finansowe Ogromny Średnie 5 Słabe zabezpieczenie • Możliwość strary cennych danych danych • Wyciek poufnych danych Ogromny Średnie 1 Wadliwe zarządzanie • Zwiększenie kosztu projektu • Niebezpieczeństwo niezrealizowania zaplanowanych dziłań w terminie 2 Opóźnienie z dostawą sprzętu • Opóźnienie dostawy finałowego produktu 3 Niedostępność osób • Możliwe zagrożenie terminu dostawy z przyczyn losowych finałowego produktu • Opóźnienia w realizacji etapów • Straty finansowe 4 Błędy w oprogramowaniu 6 Awarie sprzętu • Strary finansowe • Opóźnienie oddania systemu Duży Niskie 7 Konflikty między członkami zespołu • Wydłużenie czasu realizacji projektu • Obniżenie jakości zarządzania Średni Średnie 8 Przestoje w płatnościach • Utratra płynności finansowej Ogromny Minimalne 6.2 Macierz ryzyk Prawdop. Duże 3 Średnie 2,7 4,5 Niskie 6 1 Minimalne 8 Minimalne Niski Średni Duży Ogromny Wpływ Dokumentacja zarządzania realizacją projektu Metia OM Strona 31 z 33 Dokumentacja projektowa 6.3 Zdefiniowanie pradopodobnych zagrożeń • 2: Opóźnienia z dostawą sprzętu Działania prewencyjne: • Współpraca ze sprawdzonymi i kompetentnymi dostawcami • Ustalenie dostawy sprzętu z wyprzedzeniem • 3: Niedostępność osób z przyczyn losowych Działania prewencyjne: • Określenie listy osób możliwych do wydelegowania na czas określony z innych projektów • Założenie na wstępie pewnego współczynnika niedostepności • Ustalenie budżetu na nadgodziny • 4: Wystąpienie błędów w oprogramowaniu Działania prewencyjne: • • Wydłużenie etapu testowania produktu Wydzielenie budżetu na dodatkowy audyt kodu i kodu testów • 5: Słabe zabezpieczenia ochrony danych Działania prewencyjne: • • Tworzenie co godzinę kopii przyrostowej kodu i raz dziennie pełnej kopii Zdefiniowanie listy osób uprawnionych do dostępu do określonych danych • 7: Konflikty między członkami zespołu Działania prewencyjne: • • Jawne zdefiniowanie ról i obowiązków Indywidualny dobór zespołów Dokumentacja zarządzania realizacją projektu Metia OM Strona 32 z 33 Dokumentacja projektowa 7 Słownik użytych pojęć Termin Opis Klient Firma zamawiająca system "Metia Sp. Z o. o" Pracownik Osoba zatrudniona w firmie "Elka soft" biorąca udział w projekcie System Twrzony system informatyczny typu Order Management przez firmę "Elka soft" na zlecenie firmy "Metia Sp. Z o. o." Dokumentacja zarządzania realizacją projektu Metia OM Strona 33 z 33
