Grunwaldzka Rent — wypożyczalnia sprzętu
Wypożyczalnia sprzętu (konsole i gry lub sprzęt sportowy) z naliczaniem kar za zwłokę.
Technologie: WPF lub PHP + MySQL
⬇ Pobierz bazę startową (.sql.gz)Uwaga przed importem: plik z bazą jest spakowany jako .gz. phpMyAdmin w XAMPP przyjmuje takie pliki bez rozpakowywania. Jeżeli po pobraniu nazwa wygląda np. bistro.sql_.gz i import nie przejdzie, zmień nazwę pliku na bistro.sql.gz, a potem wybierz go w zakładce Importuj.
Po co ten projekt
Zbudujecie system wypożyczalni: klient wypożycza sprzęt na określony termin, a przy zwrocie po czasie program nalicza karę za każdy dzień zwłoki. Temat sprzętu wybierzcie sami (konsole i gry, sprzęt sportowy, narzędzia). Projekt to klasyczne zadanie INF.03 z regułą naliczania kary.
Co budujemy
- ewidencja sprzętu (nazwa, kategoria, cena wypożyczenia za dzień, dostępność),
- rejestracja klientów (imię, nazwisko, telefon),
- wypożyczenie i zwrot z datą i terminem oddania,
- naliczanie kary za każdy dzień zwłoki,
- lista sprzętu aktualnie wypożyczonego i klientów z zaległościami.
Struktura danych
Klienci 1 ────< Wypozyczenia >──── 1 Sprzet
│
└───< Kary
Sprzet(id, nazwa, kategoria, cena_dzien, dostepny)
Klienci(id, imie, nazwisko, telefon)
Wypozyczenia(id, sprzet_id →, klient_id →, data_wyp, termin_zwrotu, data_zwrotu)
Kary(id, wypozyczenie_id →, kwota, oplacona)Kontekst z życia
Każda wypożyczalnia — od nart po elektronarzędzia — działa tak samo: wydajesz sprzęt, kontrolujesz termin zwrotu, liczysz karę za spóźnienie. Ta reguła (kara = dni zwłoki × stawka) to serce projektu.
Podział obowiązków
| Rola | Konkretne zadania w tym projekcie |
|---|---|
| Lider / analityk | ustala zakres, rysuje diagram danych, zakłada tablicę w Trello, pilnuje terminów, pisze dokumentację (instrukcja użytkownika + opis bazy), przygotowuje i prowadzi prezentację, scala pracę zespołu (Git / wspólny dysk) |
| Projektant bazy danych | skrypt rent.sql (4 tabele + klucze obce), dane testowe (min. 15 sztuk sprzętu, 10 klientów, 10 wypożyczeń), zapytania: sprzęt dostępny, klienci z zaległościami, suma kar klienta |
| Programista interfejsu (UI) | widoki: lista sprzętu, lista klientów, formularz wypożyczenia i zwrotu, panel zaległości |
| Programista logiki / tester | wypożyczanie/zwrot, automatyczne naliczanie kary wg dni zwłoki, walidacja (nie można wypożyczyć niedostępnego sprzętu), testy |
Harmonogram
| Tydzień | Kamień milowy |
|---|---|
| 1 | Analiza i projekt: zakres, diagram danych, podział zadań, harmonogram |
| 2 | Baza z danymi testowymi działa |
| 3 | Interfejs pokazuje sprzęt i klientów z bazy |
| 4 | Wypożyczenie/zwrot + naliczanie kary + testy |
| 5 | Scalenie, poprawki, dokumentacja, prezentacja przed klasą |
Kryteria oceny
Każdy uczeń dostaje ocenę indywidualną za swoją rolę (kryteria zero-jedynkowe) plus wspólny bonus zespołowy. Proporcja: 70% rola + 30% zespół.
Projektant bazy danych (0–10 pkt):
- 4 tabele z poprawnymi typami (1)
- klucze główne wszędzie (1)
- klucze obce łączą wypożyczenia ze sprzętem i klientami (2)
- dane testowe w wymaganej liczbie (1)
- zapytanie „klienci z zaległościami" działa (2)
- zapytanie „suma kar klienta" działa (2)
- nazewnictwo spójne (1)
Programista logiki / tester (0–10 pkt):
- wypożyczenie zmienia dostępność sprzętu (2)
- kara nalicza się poprawnie: dni zwłoki × stawka (3)
- walidacja: nie można wypożyczyć niedostępnego sprzętu (2)
- zwrot w terminie nie generuje kary (1)
- spisane wyniki testów (2)
Analogiczne zestawy kryteriów obowiązują Lidera (dokumentacja, harmonogram, prezentacja, scalanie) oraz Programistę UI (kompletność widoków, czytelność, połączenie z bazą, walidacja formularzy).
Ocena zespołowa (0–10 pkt):
- aplikacja uruchamia się i działa jako całość (3)
- części zespołu są zintegrowane, nie luźne kawałki (3)
- prezentacja jasno pokazuje działanie i podział pracy (2)
- dokumentacja kompletna: instrukcja + opis bazy (2)
Typowe błędy w pracy zespołowej
- brak wspólnego miejsca na kod → wersje się rozjeżdżają; ustalcie od razu Git albo jeden dysk,
- „zrobimy wszystko na końcu" → kamienie milowe są po to, żeby tego uniknąć,
- każdy pisze w swoim stylu → uzgodnijcie nazewnictwo tabel i zmiennych na starcie,
- nikt nie testuje integracji → tester wchodzi już w 4. tygodniu, nie na końcu.
W tym projekcie szczególnie: liczenie kary od złej daty (data wypożyczenia zamiast terminu zwrotu) — sprawdźcie na przykładzie z kartki, zanim zaufacie kodowi.
Nawiązanie do egzaminu
Ten projekt to w praktyce rozbudowane zadanie z części praktycznej INF.03 (baza danych + aplikacja operująca na danych, z regułą biznesową). Rozdzielając role, każdy z Was ćwiczy inny fragment tego, co na egzaminie trzeba umieć samodzielnie — a przy okazji uczycie się pracy zespołowej, którą sprawdza się i na maturze, i w prawdziwej firmie.