Zespołowy Projekt Informatyczny Capgemini Beer Game

Transkrypt

1 Beer Game Andrzej Kałuża Capgemini Wrocław Cel projektu Zasady gry Uczestnicy Wymagania oraz reguły gry: Karty wymagao Wymagania obligatoryjne: Wymagania opcjonalne: Wymagania niefunkcjonalne Przykładowa architektura... 9 Zespołowy Projekt Informatyczny 1

2 1. Cel projektu Celem projektu jest implementacja internetowej gry Beer Game. Gra ta pozwala zamodelowad znane w logistyce zarządzanie łaocuchem dostaw (supply chain management), a więc zintegrowany przepływ towarów (zamówieo oraz wysyłek) pomiędzy poszczególnymi uczestnikami handlu, planowanie zakupów oraz sprzedaży i kontrolowanie towarów, informacji, przepływu kapitału począwszy od klienta detalicznego aż do producenta surowców potrzebnych do produkcji. Gra umożliwia interakcję pomiędzy uczestnikami oraz pozwala na ciągłą analizę i kontrolę stanów magazynowych, a także zależności pomiędzy klientem a odbiorcą. 2. Zasady gry 2.1 Uczestnicy W klasycznym modelu w grze bierze udział 8 uczestników: 1) Odbiorca koocowy 2) Sprzedawca detaliczny 3) Spedytor 4) Hurtownik 5) Producent koocowy 6) Prefabrykacja 7) Dostawca 8) Producent surowca Natomiast każdy z uczestników jest powiązany z: 1) Jednym uczestnikiem a) klient koocowy (ze sprzedawcą detalicznym) b) producent surowca (z odbiorcą) 2) Bądź dwoma uczestnikami a) Pozostali uczestnicy (powiązani ze swoim dostawcą oraz odbiorcą) Wszyscy uczestnicy poza producentem surowca zamawiają od swojego dostawcy produkty, natomiast wszyscy uczestnicy poza odbiorcą koocowym dostarczają produkty do odbiorcy. Zespołowy Projekt Informatyczny 2

3 2.2 Wymagania oraz reguły gry: 1. Czas dostawy produktu od momentu zamówienia pomiędzy poszczególnymi uczestnikami jest ściśle określony. 2. Każdy cykl gry ma określony przebieg, a podczas pojedynczej fazy gry (jednego dnia w łaocuchu dostaw) obowiązuje następująca kolejnośd: Zespołowy Projekt Informatyczny 3

4 1. Odbierz zamówiony produkt i przekaż go do magazynu 2. Odbierz zamówienie klienta (dopiero w tym momencie producent dowiaduje się o wielkości zamówienia). 3. Przekaż dalej wysłane wcześniej towary z punktu 1 do punktu Sprawdź stan magazynu i przekaż do klienta zamówione przez niego towary. Istnieją 3 warianty: a) Liczba wysłanych towarów zgadza się z odebranym zamówieniem klienta b) Liczba wysłanych towarów jest mniejsza niż wielkośd zamówienia klienta z powodu niedoboru w magazynie c) Liczba towarów jest większa od aktualnego zamówienia, ponieważ producent dostarcza tym razem również towary, których nie dostarczył w poprzednich wysyłkach z powodu niedoboru w magazynie. 5. Wyślij produkty, kładąc je w buforze Przekaż dalej wysłane cykl wcześniej zamówienie z punktu 1 do punktu Przeanalizuj (zaznacz na wykresie) aktualny stan magazynu i wielkośd zamówienia. 8. Zamów produkty, uzupełniając punkt 1 wielkością zamówienia. Aktualny stan magazynu może byd prezentowany przy pomocy następującego formularza: Zespołowy Projekt Informatyczny 4

