PRI (ZPRI) - Inżynierski projekt zespołowy

Uwagi do PRI/1 oraz PRI/2

1. Obrona projektu przed KOMISJĄ: 18.01.2025, 14:00-18:00, stacjonarnie, (prawdopodobnie B3-8/9)
   Jak powinno wyglądać wystąpienie przed KOMISJĄ?
   
   • slajdy: krótki wstęp, funkcjonalności, architektura, podział pracy
   • prezentacja produktu "na żywo" (działającej aplikacji, NIE pokazujemy kodu)
2. Zasady prowadzenia "inż projektu zespołowego" w skrócie:
   1. folder 2024 /kopia/ z dokumentami (szablony, slajdy, oficjalny regulamin)
   2. UWAGA: tematy prac dyplomowych/inż muszą być w sys APD przed obroną prj (w 1 semestrze !!!)
   3. istnieje karta oceny, w której przedstawiono szczegółowo jak komisja ocenia projekt
      (patrz: teams/Pliki, będziemy uzupełniać tą kartę dla każdej grupy)
   4. zajęcia PRI trwają 2 semestry! (PRI/1, PRI/2),
      równolegle z PRI/2 odbywa się SDD (Seminarium Dyplomowe)
      po 1 i 2 sem. projekt jest broniony przed KOMISJĄ !!!
   5. grupy projektowe: 3-4 osoby w grupie
   6. każda osoba musi być odpowiedzialna za ważną część systemu,
      tj. wszyscy muszą mieć funkcje programistyczne!!
   7. praca w grupach zgodnie z wybraną "metodyką" pracy nad projektem + narzędzia
      (metodyka zwinna, np. SCRUM; narzędzia: jira, trello, git wydziałowy, github)
   8. obowiązkowe dokumenty: wizja, wymagania (wg szablonów w folderze)
      
   9. w ramach PRI/1 musi powstać działająca aplikacja
      niekoniecznie wszystkie funkcjonalności; może(?) być niedostępna dla komisji
   10. w ramach PRI/2 wytwarza się produkt, użyteczny dla klienta, działający, nietrywialny;
       przykładowo, komisja NIE akceptuje samego backend!!!
       
   11. nagradzane są: "prawdziwy" klient/ użytkownik, wdrożenie, testy wielu typów, ...
       czym jest "wdrożenie"? sklep, web app dostępna publicznie
   12. co zrobić w razie problemów w grupie ?
       PRI/1: osoba z rozbitej grupy może stać się podwykonawcą w innej grupie,
       PRI/2: w razie rozbicia grupy i tak każda osoba musi stworzyć produkt (def jak wyżej),
       PRI/2 vs studia mgr: praktycznie trzeba obronić projekt w 1 terminie aby zdążyć na studia mgr!!
3. PRI/1 - Ramowy harmonogram:
   1. wybór projektu, ustalenie grup, wybranie cyklu życia/ metody (np. SCRUM),
      oraz narzędzi wspierających (np. jira + github),
      Proszę przysłać w mailu (subject: ZPRI "krótka nazwa prj") następujące dane:
      1. wybrany temat projektu + krótki opis
      2. lista osób w grupie projektowej (imię nazwisko, nr indeksu, adres e-mail, kto jest liderem(?))
      3. link do dysku chmurowego z dokumentami ("Wizja", "Wymagania", pozostałe dokumenty)
      4. link do "listy zadań" (jira, trello, arkusz(?), ...)
      5. link do repozytorium kodu (git "wydziałowy", github, ...)
   2. stworzenie dokumentu "wizja", ostateczny termin: 17.03.2024
      oraz dokumentu "wymagania", ostateczny termin: koniec kwietnia
      szablony dokumentów są w tym folderze 2024; stare przykłady znajdziemy tutaj
   3. stworzenie dokumentu Duże Przyrosty
      powinien zawierać listą funkcjonalności wysokiego poziomu,
      podzieloną na 4 części: I, II duży przyrost (1 sem), III, IV duży przyrost (2 sem)
      plik powinien się nazywać /nazwa prj/_duze_przyrosty.txt i powinien być tam gdzie wizja i wymagania
      ten plik będzie oczywiście aktualizowany w czasie trwania obu semestrów ("zarządzanie zakresem")
      można tu wpisać także takie rzeczy jak tworzenie dokumentów i przeprowadzanie testów...
   4. I duży przyrost, implementacja kilku wymagań, termin: 21.04.2024 (stacjonarnie)
      
   5. II duży przyrost, działająca aplikacja/produkt
   6. akceptacja projektu przez prowadzącego
   7. próba generalna wystąpienia przed komisją, termin: 9.06.2024, 20:00 (teamsy)
   8. obrona projektu przed komisją, termin: 16.06.2024 (stacjonarnie)
