Zarządzanie Projektami Symulator Automatów Komórkowych

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

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

Założona funkcjonalność cd Pozostał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)

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

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

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.

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

Ocena organizacji pracy Ograniczenie 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

Nieplanowane zdarzenia Zmiana 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

Ź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

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ę 

Stopień realizacji projektu Core 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

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