Spiżarnia i lista zakupów
Ewidencja domowych zapasów z terminami ważności i automatyczną listą zakupów.
Technologie: .NET MAUI (mobilna) + SQLite
Po co ten projekt
Zbudujecie aplikację, która wie, co macie w domu i czego brakuje: ewidencja produktów z ilością i terminem ważności, ostrzeżenia o kończących się terminach, automatyczna lista zakupów z produktów poniżej minimalnego stanu.
Co budujemy
- ewidencja produktów (nazwa, ilość, jednostka, termin ważności, stan minimalny),
- przypisywanie produktów do kategorii (nabiał, pieczywo, chemia…),
- lista produktów z kończącym się terminem ważności,
- automatyczna lista zakupów — produkty, których ilość spadła poniżej stanu minimalnego,
- odhaczanie kupionych produktów aktualizujące zapas.
Struktura danych
Kategorie 1 ────< Produkty Kategorie(id, nazwa) Produkty(id, kategoria_id →, nazwa, ilosc, jednostka, termin_waznosci, stan_min)
Kontekst z życia
Znacie to: otwierasz lodówkę, a mleko się skończyło albo właśnie przeterminowało. Ta aplikacja rozwiązuje realny domowy problem — pilnuje zapasów i sama układa listę zakupów.
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 | baza SQLite (2 tabele), dane testowe (min. 20 produktów w kilku kategoriach), zapytania: produkty poniżej stanu min., produkty z terminem w ciągu 3 dni |
| Programista interfejsu (UI) | widoki: lista produktów z ilością i terminem, formularz dodawania, ekran listy zakupów, ekran ostrzeżeń o terminach |
| Programista logiki / tester | dodawanie/edycja produktów, generowanie listy zakupów z produktów poniżej stanu min., odhaczanie kupionych aktualizujące ilość, walidacja, testy |
Harmonogram
| Tydzień | Kamień milowy |
|---|---|
| 1 | Analiza i projekt: zakres, diagram danych, podział zadań, harmonogram |
| 2 | Baza SQLite + szkielet aplikacji działa |
| 3 | Lista produktów i formularz połączone z bazą |
| 4 | Automatyczna lista zakupów + ostrzeżenia o terminach + 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):
- baza SQLite z 2 tabelami i kluczem obcym (2)
- dane testowe: min. 20 produktów (2)
- zapytanie „produkty poniżej stanu min." (3)
- zapytanie „produkty z bliskim terminem ważności" (3)
Programista logiki / tester (0–10 pkt):
- dodanie/edycja produktu zapisuje się do bazy (2)
- lista zakupów generuje się z produktów poniżej stanu min. (3)
- odhaczenie kupionego zwiększa zapas (2)
- walidacja: ilość ≥ 0, termin poprawny (2)
- spisane wyniki testów (1)
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.
Nawiązanie do egzaminu
Ten projekt łączy logikę aplikacji, interfejs i lokalną bazę SQLite — czyli rdzeń części praktycznej INF.04 (aplikacja desktopowa/mobilna). Podział ról pozwala każdemu skupić się na innym fragmencie tego, co na egzaminie robi się w pojedynkę.