For students: Projekt Indywidualny

Zajęcia:

  • Terminy zajęć
    • Wtorek 16:15-19:00, sala 317A, prowadzący: P. Rzążewski
    • Czwartek 9:15-12:00, sala 626A IL, prowadzący: M. Kobos
    • Czwartek 9:15-12:00, sala 232B, prowadzący: P. Rzążewski
    • Czwartek 14:15-17:00, sala 626A IL, prowadzący: M.Kobos
  • Osoby prowadzące zajęcia: Mateusz Kobos (główny prowadzący), Paweł Rzążewski

Projekty (wraz z odnośnikami do przykładowych implementacji prezentujących podstawową mechanikę danej gry):

Oceny (w przypadku kłopotów z pobieraniem plików, proszę o maila):

  • Uwagi i pytania dotyczące wystawionych ocen będzie można zgłaszać:
    • w terminie wystawiania ocen (grupy Mateusza Kobosa),
    • po uprzednim umówieniu się przez e-maila (grupy Pawła Rzążewskiego).

1. Harmonogram zajęć (sem. letni 2011)

Grupy Etap Komentarz
Wtorek Czwartek
1 22.02 22.02/24.02 Przydział projektów
2 Uwaga: jednorazowe przeniesienie zajęć M. Kobosa w dn. 03.03 z godziny 14:15 na 15:15
3 8.03 10.03 Specyfikacja użytkownika
4 15.03 17.03 Przydział zadań do implementacji [Update] Również: wprowadzenie do diagramów klas w UML w dn. 17.03.2011, godz. 17:15, sala 213 (dla wszystkich grup)
5
6
7 05.04 07.04 Projekt techniczny
8
9 19.04 21.04 Implementacja: kontrola implementacji 1 Działające fragmenty programu, kontrola jakości kodu
10
11 10.05 05.05 Implementacja: kontrola implementacji 2 Zaimplementowana główna funkcjonalność (możliwość grania w grę), kontrola jakości kodu
12 [Update] Zajęcia M. Kobosa w dn. 12.05 przeniesione z godziny 9:15 na godzinę 10:15
13 17.05 19.05 Implementacja: wersja beta Zaimplementowana cała funkcjonalność programu, dozwolone działanie nie całkiem stabilne
[Update] Zajęcia M. Kobosa w dn. 19.05 przeniesione z godziny 9:15 na godzinę 10:15
14 24.05 26.05 Implementacja: wersja końcowa oraz przydział testów [Update] Przesunięcie terminów oddania kolejnych etapów projektu o tydzień (zgodnie z wnioskiem studentów). [Update] Zajęcia M. Kobosa w dn. 26.05 przeniesione z godziny 9:15 na godzinę 10:15
15 31.05 02.06 Implementacja: wersja końcowa oraz przydział testów [Update] Zajęcia M. Kobosa w dn. 02.06 przeniesione z godziny 9:15 na godzinę 10:15
16 07.06 09.06 Wpisywanie ocen Raport z testów [Update] Zajęcia M. Kobosa w dn. 09.06 przeniesione z godziny 9:15 na godzinę 10:15
X 16.06 16.06 Wpisywanie ocen [Update] Wpisy o godz. 10:15 w sali 233
X 27.06 27.06 Dodatkowy termin wpisywania ocen [Update] Wpisy o godz. 09:15 w sali 233

2. Cele przedmiotu i założenia projektu

Celem przedmiotu jest zapoznanie się z następującymi zagadnieniami:

  • Podstawy tworzenia większego projektu informatycznego.
  • Tworzenie dokumentacji (specyfikacja użytkownika i projekt techniczny).
  • Tworzenie kodu źródłowego wysokiej jakości.