4. PRI/2 - Ramowy harmonogram:
   1. III duży przyrost, termin: ???
   2. IV duży przyrost, termin: ???
   3. akceptacja projektu przez prowadzącego
   4. próba generalna wystąpienia przed komisją, termin: ???
   5. obrona projektu przed komisją, termin: 18.01.2025 (stacjonarnie)
5. PRI/1 - Dokumenty:
   • obowiązkowe dokumenty to "wizja" i "wymagania" wg szablonów (patrz wyżej)
   • wymagania funkcjonalne/niefunkcjonalne i/lub przypadki użycia
     tu ma być opisane "co" system robi (NIE jak to robi)
     to musi być precyzyjny opis! (tak aby dało się zweryfikować czy app spełnia wymagania);
     najważniejszym elementem jest "spis funkcjonalności"
     z podziałem na 2 semestry i na 2 duże przyrosty w każdym semestrze
   • architektura systemu (części systemu i relacje między nimi)
     tu ma być opisane jak system działa (zarys); najlepiej rysunek + opis
   • role uczestników grupy w projekcie
     za jakie składniki systemu odpowiadają uczestnicy grupy
     (wszyscy muszą mieć funkcje "programistyczne"!!)
   • projekty interfejsu użytkownika (UI)
     np. rozrysować strony www app webowej, okna dialogowe, itp, ...; figma ??
   • projekt bazy danych
     np. diagramy ER ?
   • przypadki testowe (raporty z testów)
     co przetestowano, kto i kiedy to zrobił, jakie efekty, jakie wnioski wyciągnięto
   • instrukcja dla użytkowników systemu
   • dokumentacja programistyczna
     np. opisy bibliotek, klas, plików, itp, ...
6. Różne wskazówki:
   • trzeba tworzyć dokumenty wymagane przez wybraną "metodykę" pracy nad prj,
     i należy się nimi pochwalić podczas obrony przed komisją...
     metodyki: SCRUM, RUP, Fortnight Milestones
   • prymitywna "metoda": iteracje + przyrosty
     powtarzać: analiza, projektowanie, implementacja (powstaje aplikacja), testowanie
   • warto TESTOWAĆ !!!
     możliwie dużo wszelkiego typu testów!! testy jednostkowe, testy użyteczności -1-, -2-, ...
   • kod źródłowy trzymać na github-ie lub podobnym narzędziu kontroli wersji,
     pamiętać o regularnych "comitach", te statystyki są brane pod uwagę przy obronie
   • warto pomyśleć o "sensie biznesowym"
   • warto mieć "prawdziwego użytkownika/klienta"
   • kiedy rozmawiać z "prawdziwym użytkownikiem"?
     odp: przy spisywaniu wymagań (ankiety?), po zbudowaniu każdego prototypu
   • warto porównać z istniejącymi, podobnymi rozwiązaniami (analiza rynku !)
     i wskazać "wartość dodaną" naszego projektu
   • warto porównać projekt z projektami innych grup, także u innych prowadzących...
   • w czasie obrony każda osoba musi umieć dokładnie opisać swoją rolę w projekcie,
     powiedzieć ile czasu jej to zajęło, ile linii kodu zostało napisanych ręcznie, wskazać ten kod itp