5 3. Pozostałe reguły businessowe gry: 1. Przechowywanie produktu (każdej skrzynki piwa) w magazynie kosztuje X złotych za jeden dzieo (X jest wartością konfigurowalną). 2. Każdy niedobór w magazynie (czyli niedostarczona na czas skrzynka piwa) kosztuje gracza Y złotych (Y = 2*X) za jeden dzieo. 3. Każdy uczestnik może jednorazowo zamówid oraz wysład maksymalnie Z skrzynek piwa (wartośd konfigurowalna). 4. Wartości X, Y oraz Z są globalne dla całej gry i obowiązują wszystkich graczy. 5. Rolę producenta surowców odgrywa serwer. 6. Administrator określa wartośd T zamówieo oraz wysyłek z poprzednich dni tak, aby móc zacząd grę w trybie ciągłym. 3. Karty wymagań 3.1 Wymagania podstawowe: 1. Logowanie administratora do systemu poprzez podanie adresu i hasła (hasło dla pierwszego administratora: piwosz, - dowolny) 2. Hasła w bazie danych są haszowane przy pomocy funkcji SHA-1 3. Edycja profilu administratora (zmiana adresu oraz hasła) 4. Dodawanie nowego administratora poprzez podanie adresu , na który przychodzi z linkiem. Po kliknięciu użytkownik podaje hasło, po czym zakładany jest profil administratora. 5. Reset hasła poprzez podanie adresu , na który przychodzi link, który kieruje na stronę, gdzie administrator podaje nowe hasło. 6. Administrator po zalogowaniu może rozpocząd nową grę, podając wartości X, Y, Z, T (domyślne wartości wynoszą X: 0.5, Y: 1, Z: 15, T:5), wpisując adresy graczy oraz przyporządkowując do nich rolę w grze (jedna rola jest przypisana wyłącznie do jednego gracza) oraz podając hasło do gry. Minimalna liczba ról a więc i graczy wynosi 6 (wtedy rolę klienta koocowego odgrywa serwer, który losowo podaje wartośd zamówieo), maksymalna 7 (wraz z klientem koocowym). Użytkownicy otrzymują wtedy wiadomości z linkami prowadzącymi bezpośrednio do gry. Użytkownik może również zalogowad się do gry, wchodząc na stronę logowania i podając swój adres oraz hasło do gry. Użytkownik z danym adresem może zalogowad się tylko raz do aktualnie prowadzonej rozgrywki. Ponowna próba zalogowania przez użytkownika, który aktualnie bierze udział w grze, kooczy się niepowodzeniem. 7. Administrator po zalogowaniu może również ustawid grę, podając adresy graczy, hasło do gry oraz czas rozpoczęcia gry. 8. Gra rozpoczyna się automatycznie, kiedy wszyscy użytkownicy zalogują się do serwisu. 9. Każdy administrator po zalogowaniu widzi stan aktualnej rozgrywki. 10. Jednocześnie może byd prowadzona tylko jedna rozgrywka. 11. Tylko administrator (który zainicjował grę) ma prawo skooczyd grę, po czym każdy u uczestników wraz z administratorem może oglądad swoje wyniki, wykres stanów magazynu oraz wyniki Zespołowy Projekt Informatyczny 5

6 przeciwników. Zwycięzcą gry jest osoba, którą przechowywanie towarów w magazynie kosztowało najmniejszą kwotę. 12. Każdy administrator po zalogowaniu widzi historię wszystkich zakooczonych gier (użytkowników, wyniki ich gry, kompletne formularze z wykresami stanów magazynowych niezależnie od tego, czy inicjował grę, czy też nie). 13. System wysyła powiadomienie do gracza, który nie wykonał swojego kroku (nie zamówił odpowiedniej liczby skrzynek piwa) w ciągu 1 minuty od rozpoczęcia danej fazy gry. Komunikat z przypomnieniem pojawia się na ekranie gracza. 14. Wysyłanie skrzynek piwa do klienta odbywa się automatycznie (system sprawdza stan magazynu i wysyła tyle skrzynek, aby zrealizowad aktualne zamówienie, bądź też aby pokryd niedobory wysyłkowe z poprzednich dni ). Gracz otrzymuje komunikat o dokonanej wysyłce. 15. Tylko gracz może decydowad o wielkości aktualnego zamówienia. Kiedy wszyscy gracze określą wartośd zamówienia, kooczy się jeden cykl (faza) gry i rozpoczyna kolejny. 16. Każdy użytkownik widzi swój formularz gry (stan magazynu, dokonanych zamówieo, nieotrzymanych towarów od dostawcy i aktualne zamówienie od swojego klienta). 17. Gracz po zalogowaniu podaje nazwę miasta, gdzie znajduje się jego siedziba. Miasto wyszukiwane jest na mapie (przy wykorzystaniu Google Maps). 18. Gracz widzi na mapie przepływ towaru do swojego klienta, od swojego dostawcy oraz zamówienia do swojego dostawcy i aktualne zamówienie od klienta (z uwzględnieniem czasu oczekiwania na dostarczenie zamówienia bądź wysyłki). 19. Wszyscy gracze oraz administrator mają dostęp do aktualnych parametrów gry. 20. Administrator, który rozpoczął grę ma dostęp do aktualnego panelu każdego z graczy w trybie read Only/view. Administrator może zatem obserwowad formularz zamówieo, aktualny wykres każdego z graczy. 21. Po zakooczeniu gry każdy z uczestników otrzymuje wiadomośd z wynikiem swojej gry oraz z załącznikami zawierającymi formularz zamówieo i wykres stanu magazynu (w postaci pliku Excel bądź PDF). Zespołowy Projekt Informatyczny 6

