Powrót do strony głównej

Organizacja zajęć

Zajęcia laboratoryjne są prowadzone bez przerwy przez 1,5 godziny.

Konsultacje

t.b.d.

Ocena

  • Skala ocen na zaliczenie: 5 (bdb), 4,5 (+db), 4 (db), 3,5 (+dst), 3 (dst), 2 (ndst).

  • Zaliczenie na ocenę 5,5 (cel) może uzyskać student, który wykaże się wiedzą lub umiejętnościami znacznie wykraczającymi poza zakres przewidziany w programie nauczania.

  • Indywidualnej ocenie podlega 5 list zadań (realizowanych na zajęciach 2—​6) oraz 3 etapy projektowe realizowane podczas drugiej częsci semestru.

  • Na każdej z list zadań określona jest skala punktowa, na podstawie której wystawiana jest ocena.

  • Ocena końcowa jest średnią ważoną ocen cząstkowych. Oceny za listy zadań mają wagę 1, oceny za etapy projektu mają wagę 2.

Wymagania

  • Na zajęcia należy przychodzić punktualnie.

  • Uczestnictwo w zajęciach laboratoryjnych jest obowiązkowe: dopuszcza się jedną nieobecność nieusprawiedliwioną i jedną nieobecność usprawiedliwioną w semestrze.

  • Materiał z zajęć, na których student nie był obecny, musi być opanowany a zadania wykonane.

  • Na zajęcia należy przygotować się poprzez zapoznanie się z materiałem z wykładów i z wcześniej zapowiedzianymi tematami zajęć.

  • Uwagi ogólne dotyczące zaliczeń:

    • W tabeli Harmonogram zajęć laboratoryjnych określono termin zaliczeń dla każdej z list zadań oraz każdego etapu projektu.

    • Zadań lub etapów projektu nie można oddawać na konsultacjach.

    • Zadania lub etap projektu oddane na następnych zajęciach po obowiązującym terminie są oceniane najwyżej na ocenę dostateczną (3), materiał oddany po tym czasie oceniany jest na ocenę 2 (ndst).

  • Szczegółowe zasady dotyczące prac z listami zadań:

    • Na kolejnych pięciu zajęciach studenci rozwiązują osobiście listy zadań.

    • Listy zadań dostepne są pod następującym adresem: https://pwr-piisw.github.io/materialy/index.html#_listy_zadań.

    • Na każdej liście zadań umieszczone są informacje, w jaki sposób rozwiązania zadań należy umieszczać w repozytorium GitHub.

  • Szczegółowe zasady dotyczące pracy z kodem podczas fazy projektowej:

    • Na zajęciach 7-mych studenci tworzą 2-3 osobowe grupy projektowe, w ramach których realizować będą projekt.

    • Każda grupa projektowa powinna zgłosić prowadzącemu temat projektu na 7-mych zajęciach. Temat należy wybrać z listy umieszczonej na końcu tego dokumentu.

    • Każdy zespół projektowy zobowiązany jest do utworzenia repozytorium projektowego na portalu GitHub. Prowadzącemu zajęcia należy nadać prawa zapisu i odczytu do tego repozytorium.

    • Wszyscy członkowie zespołu zobowiązani są do wprowadzania zmian bezpośrednio do repozytorium zespołu.

    • Każdy członek zespołu zobowiązany jest utrzymywać repozytorium w stanie “zielonym” - CI po zmianach powinno być zielone, w przypadku wystąpienia błędów należy je niezwłocznie usuwać.

    • Podczas oddawania danego etapu zadania prowadzący sprawdza stan CI - niestabilne CI może być przyczyną niezaliczenia etapu.

    • Zmiany w repozytorium (kodzie aplikacji) powinny być odpowiednio i czytelnie komentowane (ang. commit message).

    • W przypadku każdego z trzech etapów zaliczeniowych należy utworzyć w repozytorium tag o nazwach odpowiednio: etap1, etap2 oraz etap3.

    • Zaimplementowany system powinien dać się uruchomić na dowolnym komputerze wyposażonym w system Microsoft Windows.

