Szanowni Państwo, przed zadaniem pytania uprzejmie proszę o zapoznanie się z zawartością niniejszej strony, jak również z informacjami o możliwościach konsultacji.

Nie używam Teams, w razie potrzeby proszę kontaktować się mailem.

Sprawy organizacyjne

Tematy nie są takie trudne jak może się na początku wydawać.

Mam świadomość tego, że niektóre tematy projektów da się zinterpretować tak, że można by nad nimi pracować wiele lat. Chodzi więc o takie zaplanowanie prac i uproszczenie zagadnienia, aby dało się je wykonać w zaplanowanym czasie.

Mogę przyjąć zespoły z własnym tematem, o ile proponowany temat mnie zainteresuje (algorytmy ewolucyjne, uczenie się maszyn, sztuczna inteligencja).

Obowiązujące terminy, kryteria oceny, ważne rady znaleźć można na stronie prowadzącego przedmiot. Termin "do dnia X" oznacza możliwość przesłania do końca dnia X (do północy).

Dokumentację wstępną, szkielet i projekt w wersji ostatecznej proszę przysłać e-mailem: rafal.biedrzycki [at] pw.edu.pl.

Po zatwierdzeniu wyboru tematu zadania należy zapisać u siebie treść zadania (system ułatwiający zapisy może mieć awarię).

Jeżeli członek zespołu nie wnosi wkładu do projektu, to jak najwcześniej należy rozwiązać zespół poprzez wysłanie do partnera e-maila (z kopią do mnie) z informacją, że wobec braku współpracy zespół ulega rozwiązaniu. Po rozwiązaniu zespołu należy zmniejszyć wymagania funkcjonalnie (należy przysłać propozycję zmian zakresu projektu do zatwierdzenia). Zwykle żeby projekt nadal miał sens nie da się okroić go aż o połowę. Proszę zatem przy każdym ocenianym etapie przypominać, że projekt realizowany jest jednoosobowo.

Wymagania

Programy powinny być napisane obiektowo w C++. Zarówno klasy, jak i moduły powinny być dobrze przetestowane (testy automatyczne, testy modułowe z boost, scenariusze testowe, itd.). Obsługa błędów za pomocą wyjątków. Wszytko powinno dobrze działać pod kontrolą systemu operacyjnego Ubuntu 22.04 LTS. Na tym przedmiocie należy również stosować się do porad, które opracowałem na potrzeby dydaktyki związanej z podstawami programowania obiektowego w C++.

Proces kompilacji i konsolidacji projektu musi być zautomatyzowany. W tym celu należy zastosować powszechnie dostępne narzędzia, np. make, cmake, qmake, Scons.

W zasobach dostępnych publicznie w Internecie proszę nie wpisywać mojego nazwiska. Często spotykam repozytoria gdzie napisano coś w stylu: "Projekt z przedmiotu ZPR na wydziale ... Prowadzący: (i tu moje dane). Najlepiej używać niepublicznego repozytorium, a jeśli się nie da to proszę nie wpisywać nazwy przedmiotu i dokładnej treści zadania.

Jesteśmy w Polsce - nie widzę potrzeby używania języka angielskiego w interfejsie graficznym aplikacji.

Można używać bibliotek zewnętrznych ale należy to wyraźnie zaznaczyć w kodzie i opisać w dokumentacji.

Nie można użyć biblioteki realizującej prawie całe zadanie - chcę sprawdzić Państwa kod.

W nagłówku każdego pliku z kodem powinna znaleźć się informacja kto jest autorem tego kodu.

Proszę nie przysyłać mi binariów, czyli bibliotek, plików wykonywalnych, wyników kompilacji.

Sposób oceny

Sposób oceny poszczególnych składników projektu został opisany na stronie prowadzącego przedmiot. Znajdują się dam również ważne daty, które obowiązują.

Za każdy rozpoczęty tydzień opóźnienia maksymalna ocena możliwa do uzyskania jest zmniejszana o 20%.

Po upływie ostatecznego terminu oddania projekty nie będą oceniane.

Programy powinny być przenośne, ale najważniejsze jest aby program działał na platformie klienta. Tu ja pełnię rolę klienta. Używam Ubuntu 22.04 LTS (a jak się już pojawi 24.04 LTS), zatem proszę używać narzędzi i bibliotek dostępnych w pakietach wskazanej dystrybucji. Najlepiej jest, jeśli co najmniej jeden członek zespołu pracuje na platformie docelowej.