7 3.2 Wymagania opcjonalne: 1. Wykrywanie sytuacji, kiedy użytkownik stracił połączenie z grą, aby umożliwid mu ponowne zalogowanie i dostęp do gry. 2. Umożliwienie administratorowi przypisania większej liczby użytkowników do danej roli. Wtedy, jeżeli dany gracz może korzystad z usług 2 dostawców, to od każdego z nich może zamówid Z/2 skrzynek piwa i każdy z tych dostawców może jednorazowo dostarczyd tyle samo skrzynek piwa do tego odbiorcy. Ponadto każdy dostawca może zamówid od swojego odbiorcy taką samą liczbę skrzynek piwa, ile wynosi maksymalna wielkośd zamówieo wysłanych od jego klientów. Ponadto administrator przypisuje wtedy danego dostawcę konkretnemu odbiorcy (komponuje graf zależności pomiędzy uczestnikami gry). Dany gracz ma wtedy możliwośd zamawiania produktów od kilku dostawców, co również prezentowane jest odpowiednio na mapach. Zastrzeżenie: w grze wciąż występuję tylko jeden klient koocowy, jeden sprzedawca detaliczny i jeden producent surowca. 3. Rozszerzenie punktu (2) polegające na modyfikacji czasu zamówienia i czasu dostawy towarów pomiędzy poszczególnymi graczami oraz nadania wartości sprzedawanym i kupowanym towarom przez administratora podczas konfiguracji gry (tylko w sytuacji, kiedy dany gracz ma możliwośd zakupu towaru od kilku dostawców). W tym przypadku wprowadzony zostaje kolejny parametr P = 100 * X i jest on ceną każdej jednostki surowca (cena sprzedaży od producenta surowca). Domyślna wartośd wynosi P=50 (ponieważ domyślna wartośd przechowywania towaru w magazynie jest równa 0.5) Obowiązuje zasada, że im krótszy czas realizacji zamówienia (czas od momentu zamówienia do otrzymania towaru), tym wyższa cena towaru. Wartośd towaru wyliczona jest wg wzoru: Cena(K, D) = P(D) * (1 + O * ( N(K) / M(K, D) ) ), gdzie Cena(K, D) wartośd transakcji (cena towaru) pomiędzy klientem K a dostawcą D O marża określana przez administratora jako parametr gry, domyślna wartośd O:0.1 P(D) maksymalna cena, po której dostawca kupuje produkt od swojego sprzedawcy N(K) najkrótszy czas dostawy między klientem K a jego wszystkimi dostawcami M(K, D) czas dostawy między klientem K a dostawcą D Zespołowy Projekt Informatyczny 7

8 Zastrzeżenie wszyscy dostawcy powiązani z producentem surowca kupują towar w tej samej cenie, a czas realizacji dostawy pomiędzy stronami jest identyczny dla wszystkich tych graczy. Każdy gracz otrzymuje na początku gry kwotę K = 3 * Z * P złotych, gdzie: Z maksymalna liczba zamówieo (określana przez administratora) P wartośd pojedynczego surowca (=100 * X) (gdzie X określana przez administratora cena za jeden dzieo przechowania towaru w magazynie). Klient koocowy ma nieograniczoną kwotę, którą może przeznaczyd na zakup dowolnej liczby skrzynek piwa Zwycięzcą gry jest w tym przypadku osoba, która zgromadziła na swoim koncie największą kwotę pieniędzy. Jeżeli dowolny z graczy ma ujemny bilans konta, gra wciąż jest kontynuowana. Koszty przechowywania i niedoboru towaru w magazynie wciąż są uwzględniane podczas wyliczania stanu konta gracza. 4. Rozszerzenie punktu (3). System automatycznie wylicza optymalne wartości zamówieo dla każdego z graczy i po zakooczeniu gry podaje, jaką maksymalną kwotę dany gracz mógłby zgromadzid, gdyby za każdym razem stosował optymalną ścieżkę wyboru. 5. Umożliwienie przeprowadzania kilku gier równocześnie. 6. Administrator widzi na mapie cały łaocuch zamówieo i dostaw wszystkich użytkowników, przy czym ma prawo do filtrowania widoku dla poszczególnych graczy. 4. Wymagania niefunkcjonalne 1. Repozytorium kodu (svn) 2. Ciągła integracja (jenkins) 3. Logowanie błędów (log4j) Zespołowy Projekt Informatyczny 8

9 5. Przykładowa architektura Zespołowy Projekt Informatyczny 9