7. Organizacja grupy (niezależnie od przyjętej metody pracy):
   • lider - kierownik, sędzia, "kadrowy", koresponduje z MH,
     być może wpisuje zadania do "listy zadań" (??)
   • najlepiej jeśli każda osoba w projekcie jest odpowiedzialna za jeden niezależny "komponent";
     jeśli osoba X jest odpowiedzialna za komponent Y, i wykonanie Y się opóźnia,
     to wtedy należy szybko reagować...
     np. jest możliwe usunięcie osoby X z grupy na wniosek lidera grupy,
     oczywiście wcześniej trzeba się starać skłonić osobę X do wykonania jej pracy...
8. Co robimy na każdych zajęciach?:
   • prowadzący (MH) musi mieć dostęp do listy zadań (np. w programie jira),
     pozycja listy powinna zawierać min te info: Zadanie, Osoba, Data rozp, Data zakon,
     może być podział zadań na kamienie milowe/sprinty
   • prowadzący ma dostęp do git-a i kontroluje regularność komitów!!
   • grupa powinna się spotykać REGULARNIE,
     ustalać i przydzielać nowe zadania,
     sprawdzać realizacje starych zadań,
     (w zgodzie z wybrana metodą pracy nad projektem...)
     
   • grupa powinna "zarządzać zakresem" czyli modyfikować plik "duże przyrosty"
     za wiedzą prowadzącego...

Lista projektów zaproponowanych przez MH:

• są tematy zaproponowane przez "zewnętrzne firmy" !! folder 2024
• można zaproponować własny temat projektu !
• PRJ 1. Sprawozdania z zajęć - obsługa
  1. studenci wysyłają sprawozdania z "tematów", tak jak na tym portalu, patrz ALR, SIK;
  tematy składają się z wielu zadań opisanych na stronach wiki
  1.1. sprawozdania maja zdefiniowany format! patrz tutaj
  posiadają "metryczkę xml" z zadeklarowanymi zadaniami/pkt + same zadania z nagłówkiem
  przy wprowadzaniu sprawozdania ten format powinien być sprawdzany !!!
  2. powinien być "antyplagiat", tzn sprawdzanie czy 2 osoby wysłały prawie to samo sprawozdanie,
  system może zasugerować nauczycielowi, że coś jest nie tak...
  powinno się brać pod uwagę także archiwalne sprawozdania (z poprzednich lat)
  3. zadania "nowego typu" których rozw. studenci dostarczają w bardziej sformalizowany sposób
  np. poprzez jakieś formularze?
  3.1. może to być test wyboru, sprawdzania słów kluczowych w odpowiedzi, itp
  3.2. można także wprowadzić coś w rodzaju "sprawdzarki" znanej z konkursów programistycznych,
  tzn student podaje kod programu, a system sprawdza czy ten kod działa prawidłowo,
  różne wersje językowe powyższego modułu ?!?!
  4. możliwość łatwego podpięcia systemu pod istniejące strony zajęciowe wiki w tym portalu
  5. powinna istnieć lista z wynikami sprawozdań dostępna dla prowadzącego
  wypełniana częściowo ręcznie, częściowo automatycznie (?)
  5.1. dla zadań nowego typu powinna być możliwość ich wprowadzania przez prowadzącego przedmiot,
  a potem podpięcia pod strony wiki
  6. inne pomysły:
  6.1. pula zadań, każdy student dostaje inne zadania nowego typu wylosowane z tej puli
  6.2. połączenie z USOS np. w celu sprawdzenia danych w metryczce
  7. łatwość instalacji wszystkiego i podpinanai pod moje strony wiki
  