W przypadku projektów, do których zrealizowania użyto wielu języków programowania proszę pamiętać, że odpowiednio dużo, odpowiednio skomplikowanego kodu musi być w C++.

Lepsza jest działająca aplikacja o ograniczonej funkcjonalności niż niestabilna aplikacja o rozdmuchanej funkcjonalności.

Niezastosowanie się do wymagań opisanych na tej stronie i jej podstronach powoduje obniżenie oceny. Przykładowo: użycie postinkrementacji zamiast preinkrementacji generalnie nie stanowi dużego problemu, tu jednak spowoduje obniżenie oceny, ponieważ na podstronie z poradami napisałem „preferujemy preinkrementację”.

Dokumentacja wstępna

Specyfikację wstępną należy wysłać pocztą elektroniczną. Nazwa pliku powinna składać się z nazwisk autorów.

W dobie automatycznego sprawdzania pisowni pojawienie się literówek w dokumentacjach jest niedopuszczalne.

Dokumentacja wstępna powinna zawierać temat zadania w wersji oryginalnej, po czym powinien pojawić się rozwinięty opis tematu, pokazujący, że wiedzą Państwo co mają zrobić. Należy również wstępnie określić jak zamierzają Państwo to zrobić. Plany te nie mogą być zbyt ogólne, np. "zamierzamy wykorzystać SI". W przykładzie tym akceptowalne jest podanie przynajmniej nazwy algorytmu, np. "... w tym celu zamierzamy wykorzystać uczenie się ze wzmocnieniem (RL)". Podanie nieco bardziej skonkretyzowanego opisu, np. "W RL stanami będą... a akcjami ..." może być opłacalne, ponieważ znając szczegóły czasem jestem w stanie wykryć błędne podejście, co może zaoszczędzić Państwu czasu.

Oprócz tego w dokumentacji należy umieścić listę funkcjonalności do zrealizowania. Lista ta musi być przemyślana. Stopień realizacji obietnic jest brany pod uwagę przy ocenie końcowej wersji projektu.

W dokumentacji wstępnej należy również umieścić tabelę z listą zadań oraz oszacowaniem czasu jaki zostanie poświęcony na każde z nich, czyli dany problem należy zdekomponować na zadania. Każde z nich dekomponujemy na podzadania. Postępujemy tak, aż dojdziemy do tak prostych zadań, że da się oszacować ich pracochłonność (w godzinach). Proszę dodać do tabeli wiersz z sumą godzin na wszystkie zadania. Suma ta powinna wynosić >50h na osobę, czyli zwykle >100h. Nie oczekuję, że to co Państwo zaplanują zgodzi się z rzeczywistością, zgodność ta przychodzi wraz z doświadczeniem w dekomponowaniu/oszacowywaniu i danej tematyce. Nie interesuje mnie podział prac w zespole. Testy automatyczne są nieodłączną częścią implementacji poszczególnych funkcjonalności - nie wymienia się ich oddzielnie w tabeli zadań. Niestety często lista funkcjonalności jest wprost kopiowana do tabeli zadań, co jest błędem. Czasem część funkcjonalności realizuje jeden prosty algorytm, więc nie ma sensu ich oddzielne wymienianie w tabeli zadań. W nietrywialnych projektach wybór odpowiednich bibliotek jest również ważnym zadaniem.

Dokumentacja powinna być najkrótsza jak to możliwe.

Ocenę za dokumentację wstępną obniżam tylko w przypadku zignorowania powyższych wskazówek lub w przypadku niepoważnego potraktowania tego etapu (braku myślenia), np. jak zespół obieca przesadnie trywialną i ograniczoną funkcjonalność, jak zespół nie odróżnia listy funkcjonalności od listy zadań, itp.

Szkielet aplikacji