Wpływ na ocenę będzie miało:

  • Spełnienie wymagań.

  • Jakość rozwiązania - zarówno wewnętrzna jak i zewnętrzne.

  • Strategia testowania i zastosowane narzędzia.

Kopiowanie prac innych studentów skutkuje automatycznie niezaliczeniem zajęć!

Harmonogram zajęć laboratoryjnych

Lp Data Temat Termin zaliczenia

1

2024-02-29

Zajęcia organizacyjne. Konfiguracja środowiska roboczego.

2

2024-03-07

HTML i CSS.

3

2024-03-14

Javascript.

Zaliczenie listy 1

4

2024-03-21

Tworzenie backendu - serwisy Restful, testowanie backendu.

Zaliczenie listy 2

5

2024-04-4

Tworzenie backendu - data persistence, mockowanie danych.

Zaliczenie listy 3

6

2024-04-11

Tworzenie aplikacji Angular, testowanie kodu frontendu.

Zaliczenie listy 4

7

2024-04-18

Podział na grupy projektowe, wybór i akceptacja tematu projektu.

Zaliczenie listy 5

8

2024-04-25

Projekt — frontend

9

2024-05-09

Projekt — frontend

10

2024-05-16

Projekt — frontend

Zaliczenie części frontendowej

11

2024-05-23

Projekt — backend i integracja

12

2024-06-06

Projekt — backend i integracja

Zaliczenie części backendowej.

13

2024-06-13

Projekt — data persistence

14

2024-06-20

Projekt — data persistence

Zaliczenie całości projektu.

15

2024-06-24

Zaliczenie końcowe. Wystawienie ocen.

Zaliczenie — 2-gi termin.

Tematów projektów

Każdy z zespołów projektowych powinien wybrać jeden z następujących projektów do realizacji.

System sprzedaży biletów kinowych

Aplikacja umożliwia rezerwację biletów na seans kinowy oraz weryfikację ważności biletów.

Użytkownik (widz), bez konieczności logowania się do systemu może przeglądać dostępny repertuar (data, godzina i czas trwania seansów; film, jego opis oraz zdjęcie).

Widz może kupić bilety na wybrany seans o ile są wolne miejsca. Kupno biletów wiąże sie z wyborem seansu (data, godzina oraz sala - kino może składać się z wielu sal) oraz wyboru miejsc w sali kinowej. Klient dokonuje wyboru miejsca na widoku reprezentującym schematyczną salę kinową z zaznaczonym ekranem oraz rzędami foteli. Klient zaznacza kliknięciem interesującą go liczbę foteli oraz potwierdza rezerwację. W efekcie wygenerowany zostaje unikalny kod rezerwacji, który jest dowodem zakupu biletu.

Repertuar kinowy, sale oraz katalog filmów można/należy "zahardkodować w systemie".

Bileter jest uprawnionym użytkownikiem, który posiada możliwość sprawdzenia ważności biletu dla wprowadzonego kodu. Bilet może w jednym z następujących stanów: nie istnieje, ważny, skasowany, nieważny.

Bilet jest ważny jedynie w czasie poprzedzającym 15 minut seans, traci zaś ważność z końcem seansu.

Bileter oprócz stanu biletu, powinien także zobaczyć ilość zarezerwowanych miejsc, nr sali oraz numery miejsc. Bileter powinien mieć możliwość skasowania biletu, a więc zmianę jego stanu z ważny do skasowany.

System powinien obsługiwać dwie klasy użytkowników:

Widzowie

Przeglądanie repertuaru oraz kupno biletu na wskazany seans oraz rezerwacja wybranych miejsc na sali kinowej.

Bileterzy

Funkcja sprawdzenia ważności oraz skasowania biletu. Dostęp do funkcjonalności wymaga wcześniejszego zalogowania się do systemu.

Tablica ogłoszeń drobnych

System umożliwia publikację ogłoszeń wraz z informacjami kontaktowymi.

Sprzedający posiadają w systemie odpowiednie konta. Po zalogowaniu mają oni możliwość dodawania, edytowania i usuwania własnych ogłoszeń drobnych.

Ogłoszenie składa się z tytułu, opisu, galerii zdjęć oraz tagów.