By realizować powyższe cele, założono, że projekt posiada cechy wymienione poniżej. Warto zwrócić uwagę, że w przypadku projektu implementowanego na tych zajęciach założenie, że projekt jest duży/b. duży nie jest spełnione (a więc w tym przypadku należałoby prawdopodobnie stosować inny model rozwoju aplikacji). Założenia implementowanego projektu:

  • Projekt nie jest b. mały i możliwe, że będzie rozwijany po jego ukończeniu (np. przez inną osobę). Wynika z tego, że:
    • ważna jest jakość/elegancja kodu (kosztem szybkości rozwoju implementacji),
    • końcowa postać kodu powinna być zdatna do ponownego wykorzystania (ang. reusability) i rozszerzenia.
  • Projekt jest duży/b. duży. Wynika z tego, że projekt jest podzielony na kolejne, oddzielone od siebie etapy: tworzenia projektu technicznego, implementacji i testowania. Etapy te normalnie wykonywane byłyby przez różnych ludzi (ew. różne grupy). Jest to tzw. model kaskadowy (ang. waterfall model) rozwoju oprogramowania.
    • Do tworzenia mniejszych/średnich aplikacji ew. modułów do dużych/b.dużych aplikacji bardziej nadają się modele “zwinne” (ang. agile software development), gdzie etapy projektowania, implementacji, testowania wielokrotnie przeplatają się ze sobą w trakcie całego procesu rozwoju oprogramowania.

Etapy powstawania aplikacji

Poniżej przedstawiono etapy powstawania projektu informatycznego wraz z artefaktami, które są wynikiem każdego z etapów.

  1. Analiza wymagań użytkownika i tworzenie specyfikacji użytkownika. Wynik: specyfikacja użytkownika (dokumentacja wstępna).
  2. Projektowanie aplikacji. Wynik: projekt techniczny (dokumentacja techniczna).
  3. Implementacja. Wynik: aplikacja razem ze zaktualizowaną dokumentacją.
  4. Testowanie. Wynik: raport z testów.
  5. Wdrożenie i konserwacja (ang. deployment and maintenance). Wynik: aplikacja poprawnie działająca u klienta.

3. Ogólne wymagania dotyczące oddawanych dokumentów

Oddawana dokumentacja powinna być zgodna z poniższymi wymaganiami:

  • Postać oddawanego dokumentu: wydruk komputerowy.
  • Polski tekst powinien być zgodny z normami języka polskiego.
  • Nie należy nadużywać zdań wielokrotnie złożonych – tekst powinno się łatwo czytać.
  • Wymagania dotyczące struktury dokumentu:
    • Na pierwszej stronie powinno znajdować się: imię, nazwisko, nazwa grupy studenckiej, tytuł dokumentu, data.
    • W dalszej części dokumentu powinien znajdować się spis treści (najlepiej użyć odpowiedniej opcji do automatycznego generowania (MS Word, OpenOffice Writer, LaTeX, …)).
    • Dokument powinien być podzielony na rozdziały/sekcje/części (tak, by w dokumencie można było łatwo znaleźć każde z opisywanych zagadnień).
    • Wszystkie rozdziały/sekcje/części dokumentu powinny być ponumerowane wg schematu: “1. Tytuł pierwszej części”, “1.1. Tytuł pierwszej podczęści pierwszej części”, “2. Tytuł drugiej części” itd.
    • Strony powinny być ponumerowane.

4. Opis wymagań związanych z kolejnymi etapami projektu

4.1. Specyfikacja użytkownika

Ogólnie, dokumentacja powinna:

  • przedstawiać co program ma robić (nie powinna opisywać jak program ma to robić – tym zajmuje się projekt techniczny),
  • opisywać program z punktu widzenia użytkownika.

Wymagana zawartość

  • Szczegółowy opis interfejsu użytkownika (z obrazkami)
    • dokładny opis wszystkich pozycji w menu i wszystkich opcji pojawiających się w oknach dialogowych
    • obraz/schemat (screenshot) głównego ekranu gry
  • Opis funkcjonowania programu z punktu widzenia użytkownika:
    • zasady gry,
    • sterowanie,
    • obiekty występujące w grze,
    • zapisywanie i odczytywanie z pliku “hi-score” – spisu najlepszych graczy,
    • kilka poziomów trudności gry,
    • itp.

4.2. Projekt techniczny z instrukcją użytkownika

Ogólnie, dokumentacja powinna:

  • przedstawiać jak program ma działać (czyli realizować funkcjonalność opisaną w dokumentacji wstępnej),
  • opis ma być na tyle szczegółowy, by inny programista bez dodatkowych pytań mógł przystąpić do implementacji.

