Zasady prowadzenia zajęć projektowych z przedmiotu „Metody i

Zasady prowadzenia zajęć projektowych z przedmiotu
„Metody i języki programowania”
studia zaoczne
wersja 1.0
1. Cel i zakres projektu
Celem jest zaprojektowanie oraz wykonanie pewnego programu (preferowany kompilator to
FreePascal; do pobrania ze strony producenta www.freepascal.org). Oceniane będą
następujące elementy (w nawiasach podano ich „wagę”):
a) projekt systemu (20%),
b) funkcjonalność gotowanego programu (60%),
c) sposób (estetyka) sformatowania finalnego kodu źródłowego (5%),
d) jakość umieszczonych w programie komentarzy (15%).
Ad a)
Student otrzymuje tylko bardzo skrótowo podany temat projektu (np. Wykonanie programu
implementującego grę w warcaby).
Jak widać sam temat nakreśla tylko bardzo ogólnie zadanie do wykonania. Brakuje tutaj
doprecyzowania wielu elementów. Przykładowo temat nie precyzuje, czy i w jakim zakresie
będzie wykorzystywana grafika. Nie wiemy też, czy chodzi o to, aby komputer był jednym z
graczy (zadanie dość trudne do implementacji, przy założeniu, że komputer ma grać
logicznie!), czy też grać mają dwaj „ludzcy” przeciwnicy, a komputer ma tylko „obsługiwać”
planszę do gry. Nie wiemy w końcu, w jaki sposób należy podawać swoje ruchy (wskazywać
pionki myszką, czy też podawać ich współrzędne – np.: „ruch pionka z A1 na B4”).
Wszystkie te elementy wchodzą w zakres etapu nazwanego „Projekt systemu” i muszą być
przygotowane w postaci PISEMNEJ (maksymalnie 1 strona tekstu przy czcionce o wielkości
12pt i pojedynczych odstępach między wierszami). Jeżeli poprawi to komunikatywność, tekst
może być uzupełniony o rysunki, schematy, szkice itp. Wówczas opracowanie może mieć
maksymalnie 2 strony.
Proszę pamiętać o podpisaniu projektu imieniem, nazwiskiem oraz numerem grupy.
Ad b)
Warunkiem koniecznym przyjęcia projektu jest oczywiście to, że program musi działać (czyli
dać się uruchomić w środowisku Windows/Linux). Program może jednak działać lepiej lub
gorzej, może być ergonomiczny lub też jego obsługa może być bardzo nieefektywna. Te i tym
podobne elementy też będą podlegały ocenie.
Należy również zwrócić szczególną uwagę na prawidłową obsługę wszystkich ew. błędów,
które mogą pojawić się podczas działania programu. Przykładowo, gdy użytkownik ma podać
dowolną liczbę z przedziału od 1 do 10, to należałoby programowo sprawdzić, czy
użytkownik rzeczywiście podał liczbę z tego przedziału. Gdy podana liczba jest inna należy
na ekranie wypisać stosowny komunikat.
Ponadto program testowany na tzw. „warunki krytyczne” musi takowe testy przejść.
Przykładowo, gdy piszemy program, który mnoży dwie macierze, musi on działać zarówno
dla macierzy o rozmiarze 1x1, jak i dla macierzy 100x100 (oczywiście istnieją jakieś
sensowne granice, które wyznacza np. ilość fizycznej pamięci w komputerze, czy czas
potrzebny na ukończenie obliczeń).
Ad c)
Kody programów muszą być jednolicie sformatowane. Przykładowo, gdy wykonujesz wcięcia
kodu na głębokość 2. znaków, to zasada ta powinna być przestrzegana w całym kodzie i nie
może być od niej wyjątków. Ponadto należy przyjąć jakiś jednolity schemat nazewnictwa
zmiennych, stałych itd. Przykładowo można przyjąć, że wszystkie nazwy zmiennych pisane
będą wyłącznie małymi literami a nazwy stałych dużymi. Bardziej istotne od przyjętego
schematu jest jednak jego konsekwentne stosowanie!
Ad d)
Kod programu, aby był czytelny dla osób innych niż autor, powinien być sensownie
skomentowany. Komentarze powinny być umieszczane tylko w istotnych miejscach. Nie
należy wpisywać komentarzy nieistotnych (np. całkowicie zbędny będzie komentarz w stylu:
„Poniższa funkcja writeln wypisuje na ekranie tekst powitania”). Z drugiej strony celowym
będzie napisanie w 2-3 zdaniach co robi dana procedura lub jakie znaczenie mają
poszczególne parametry tej procedury. Pamiętaj więc, że będzie oceniana jakość a nie ilość
umieszczonych w kodach źródłowych komentarzy!
2. Terminy i zasady oceny
Gotowy program (kod źródłowy oraz wersja skompilowana) muszą być oddane najpóźniej do
dnia 04-02-2007. Musi on zostać przesłany jako załącznik do poczty elektronicznej w
postaci archiwum ZIP. Warunkiem dopuszczenia do obrony projektów jest dostarczenie
zarówno projektu systemu, jak i działającego programu.
Na samej górze kodu źródłowego należy umieścić swoje imię, nazwisko oraz numer grupy
(jest to bardzo ważne, gdyż wyklucza różne pomyłki i trudności typu „który student przysłał
mi ten plik”).
Za każdy tydzień spóźnienia ocena obniżana jest o jeden. Prowadzący zastrzega sobie prawo
do nie przyjęcia projektu ze względu na jego złą jakość.
Zaliczenie projektu będzie zrealizowane w salach uniwersytetu w czasie sesji egzaminacyjnej.
Dzień, godzina spotkania oraz numer sali zostanie ustalony pod koniec semestru i
umieszczony na stronie serwisu https://e-weit.uz.zgora.pl. Podczas zaliczenia student będzie
musiał zaprezentować swój program i go obronić (m.in. wykazać, że jest jego autorem).
Prowadzący może podczas zaliczenia zadawać studentowi różne, nawet bardzo szczegółowe,
pytania dotyczące zrealizowanego projektu.
W przypadku niedostarczenia na czas projektu lub jego złej jakości student nie otrzymuje
wpisu zaliczeniowego oraz nie ma możliwości zdawania „w późniejszym terminie”. Jedyne
uwzględniane usprawiedliwienia mogą dotyczyć tylko przypadków losowych (za taki nie
będą uznawane np. „niespodziewane awarie dysku”, „rozsypanie się systemu operacyjnego”,
„zgubienie dyskietki” oraz tym podobne często stosowane tłumaczenia).
3. Kontakt
Zajęcia realizowane są w trybie zdalnym (kontakt za pomocą internetu). Kontaktujemy się ze
sobą tylko za pośrednictwem serwisu https://e-weit.uz.zgora.pl. W szczególnych przypadkach
możemy spotykać się osobiście w terminach zjazdów.