Na ziolono zapisane są doprecyzowania, które zostały dopisane po publikacji treści projektu.

Projekt zespołowy polega na przygotowaniu aplikacji działającej w trybie graficznym, w bibliotece PyGame lub PyQt (obie zademonstrowane w materiale po 9 wykładzie), z wykorzystaniem programowania obiektowego. Do jego realizacji mogą przystąpić grupy 3–5 osobowe, dozwolone jest dowolne łączenie grup.

Dokładny temat projektu jest dowolny, o ile mieści się w wytycznych opisanych w treści zadania. Zapoznaj się z całością dokumentu, zanim przystąpisz do realizacji projektu.

Projekt oceniany jest w trzech fazach, łącznie na 50 punktów.

Na tym etapie należy:

1. wybrać skład drużyny i w przypadku grup mieszanych, wybrać godzinę i prowadzącego, któremu odda się zadania* (1p),
2. założyć repozytorium git (na serwerze Github, Gitlab lub podobnym) oraz dodać na nim wszystkich członków drużyny i prowadzącego (1p),
3. wybrać temat projektu (1p),
4. napisać około pół strony A4 na temat tego, jak może wyglądać gotowy produkt, dlaczego wybraliście taki projekt a nie inny, jak planujecie rozplanować pracę, z jakich bibliotek planujecie skorzystać (2p).

* prowadzący mogą zmienić preferowany wybór terminu i prowadzącego, w celu zrównoważenia liczności grup i umożliwienia sprawiedliwej rywalizacji o tytuł najlepszego projektu zajęć.