Wymagana zawartość

  • W dokumencie powinny być wydzielone przynajmniej następujące części (w razie potrzeby z podpunktami):
    • struktura klas. Komentarze:
      • m.in. powinien być zawarty diagram UML przedstawiający ogólną budowę całego programu (główne klasy/moduły)
      • dla każdej z klas powinien być podany krótki opis przedstawiający filozofię stojącą za daną klasą/zakres odpowiedzialności tej klasy w programie.
    • opis algorytmów. Komentarze:
      • preferowane sposoby prezentacji algorytmów:
        1. pseudokod – połączenie konstrukcji programowych z językiem naturalnym, np:
          while ( istnieją niezaktualizowane obiekty )
          {
          	oblicz parametry
          	aktualizuj stan systemu
          	zrób coś jeszcze
          }
        2. ponumerowane punkty
        3. diagramy
      • opis algorytmów jednolitym tekstem jest nieakceptowalny
      • opis algorytmów powinien zawierać wszystkie przypadki szczególne
      • podczas gry powinna być zauważalna “inteligencja” komputera (podczas gry np. duszek nie powinien blokować się, jeśli nie może bezpośrednio dojść do diggera, powinien być w stanie ominąć przeszkody)
      • przy dokładniejszym opisie algorytmu, należy odwoływać się do zmiennych z diagramów UML (typu Klasa.zmienna)
      • Jeśli korzystamy ze znanego algorytmu (np. algorytm Dijkstry, A*), to powinno być opisane w jaki sposób struktury używane w programie przekładają się (są interpretowane lub konwertowane) na struktury używane przez ten algorytm (np. w jaki sposób plansza jest interpretowana jako graf, którym posługuje się algorytm Dijkstry/A*). Przy korzystaniu ze znanego algorytmu, nie ma potrzeby jego dokładnego opisywania.
    • instrukcja użytkownika. Komentarze:
      • instrukcja powinna zawierać informacje umożliwiające świadomą grę (opis np.: sterowania grą, ile warte są jakie bonusy, co znaczą możliwe do ustawienia opcje itp.)
  • Ponadto powinny być opisane następujące zagadnienia:
    • inicjalizacja programu
    • obsługa plików (jak wykonywane jest wczytywanie/zapisywanie Hi-Score). Komentarze:
      • należy a) podać format używanych plików i opisać jak ten format jest zamieniany na strukturę przechowywaną w programie lub b) podać, że wykonywana jest serializacja i określić co i jak jest serializowane.
    • opis różnych poziomów trudności gry

Pomocnicze dokumenty związane z tym etapem projektu

4.3. Implementacja

Wymagania względem programu

  • Warstwa biznesowa (engine gry) powinna być oddzielona od warstwy prezentacji (elementy związane z interfejsem użytkownika). Chodzi tutaj o to, by engine gry nie był zaszyty bezpośrednio w formatkach odpowiedzialnych za wyświetlanie, ale żeby stanowił oddzielny moduł. Dzięki temu zabiegowi kod staje się bardziej przejrzysty i pozwala na łatwą i w miarę niezależną modyfikację obu warstw.
  • Gra powinna zawierać następujące opcje przeznaczone dla testera gry:
    • możliwość przenoszenia się między poziomami, by łatwo można było np. sprawdzić inteligencję zaawansowanych przeciwników pojawiających się w późniejszych etapach gry;
    • nieśmiertelność.
  • Gra powinna być intuicyjna w obsłudze – w zasadzie nie powinno być potrzeby korzystania z instrukcji (a więc np. użytkownik gry nie powinien być zmuszony do korzystania z tajemniczych skrótów klawiaturowych).
  • W programie powinna być dostępna prosta instrukcja użytkownika.
  • Używana grafika nie powinna być trywialna (powinny być używane bitmapy zamiast prostych figur geometrycznych).

Pomocnicze dokumenty związane z tym etapem projektu

  • Dokumenty opisujące styl kodowania obowiązujący podczas implementacji zadań projektowych. Niestosowanie się do zaleceń z działu “wymagane” skutkować będzie obniżeniem oceny.
  • Materiały związane z programem Gendarme, który służy do automatycznego sprawdzania stylu kodowania
  • Informacje dotyczące tworzenia komentarzy w języku C#.

4.4. Wersja końcowa projektu

Końcowa wersja projektu powinna być oddana w formie spakowanego pliku o nazwie zgodnej ze wzorcem: “Nazwisko_Imie.zip”.

