1 Zarządzanie ProjektamiSymulator Automatów Komórkowych

2 Tematyka projektu Stworzyć symulator automatów komórkowych spełniający następujące założenia: Dostarczenie wielu opcji symulacji Łatwa dostępność Wymiar edukacyjny

3 Założona funkcjonalnośćDefiniowanie przez użytkownika następujących parametrów: Wybór typów siatki Wybór schematów sąsiedztwa Wybór dostępnych stanów Zdefiniowanie warunków brzegowych Zdefiniowanie warunków początkowych Liczba kroków symulacji Zdefiniowanie reguł przejścia Umożliwienie symulacji asynchronicznej i synchronicznej Możliwość podania kolejności aktualizacji pól dla automatu asynchronicznego

4 Założona funkcjonalność cdPozostałe wymagania: Wybór parametrów poprzez inteligentne menu Możliwość przechwycenia stanu symulacji Możliwość zapisu stanu symulacji Statystyka symulacji Wydzielenie tekstów do pliku Funkcjonalność dodatkowa: Automatyczne dzielenie symulacji na wiele maszyn (komputerów)

5 Trudności w implementacjiZapis stanu automatu z GUI Obsługa obliczeń rozproszonych przez środowisko wykorzystane do tworzenia GUI (SilverLight)

6 Metodologia pracy Programowanie ekstremalne Dlaczego?Metodologia bardzo elastyczna idealna dla projektu pisanego w nowych technologiach Metodologia iteracyjna Możliwość iteracyjnego dodawania nowych funkcjonalności Ciągłe modyfikowanie architektury W dowolnej chwili można było zaproponować zmiany architektury

7 Ocena metodologii Pozwoliła na elastycznośćNie wymagała stałości architektury Konieczność zastąpienia obecności klienta przez własną kontrolę projektu Czy wybralibyśmy inną metodologię? Nie bo elastyczność przy projektach studenckich jest kluczowa.

8 Organizacja pracy Ograniczenie ilości spotkań do minimumKontakt via mail i IM Wyodrębnienie na ile to możliwe zadań przewodnich dla członków zespołu

9 Ocena organizacji pracyOgraniczenie ilości spotkań do minimum Oszczędność czasu Kontakt via mail i IM Problem z kontaktem z osobami nie spędzającymi online 20h dziennie  Wyodrębnienie na ile to możliwe zadań przewodnich dla członków zespołu Ścisły podział zadań Wymuszenie odpowiedzialności za dany moduł/zadanie

10 Nieplanowane zdarzeniaZmiana wymagań klienta w czasie realizacji projektu Zmiana terminu ukończenia projektu przez klienta Brak motywacji grupy Niedostateczne tempo prac Zagrożenie związane z użyciem nowoczesnych technologii Wszystkie nieplanowane zdarzenia przewidziane w analizie ryzyka

11 Źródła problemów Brak motywacji grupy: Niedostateczne tempo prac:Przyczyna: Brak środków motywacyjnych po stronie PM Przyczyna: Zachęta do lenistwa ze strony Klienta Rozwiązanie: Przekazanie zdań AMBITNYM członkom zespołu Niedostateczne tempo prac: Przyczyna: Praca zawodowa członków grupy Przyczyna: Studia na drugim kierunku Rozwiązanie: Przekazanie zdań innym członkom zespołu Zagrożenie związane z użyciem nowoczesnych technologii Przyczyna: Brak możliwości symulacji rozproszonej przez GUI w technologii SilverLight Rozwiązanie: Utworzenie prezentacji możliwości jądra w projekcie konsolowym

12 Deathmarch Problem z wyznaczeniem kluczowej funkcjonalności.Przyczyna: Brak podania przez klienta priorytetów funkcjonalności. Rozwiązanie: Wydłużenie „godzin pracy” z 8 na 16 godzin na dobę 

13 Stopień realizacji projektuCore projektu całkowicie gotowy. Skupienie się na realizacji najważniejszego Potrzeba przetestowania Core projektu. Skrócenie czasu projektu Konieczność napisania nowego GUI jeśli projekt ma być wykorzystywany jako aplikacja rozproszona. Ponieważ aplikacja z założenia miała mieć charakter edukacyjny raczej nie będzie wymagała dużych możliwości obliczeniowych

14 Dziękujemy za Uwagę Zespół nr 4 PM: Michał Szylar Artur KosztyłaTomasz Stępień Paweł Bicz Tomasz Manugiewicz Michał Janda