• PRJ 2. Rezerwacja sal (już było!)
  1. z uwzględnieniem planu zajęć z USOS-a
  2. grupy użytkowników zapisują się na "wydarzenie" (np. egzamin)
  2.1. druga możliwość to że grupę definiuje twórca wydarzenia
  3. przydziela się do wydarzenia salę/termin tak aby wszystkim uczestnikom grupy "pasował"
  4. system proponuje sale/terminy pasujące grupie
  5. istnieje także uproszczony mechanizm rezerwowania sal (bez grupy)
  
• PRJ 3. Wykłady webowe
  1. studenci i wykładowca otwierają stronę www z treścią wykładu,
  jest zapewnione "synchroniczne skrolowanie przeglądarek",
  tzn nauczyciel skroluje, a studenci widzą ten sam fragment strony co on...
  2. rozważyć możliwość stworzenia specjalnej strony www, w której widać inne strony (czy to lepszy pomysł??)
  3. dodać transmisję głosu od wykładowcy do studentów
  4. "ułatwienia" dla studentów: np możliwość prywatnej komunikacji z wykładowcą
  tzn. studenci zadają pytania przez czat tekstowy
  5. "ułatwienia" dla wykładowcy: kontrola osób uczestniczących w wykładzie
  np. wie gdzie siedzą w sali, poza salą; może im wysłać jakiś przykład itp
  6. standardowe strony www wymagają tylko "drobnej wstawki" aby działać w tym systemie
  7. zaznaczanie fragm. tekstu w przeglądarce przez prowadzącego widoczne u studentów,
  albo jakiś znacznik doczepiany do miejsca w tekście??
  8. osobno zrobić obsługę slajdów pdf
  9. czym to się różni od zdalnego desktopu??? przemyśleć...
  10. zastosowane rozwiązanie powinno być możliwie "nieinwazyje" (bez ingerencji po stronie ser. www)
  11. powinno działać na starym sprzęcie i starych przeglądarkach (nie wymaga upgrade)
  
• PRJ 4. Rozproszona tablica do pracy nad projektem
  1. wyobraźmy sobie że grupa ludzi dyskutuje przy tablicy nad jakims projektem
  (np. chodzi o dowód tw. matematycznego) i mamy umożliwić im zdalną pracę...
  2. w zasadzie chodzi o: czat tekstowy i tablicę do rysowania z obsługą wzorów matemat
  2.1. w przyszłości (2 semestr?) można dodać kontakt głosowy
  3. wymagana jest łatwość instalacji kli/ser (serwer na linux-ie!)
  4. oprogramowanie klienckie musi być na wszystkie możliwe platformy: windows/linux, web (?), tablety, ...
  5. czym to się różni od "google docs"? musi byc jakaś istotna różnica, przemyśleć, ...
  6. wyspecjalizowane rysunki? np. operacje na grafach dla teoretyków grafowych?
  6.1. możliwość wpisywania wzorów matematycznych w latex-u, które są widoczne jako obrazki
  
• PRJ 5. Mapa lepsza niż Google Maps
  1. powinna działać także na smartfonach i tabletach
  2. możliwość ręcznego wyznaczania/modyfikowania trasy
  3. wszystkie funkcje znane z Google Maps
  4. powinna działać także bez internetu
  5. powinna używać GPS (zapamiętywanie trasy, nawigacja)
  6. oprzeć się na OpenStreetMap
  7. przemyśleć, czy jesteśmy w stanie zrobić coś, co przewyższa google maps ?!?!
  8. MAŁE wymagania sprzętowe (w przeciwieństwie do androidowej app google maps)
  
• PRI 6. Zamiana slajdów na filmy
  1. darmowy odpowiednik programu Camtasia ?
  2. musi być przenośny (linux, windows, ?), zwłaszcza linux, bo brakuje takiego oprogramowania!!
  3. możliwość nagrywania głosu oraz animacji kursora myszy dla każdego slajdu osobno
  3.1. możliwość edycji powyższego...
  4. wymyślić lepszą nazwę dla tego projektu
  5. możliwość rysowania na slajdach (+ edycja)