Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Zarządzanie Projektami
Symulator 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ść 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)
5
Trudności w implementacji
Zapis 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 minimum
Kontakt via mail i IM Wyodrębnienie na ile to możliwe zadań przewodnich dla członków zespołu
9
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
10
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
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 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
14
Dziękujemy za Uwagę Zespół nr 4 PM: Michał Szylar Artur Kosztyła
Tomasz Stępień Paweł Bicz Tomasz Manugiewicz Michał Janda
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.