Specyfikacja

 

Do końca trzeciego tygodnia zajęć studenci są zobowiązani do udostępnienia Prowadzącemu Zajęcia specyfikacji wybranego projektu. Specyfikacja jest oceniana na 0 - 5 punktów.

Specyfikacja powinna się składać z następujących sekcji:

  1. Opis projektu
  2. Model matematyczny (nieobowiązkowo, jeśli projekt nie ma podłoża fizycznego)
  3. Interfejs graficzny aplikacji
  4. Scenariusze użycia
  5. Wymagania dodatkowe
  6. Terminarz realizacji projektu
  7. Ocena oraz tabela zadań (obowiązkowo, bez tej sekcji prowadzący nie wystawi punktów za projekt).

To nie jest zamknięta lista możliwych sekcji. Jeśli chcieliby Państwo zamieścić diagramy UML, jasno wyszczególnić wymogi formalne, czy też dodać jakąś inną sekcję bezpośrednio wynikającą ze specyfiki waszego projektu, jak najbardziej zachęcamy do rozszerzenia tej listy. Nie ma jednak potrzeby zamieszczania rozwlekłych opisów: dokument ma być krótki, konkretny i ma jasno definiować Państwa pomysł na realizację projektu.

Szablon dla specyfikacji projektów z programowania obiektowego można znaleźć tutaj (Google Docs) lub tutaj (Office 365).

Szczegółowe informacje nt. każdej sekcji można znaleźć wewnątrz pliku szablonu, wraz z przykładami. Studenci są zobowiązani do wykonania kopii udostępnionego pliku, uzupełnienia wszystkich sekcji zgodnie z założeniami ich projektu oraz następnie udostępnienia Prowadzącemu Zajęcia tak przygotowanego dokumentu.

Specyfikacja zostaje zatwierdzona gdy prowadzący uzupełni Tabelę Zadań znajdującą się na końcu dokumentu,  oraz obie strony zaakceptują ostateczną punktację za zaplanowane funkcjonalności.

Specyfikacja może ulec zmianie w trakcie trwania semestru:

  • Dodatkowe funkcjonalności mogą zostać zasugerowane przez prowadzącego podczas oceny tabeli zadań.
  • Jeśli w trakcie rozwoju aplikacji okaże się, że nowe rozwiązania są lepsze niż założone na początku, za zgodą prowadzącego studenci mogą wprowadzić odpowiednie modyfikacje.
    • Np. Okaże się że podczas pracy nad projektem wymyślono lepsze rozwiązanie dotyczące interfejsu użytkownika, bądź któraś z funkcjonalności dodatkowej zostanie zastąpiona inną.
    • Takie zmiany powinny zostać wprowadzone w samej aplikacji ale również w specyfikacji projektu. 
  • W "komercyjnej rzeczywistości"  specyfikacje są właśnie żywymi tworami - zespół stara się jak najlepiej zdefiniować wszystkie cechy produktu na samym początku, ale jeśli w wyniku pracy nad projektem niezbędne jest wprowadzenie zmian, tych zmian nie należy się obawiać.

Przypominam, że tutaj znajduje się czytelna lista umiejętności jakie Państwo posiądziecie w trakcje zajęć, natomiast za użycie technik nie omawianych podczas zajęć (przykłady dodatkowych funkcjonalności tutaj) zawsze można uzyskać dodatkowe punkty.