Zawartość spakowanego pliku:

  • źródła programu
  • wersja “Release” programu gotowa do uruchomienia (z załączonymi bibliotekami itp.), bez plików tymczasowych (np. bez plików *.obj, katalogu “Debug”)
  • dokumentacja końcowa wygenerowana automatycznie ze źródeł (np. za pomocą programu Sandcastle Help File Builder)
  • instrukcja użytkownika
  • lista zmian względem specyfikacji użytkownika
  • lista zmian w dokumentacji technicznej (względem wersji pierwotnej)

4.5. Testy akceptacyjne

Ogólnie, główne cele testowania to

  • wykrycie i usunięcie błędów oraz
  • ocena niezawodności.

Różnego rodzaju testy można wykonywać na różnych etapach tworzenia aplikacji (od specyfikacji użytkownika po testy związane z konserwacją i wprowadzaniem poprawek do systemu zainstalowanego i działającego u klienta).

Na tym etapie będziemy zajmować się testami akceptacyjnymi. Testy te są wykonywane z punktu widzenia użytkownika/końcowego odbiory programu, który nie ma dostępu do kodu źródłowego programu i opiera się tylko na analizie zewnętrznego zachowania programu (tzw. testy „czarnej skrzynki” (black box)).

Cele testów akceptacyjnych:

  • Sprawdzenie, czy program poprawnie realizuje funkcjonalność opisaną w specyfikacji użytkownika.
    • W naszym przypadku: należy sprawdzić funkcjonalność gry korzystając z dokumentów specyfikacji użytkownika i zmian względem specyfikacji użytkownika (zakładamy, że zmiany względem specyfikacji użytkownika zostały zatwierdzone przez odbiorcę).
  • Ocena jakości produktu końcowego widzianego z perspektywy użytkownika/odbiorcy.
    • W naszym przypadku: należy sprawdzić, czy gra działa poprawnie w trakcie normalnego użytkowania (przykłady niepoprawnego działania: pojawienie się okna dialogowego informującego o powstaniu wyjątku w programie, zakończenie działania programu w nieodpowiednim momencie, możliwość wyjścia głównego bohatera poza planszę) i w przypadkach szczególnych (np. podanie pustego string-u imienia w „hi-score”).

Warto zwrócić uwagę, że to, czy dane zachowanie jest poprawne czy błędne, jest określone poprzez specyfikację użytkownika. Np. jeśli przeciwnik w trakcie rozgrywki przechodzi przez ściany, to domyślnie jest to zachowanie niepoprawne, jeśli jednak w specyfikacji użytkownika jest napisane, że tak właśnie dany przeciwnik ma się poruszać (bo np. jest duchem), to jest to zachowanie poprawne.

Raport z testów powinien opisywać program z perspektywy celów testów akceptacyjnych.

5. Zasady oceniania

Oceniane są kolejne etapy pracy nad programem przedstawione w harmonogramie zajęć. Gotowa aplikacja powinna realizować postawione przed nią zadania (określone w specyfikacji użytkownika), posiadać wygodny interfejs i instrukcję dla użytkownika. Oceniana jest również jakość kodu źródłowego.

Ocena końcowa jest wystawiana zgodnie ze standardowymi progami procentowymi i uwzględnia oceny z każdego z etapów w sposób następujący:

  • 10% – specyfikacja użytkownika
  • 25% – projekt techniczny
  • 55% – implementacja
    • 5% – wersja beta
    • 30% – działanie programu
    • 15% – jakość kodu
    • 5% – dokumenty w postaci elektronicznej: dokumentacja końcowa (wygenerowana ze źródeł) i instrukcja użytkownika
  • 10% – raport z testów

Dodatkowo, ocena końcowa jest obniżana na skutek opóźnień w oddawaniu kolejnych etapów projektu. W przypadku opóźnienia oddawania etapów “Specyfikacja użytkownika” i “Implementacja: wersja końcowa”, każdy tydzień opóźnienia powoduje utratę 10% ogólnej liczby punktów. Opóźnione oddanie dokumentacji technicznej oraz opóźnienia podczas procesu implementacji (nawet jeśli wersja końcowa będzie oddana w terminie) również mogą powodować obniżenie oceny.

Osoby, które po trzecich zajęciach nadal nie maja przydzielonego zadania, nie zaliczają przedmiotu.

Comments are closed.