Skip to main content

Zasady zaliczenia przedmiotu Systemy / Przetwarzanie Odporne na Błędy - Projekt

mgr inż. Michał Młodawski
Katedra Systemów Informatycznych PŚk


Zasady zaliczenia

  1. Obecność na zajęciach projektowych jest obowiązkowa.

  2. Od studenta oczekuje się pracy nad projektem przez cały semestr i systematyczne przedstawianie postępów na zajęciach projektowych prowadzącemu na „kamieniach milowych".

  3. Oceniane będą następujące elementy:

    • Sprawozdanie oraz dokumentacja projektowa
    • Działanie programu i spełnienie założeń projektowych
    • Znajomość projektu oraz opracowanego zagadnienia
    • Zaliczenie etapów zwanymi „kamieniami milowymi"
  4. Zasady zaliczenia „kamieni milowych": Zespół projektowy co określony przez prowadzącego czas musi przedstawić wyniki swojej pracy poprzez prezentacje aktualnych postępów i przygotowania sprawozdania z dotychczasowej pracy. W przypadku braku zaliczenia danego kamienia milowego zespół projektowy uzyskuje 30 punktów ujemnych do wyniku końcowego. Niezaliczenie dwóch z czterech kamieni milowych oznacza uzyskanie oceny niedostatecznej w pierwszym terminie.

  5. Terminy kamieni milowych i zakres prac na poszczególne kamienie milowe zostaje ustalone na pierwszych zajęciach projektowych.

  6. Łączna liczba punktów sumuje się do 100. Ocena końcowa zależna jest od łącznej liczby uzyskanych punktów:

    • 0–49 punktów - 2,0 (niedostateczny)
    • 50–59 punktów - 3,0 (dostateczny)
    • 60–69 punktów - 3,5 (dostateczny plus)
    • 70–79 punktów - 4,0 (dobry)
    • 80–89 punktów - 4,5 (dobry plus)
    • 90–100 punktów - 5,0 (bardzo dobry)
  7. W razie wykrycia plagiatu praca zostanie oceniona na zero punktów bez możliwości poprawy.

  8. Student przed rozpoczęciem kursu ma obowiązek zapoznać się z instrukcją BHP obowiązującą w laboratorium i poświadczyć w sposób podanym przez prowadzącego.

  9. Dopuszczalne jest odstąpienie od niniejszych reguł w uzasadnionych przypadkach (zaświadczenia o niepełnosprawności, okres rekonwalescencji, itp.), tylko za obustronnym porozumieniem osób zainteresowanych i prowadzącego. Jednakowoż niedopuszczalne jest ograniczenie zakresu materiału, którego opanowanie w ramach zajęć określone jest w karcie przedmiotu.

  10. W sprawach nieuregulowanych niniejszymi zasadami zastosowanie mają ogólnie obowiązujące przepisy, w szczególności Regulamin Studiów i ogólnie przyjęte zasady.

Organizacja zajęć

  1. Wychodzenie z sali dozwolone jest tylko po zgłoszeniu prowadzącemu.

  2. W sali laboratoryjnej/ćwiczeniowej obowiązuje zakaz spożywania posiłków i napojów.

  3. Okrycia wierzchnie należy pozostawić w szatni.

  4. Plecaki czy torby należy umieścić w miejscu nie przeszkadzającym w chodzeniu.

  5. Podczas laboratorium należy zachować ciszę. Konwersację z innymi członkami zespołu należy prowadzić tak, aby nie zakłócić ciszy.

  6. Na każdych zajęciach sprawdzana jest lista obecności.

  7. Instrukcje umieszczane są pod adresem podanym przez prowadzącego.

  8. Literatura podstawowa i uzupełniająca podana jest w karcie przedmiotu.

Wymagania projektowe

  1. Projekt powinien wykorzystywać system kontroli wersji Git i być umieszczony w repozytorium, do którego prowadzący ma dostęp.

  2. Dopuszcza się wykorzystanie dowolnego języka programowania.

  3. Komunikacja powinna być oparta o TCP/IP lub pamięci dzielonej z wykorzystaniem semaforów lub innym rozwiązaniem umożliwiającym komunikację w czasie rzeczywistym pomiędzy elementami systemu.

  4. Każdy element systemu powinien działać jako osobny wątek, proces, program.

  5. Celem projektu jest wierne zasymulowanie działania algorytmu, a nie jego implementacja. Niedopuszczalne jest użycie gotowych bibliotek implementujących rozwiązanie lub jego część.

  6. Program powinien posiadać interfejs graficzny umożliwiający:

    • Monitorowanie pracy poszczególnych elementów systemu
    • Możliwość wprowadzania usterki i jej usuwania w poszczególnych elementach systemu
    • Możliwość wprowadzania nowych wartości do systemu
  7. Program powinien mieć funkcjonalność wstrzykiwania minimum 3 różnych rodzajów błędów do każdego elementu systemu, nawet do elementów, które nie tolerują danego rodzaju błędu.