Budżet domowy
Rejestr przychodów i wydatków z kategoriami, miesięcznym podsumowaniem i wykresem.
Technologie: WPF lub .NET MAUI + SQLite
Po co ten projekt
Zbudujecie aplikację do pilnowania domowych finansów: zapisujesz przychody i wydatki, przypisujesz je do kategorii, a program pokazuje, ile zostało i na co idzie najwięcej. Coś, czego realnie moglibyście używać.
Co budujemy
- dodawanie transakcji (kwota, data, opis, typ: przychód/wydatek),
- przypisywanie transakcji do kategorii (jedzenie, transport, rozrywka…),
- bilans miesiąca: suma przychodów, suma wydatków, saldo,
- podsumowanie wydatków wg kategorii,
- prosty wykres udziału kategorii.
Struktura danych
Kategorie 1 ────< Transakcje Kategorie(id, nazwa, typ) Transakcje(id, kategoria_id →, kwota, data, opis, typ) typ: przychod / wydatek
Kontekst z życia
Każda aplikacja do finansów (od prostego arkusza po komercyjne apki) robi to samo: sumuje wpływy, sumuje wydatki, pokazuje saldo i rozkład. Wy zrobicie własną wersję z lokalną bazą SQLite.
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 (kategorie + min. 20 transakcji), zapytania: bilans miesiąca, suma wydatków wg kategorii |
| Programista interfejsu (UI) | widoki: lista transakcji, formularz dodawania, panel podsumowania z wykresem (słupki lub kołowy) |
| Programista logiki / tester | dodawanie/usuwanie transakcji, liczenie bilansu i sum wg kategorii, walidacja (kwota > 0, data poprawna), testy |
Harmonogram
| Tydzień | Kamień milowy |
|---|---|
| 1 | Analiza i projekt: zakres, diagram danych, podział zadań, harmonogram |
| 2 | Baza SQLite + szkielet aplikacji działa |
| 3 | Lista transakcji i formularz połączone z bazą |
| 4 | Bilans, podsumowanie wg kategorii, wykres + 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: kategorie + min. 20 transakcji (2)
- zapytanie „bilans miesiąca" działa (3)
- zapytanie „wydatki wg kategorii" działa (3)
Programista logiki / tester (0–10 pkt):
- dodanie transakcji zapisuje się do bazy (2)
- bilans przelicza się poprawnie (przychody − wydatki) (3)
- walidacja: kwota dodatnia, data poprawna (2)
- wykres odzwierciedla dane (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ę.