Programy powinny być przenośne (działanie na Linux i Windows), ale najważniejsze jest aby program działał na platformie klienta. Tu ja pełnię rolę klienta. Używam Ubuntu 22.04 LTS, zatem proszę używać narzędzi i bibliotek dostępnych w pakietach wskazanej dystrybucji. Proszę nie używać najnowszych wersji bibliotek i narzędzi zmuszających mnie do instalacji niestandardowych wersji pakietów czy pobrania źródeł i kompilacji. Przykładowo - nie chcę pobierać i kompilować biblioteki boost, ponieważ są odpowiednie pakiety w Ubuntu. Najlepiej jest, jeśli co najmniej jeden członek zespołu pracuje na platformie docelowej.

Jeżeli jednak konieczne jest użycie zewnętrznej biblioteki (jeśli jest niezbędna a nie istnieje stosowny pakiet), to proces jej instalacji proszę zautomatyzować (skrypt) i skonfigurować tak, aby instalowała się lokalnie w katalogu projektu - nie w katalogu systemu operacyjnego.

Proszę nie przysyłać mi binariów, czyli bibliotek, plików wykonywalnych, wyników kompilacji.

Dokumentacja końcowa

O dokumentacji końcowej sporo napisał kierownik przedmiotu.

W dokumentacji końcowej proszę również zamieścić tabelkę z listą zadań i ich rzeczywistą płacochłonnością, należy ją porównać z analogiczną tabelką z dokumentacji wstępnej.

W dokumentacji końcowej nie może zabraknąć opisu funkcjonalności jakie zrealizowano, a także opisu architektury aplikacji, gdzie należy wyjaśnić jakie moduły ze sobą współpracują, a także opisać główne klasy i ich rolę w systemie. Proszę zamieścić diagram klas oraz schemat ER dla bazy danych jeśli jest używana.

Na podstawie dokumentacji końcowej oraz ewentualnych plików "Readme" muszę być w stanie uruchomić na własnym komputerze Państwa aplikację. Przed oddaniem projektu dobrze jest przetestować na "czystym" komputerze czy postępując zgodnie z instrukcją da się uruchomić Państwa projekt.

Dokumentacja końcowa powinna być w pliku .pdf, nie wolno jej mieszać czy mylić z wynikami automatycznych generatorów, np. Doxygen.

W dokumentacji należy opisać wszystkie nietrywialne algorytmy, które zostały zaimplementowane, np. jeśli projekt używa algorytmu ewolucyjnego to należy podać i opisać wzór na funkcję celu, opisać jakie operatory ewolucyjne zostały wykorzystane.

Oddawanie projektów

Oddawanie projektów przebiega w sposób następujący: Student wysyła e-mail z załącznikiem zawierającym wszystko to, co tej pory powstało w związku z projektem, po czym czeka na ocenę lub na zaproszenie na rozmowę. W temacie e-maila koniecznie proszę wpisać ZPR. Reguły biurokracji wymagają aby w przesłanym archiwum wraz z projektem końcowym przysłać również wszystko to, co się wcześniej wytworzyło. Archiwum powinno nazywać się tak jak nazwiska członków zespołu, np. Kowalski_Nowak.zip. Nie należy używać formatu .rar do pakowania kodu projektów przed wysłaniem. W archiwum powinien być porządek, dokumentacja końcowa niech nazywa się "dokumentacja końcowa.pdf", dokumentacja wstępna "dokumentacja wstępna.pdf", w katalogu ,,Szkielet aplikacji'' znajduje się wysłany szkielet aplikacji, a w katalogu ,,rozwiązanie zadania'' znajduje się rozwiązania zadania czyli to, co mam aktualnie sprawdzić. Oprócz tego w archiwum powinien istnieć plik ,,temat projektu.txt'' zawierający temat projektu w formie takiej jak podałem na stronie.

Proszę nie przysyłać mi binariów, czyli bibliotek, plików wykonywalnych, wyników kompilacji. Proszę również usunąć katalogi ukryte, np. repozytorium git (w Ubuntu Ctrl+h włącza pokazywanie ukrytych plików i katalogów - ich nazwy zaczynają się od kropki).

Tam gdzie ma to sens należy również dostarczyć przykładowych danych, aby po kompilacji projektu dało się go normalnie używać bez konieczności czasochłonnego wprowadzania dodatkowych danych. Przykładowe dane powinny być importowane przygotowanym skryptem z pliku txt (może być również zrzut bazy danych).

Nie ma osobistej "prezentacji projektu". Zespoły, których kod wzbudzi wątpliwości co do autorstwa zostaną zaproszone na rozmowę.