Planer dnia — menedżer zadań
Zadania z terminami, priorytetami i statusem oraz przypomnieniem o zbliżającym się terminie.
Technologie: WPF lub .NET MAUI + SQLite
Po co ten projekt
Zbudujecie aplikację do zarządzania zadaniami: dodajesz zadanie z terminem i priorytetem, oznaczasz jako zrobione, a program pokazuje, co pilne i co po terminie. Klasyczne „to-do", ale z bazą i porządną logiką.
Co budujemy
- dodawanie zadań (tytuł, opis, termin, priorytet, status),
- grupowanie zadań w projekty/listy (np. Szkoła, Dom),
- oznaczanie zadania jako ukończone,
- widok zadań na dziś i po terminie,
- sortowanie po priorytecie i terminie.
Struktura danych
Listy 1 ────< Zadania Listy(id, nazwa) Zadania(id, lista_id →, tytul, opis, termin, priorytet, status) priorytet: niski / sredni / wysoki status: do_zrobienia / zrobione
Kontekst z życia
Todoist, Microsoft To Do, kartka na lodówce — wszystkie służą temu samemu: nie zapomnieć, co i na kiedy. Wy zrobicie własny planer, który realnie mógłby Wam pomóc ogarnąć naukę i obowiązki.
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 (kilka list + min. 20 zadań o różnych terminach i priorytetach), zapytania: zadania na dziś, zadania po terminie, zadania wg priorytetu |
| Programista interfejsu (UI) | widoki: lista zadań z filtrowaniem, formularz dodawania, widok „na dziś", oznaczanie jako zrobione (checkbox) |
| Programista logiki / tester | dodawanie/edycja/ukończenie zadań, wyznaczanie zadań po terminie (porównanie z datą bieżącą), sortowanie, 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 zadań i formularz połączone z bazą |
| 4 | Widok „na dziś"/„po terminie", sortowanie, ukończanie + 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: kilka list + min. 20 zadań (2)
- zapytanie „zadania na dziś" (3)
- zapytanie „zadania po terminie" (3)
Programista logiki / tester (0–10 pkt):
- dodanie/edycja zadania zapisuje się do bazy (2)
- oznaczenie „zrobione" zmienia status (2)
- zadania po terminie są poprawnie wykrywane (porównanie z datą bieżącą) (3)
- walidacja: termin i priorytet poprawne (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ę.