Aplikacja może być dowolna i zachęcam, by było to coś, co ciekawi większość członków drużyny lub się wam jakoś przyda. Choć przykłady użycia bibliotek PyGame i PyQt pokazane w ramach wykładu są grami, nie trzeba się ograniczać. Biblioteka PyGame może posłużyć na przykład jako narzędzie do wizualizacji fraktali, a PyQt jako interfejs do katalogowania książek, które ma się ochotę przeczytać. Przed wybraniem tematu projektu warto pomyśleć, czy jesteście w stanie go zrealizować. Poszukajcie bibliotek pomagających zrobić to, co planujecie. Przykładowo — chcecie ściągać z Internetu kursy walut? Pewnie przyda się jakaś biblioteka przetwarzania stron Internetowych i wyciągania z nich konkretnych informacji. Poszukajcie takiej w Google (na przykład https://www.google.com/search?q=python+read+webpage) i zróbcie jakiś tutorial, żeby się przekonać, czy jest to proste, czy poza możliwościami. Chcecie w swojej aplikacji odtworzyć plik mp3? https://www.google.com/search?q=python+play+mp3. Nie sposób opisać wszystkich bibliotek, które będą potrzebne do realizacji waszych pomysłów. W pracy nad projektem znalezienie biblioteki, która się przyda do zaprogramowania rozwiązania zadania, to istotna część jego realizacji.

Tematy projektów nie powinny się powtarzać, decyduje kolejność zgłoszeń. Termin nadsyłania zgłoszeń to 16 maja 2024. Aby ułatwić poszukiwanie członków zespołu oraz to, żeby tematy się nie powtarzały, przez USOS udostępniony został dokument na pomysły. Uwaga, jest to wyłączenie dokument dla was, umieszczenie tam pomysłu nie jest równoznaczne ze zgłoszeniem tematu! Zgłoszenie tematu odbywa się przez maila, poprzez wysłanie wszystkich wymaganych informacji (składu drużyny, dostępu do repozytorium, tematu oraz opisu projektu) do obu prowadzących grupy laboratoryjne.

Uwaga: projekt nie musi być duży pod kątem zakresu funkcjonalności — zachęcam, aby wręcz nie był. Dobrze działające narzędzie, robiące niewielką rzecz, ale robiące ją dobrze, może być bardzo przydatne. Przykładowo jeśli trenujecie łucznictwo i brakuje wam aplikacji, w której moglibyście kliknięciem zaznaczać, w jakie miejsce tarczy trafiliście podczas konkretnego treningu, po czym zobaczyć w niej jak statystyki trafień zmieniają się w czasie, to dobrze zrobiona aplikacja tego typu to zakres w zupełności wystarczający na projekt. Jeśli jakiś projekt będzie miał zbyt mały lub zbyt duży zakres, będzie możliwość skorygowania tego na kolejnym etapie.

Do 6 czerwca powinniście przygotować prototyp oraz projekt aplikacji.

Prototyp to aplikacja, która nie ma pełnej funkcjonalności, ale w jakiś sposób testuje wykonalność zadania. Przykładowo, jeśli w ramach projektu tworzycie elektroniczną kartę postaci do grania w 5 edycję Dungeons & Dragons, być może wyświetla wam się kawałek formularza, gdzie można wpisać informacje, ale nie ma jeszcze sprawdzania poprawności wpisanych danych, nie ma wszystkich elementów formularza oraz dane nie są zapisywane na dysk, więc po wyłączaniu aplikacji znikają. Pomimo tych oczywistych niedoskonałości, jest to dobry prototyp, pokazujący, że mając więcej czasu dokończycie aplikację, postępując analogicznie jak dotychczas, czyli dodając kolejne funkcjonalności do programu.

Działający prototyp oceniany jest na 8 punktów.

Razem z prototypem należy oddać dokumentację. Tutaj oczekujemy:

1. instrukcji uruchomienia prototypu, listy wymaganych bibliotek oraz instrukcji użytkowania (2p),
2. planowanego diagramu klas UML gotowej aplikacji (3p),
3. zaktualizowanego planu działania na kolejne tygodnie pracy (1p),
4. zaktualizowanego planu funkcjonalności gotowej aplikacji (1p).

Dwa ostatnie punkty stanowią aktualizację dokumentu przesłanego podczas zgłoszenia tematu. Pamiętajcie, że praktycznie nie istnieje na świecie projekt, w którym jego plan, na przykład zakres lub kolejność realizacji etapów, się nie zmienia. Pokażcie, że zauważacie zmiany. Jeśli wasz pierwotny projekt był zbyt ambitny lub zbyt asekuracyjny, teraz jest idealny moment na korektę.

Uwaga, ponieważ teraz wszystko trzymacie w gicie, po prostu wysyłacie maila z informacją, że wszystko jest w repozytorium i jest gotowe do sprawdzenia w stanie na konkretną datę. Ponieważ git przechowuje całą historię, nie musicie czekać, aż prowadzący sprawdzi to co jest w repozytorium, możecie kontynuować pracę mając pewność, że sprawdzimy stan plików na tę datę, kiedy się zgłosicie do sprawdzenia. Dla pewności, możecie dodać tag do właściwego commita.

Podczas ostatnich zajęć, prezentujecie gotowe aplikacje. Jeśli aplikacja zadziała i robi to, co miała robić według opisu z 2 fazy, otrzymujecie 10 punktów.

Po zajęciach zostanie również rozdystrybuowana anonimowa ankieta oceny pracy w grupie, w której gdzie każdy członek zespołu będzie mógł ocenić siebie oraz wszystkich swoich współpracowników pod kątem tego, jak dobrze pracowało się z daną osobą w grupie. Za pracę w grupie można otrzymać 5 punktów.

Pozostałe 15 punktów rozdzielone będzie po zajęciach na podstawie repozytorium w następujący sposób:

1. styl kodu w formie zgodnej z PEP-8 (1p),
2. obecność komentarzy i styl komentarzy w formie zgodnej z PEP-257 (2p),
3. wykorzystanie adnotacji typów (2p),
4. testy jednostkowe (5p),
5. jakość kodu (5p).

Jakość kodu będzie oceniana pod kątem złych zapachów kodu, przy czym najpoważniejszymi zarzutami będą:

1. nic nie mówiące nazwy metod lub zmiennych oraz magiczne stałe, utrudniające zrozumienie kodu,
2. nadmiernie powielony kod, który łatwo wyciągnąć do osobnej funkcji lub metody,
3. zbędny kod zajmujący czas, ale nie dający żadnych efektów, na przykład

suma = 0
for x in lista:
    suma += x
return lista  # suma jest policzona, ale nigdy nie jest używana

zamiast

return lista

albo

if x>1:  # wyrażenie x>1 ma tylko dwie możliwe wartości, True i False
    return True
else:
    return False

zamiast

return x>1

Po zaprezentowaniu projektów wszyscy uczestnicy zajęć otrzymają drugą ankietę, w której będą mogli zagłosować na najlepszy projekt. W każdej grupie laboratoryjnej głosami publiczności zostanie wyłoniona jedna drużyna, która przedstawiła najlepszy (lub przedstawiła najlepiej) swój projekt. Każdy członek tych drużyn otrzyma możliwość wybrania jednej kartkówki z wykładu, z której będzie mógł odzyskać punkty.