Sprzedający posiada pewną ilość danych kontaktowych (telefon, email), które może udostępniać wraz z ogłoszeniem. Dla każdego ogłoszenia można dane kontaktowe udostępniać indywidualnie.

Dostępna jest też poczta wewnętrzna, która pozwala na komunikację ze sprzedającym bez użycia zewnętrznego adresu email i telefonu. Poczta wewnętrzna jest zawsze dostępna (może być jedynym środkiem komunikacji).

Sprzedający mogą swobodnie dodawać własne tagi lub podpinać się do tagów już istniejących.

Ogłoszenie może być w trzech stanach: wersja robocza, opublikowane, archiwum. Ogłoszenie w stanach: wersja robocza i archiwum jest widoczne jedynie dla ogłoszeniodawcy.

Ogłoszeniodawca powinien mieć możliwość poglądu wersji roboczej aby zobaczyć, jak ogłoszenie będzie finalnie wyglądać. Tę funkcjonalność można zrealizować np z użyciem losowo wygenerowanego tajnego linku.

Kupujący mogą przeszukiwać bazę opublikowanych ogłoszeń z wykorzystaniem wyszukiwania tekstowego (po nazwie i opisie) oraz po tagach.

System powinien w wyszukiwarce podpowiadać tagi sortując je wg częstości użycia, na podstawie wprowadzonych znaków.

System powinien udostepniać prosty mechanizm poczty wewnętrznej. Poczta powinna umożliwiać wysłanie wiadomości tekstowej od jednego do drugiego użytkownika systemu. Poczta powinna zawierać zakładkę z zawartością skrzynki z wiadomościami. Powinna być dostępna funkcja: odpowiedz.

System powinien obsługiwać dwie klasy użytkowników:

Kupujący

Funkcja wymaga zalogowania się do systemu. Kupujący może przeglądać ogłoszenia. Kupujący, po zalogowaniu, otrzymuje dodatkowo możliwość korzystania z poczty wewnętrznej.

Ogłoszeniodawcy

Funkcja wymaga zalogowania się do systemu z użyciem loginu i hasła.

Zwróćcie uwagę, że w tym systemie kupujący może być także sprzedającym.

Elektroniczny bilet miejski

Użytkownik uzyskuje możliwość rejestracji w serwisie oraz wygenerowanie wirtualnego biletu umożliwiającego korzystanie z systemu transportu zbiorowego. System umożliwia weryfikację sprawdzanych biletów.

Pasażer może założyć sobie konto w systemie. W ramach konta możliwe jest przeglądanie dostępnej oferty biletowe (bilety czasowe, jednorazowe, okresowe; ulgowe i normalne). Pasażer może wybrać dowolny bilet, wybrać jego ważność (w przypadku biletów czasowych i okresowych) oraz dokonać zakupu. Po zakupie, bilet pojawia się w zakładce "moje bilety". Każdy bilet posiada unikalnie wygenerowany kod, umożliwiający jego walidację.

System powinien posiadać prosty interfejs REST pozwalający na zintegrowanie z systemem kasowników (każdy bilet jednorazowy i czasowy wymaga skasowania, bilet nieskasowany jest nieważny).

Bileter posiada możliwość sprawdzenia ważności biletu - w tym celu konieczne jest wprowadzenie kodu biletu oraz identyfikatora pojazu. Bilet może być ważny lub nieważny. Bilet jest ważny tylko wtedy, gdy:

  • W przypadku biletu okresowego - data kontroli zawiera się w okresie ważności biletu.

  • W przypadku biletu jednorazowego - bilet został skasowany w pojeździe, w którym przeprowadzana jest kontrola.

  • W przypadku biletu czasowego - nie upłynął czas ważności biletu od momentu skasowania biletu.

System powinien obsługiwać dwie klasy użytkowników:

Pasażer

Funkcja wymaga zalogowania się do systemu. Kupujący może przeglądać dostępną ofertę biletową, kupić bilet oraz podglądać zakupione bilety wraz z historią transakcji.

Bileter

Funkcja wymaga zalogowania się do systemu. Bileter może sprawdzać ważność kodu biletu.

Powrót do strony głównej