Wikia

IO Wiki

Dokument wizji

Dyskusja0
9stron na
tej wiki

Wersja RAW dokumentu wizji

Historia edycji

DOKUMENT WIZJI

wg. Leffing D., Widring D., Zarządzanie wymaganiami WNT 2003, str. 195

1. WprowadzenieEdytuj

Ogólny opis całego dokumentu wizji

1.1. Cel dokumentu wizjiEdytuj

W dokumencie są, zebrane, zdefiniowane i analizowane ogólne potrzeby użytkownika oraz cechy produktu

1.2. Ogólny opis produktuEdytuj

Cel aplikacji, jego wersje, nowe dostarczone cechy

1.3. OdniesieniaEdytuj

Pełna lista dokumentów, do których występują odwołania w dokumencie wizji

2. Opis użytkownikaEdytuj

Krótki opis użytkownika i jego punktu widzenia na system

2.1. Dane statystyczne dot. użytkowników i rynkuEdytuj

2.2. Opis użytkownikówEdytuj

2.3. Środowisko użytkownikówEdytuj

2.4. Podstawowe potrzeby użytkownikaEdytuj

2.5. Rozwiązania alternatywne i konkurencyjneEdytuj

3. Ogólny opis produktu Edytuj

Aplikacja ma na celu umożliwienie użytkownikowi wykonanie czynności związanych z układaniem planu zajęć. Dostęp do aplikacji będzie się odbywał poprzez Internet za pomocą przeglądarki internetowej. Użytkownik-pracownik będzie mógł wprowadzić do systemu propozycje przedmiotów, sprawdzić wyniki głosowania oraz skontaktować się ze studentami zapisanymi na jego przedmioty. Użytkownik-student będzie mógł głosować na przedmioty zaproponowane przez pracowników, zapisywać się na przedmioty wybrane do realizacji oraz oceniać przedmioty na które uczęszczał. Użytkownik-pracownik dydaktyczny będzie miał możliwość nadzorowania wszystkich etapów i będzie mógł wprowadzać ręczne poprawki.

3.1. Schemat produktuEdytuj

Aplikacja będzie podzielona na współpracujące ze sobą moduły. Moduły będą ze sobą powiązanie z ten sposób, że wyniki uzyskane i zebrane przez dany moduł będą danymi wejściowymi dla następnego modułu.

Lista modułów:

  • Propozycje przedmiotów
  • Głosowanie na przedmioty
  • Układadnie planów
  • Dopasowywanie planów (przez system)
  • System kolejkowania
  • Ocena zajęć

3.2. Określenie pozycji produktu na rynkuEdytuj

Serwis przeznaczony jest dla Studentów i Pracowników Instytutu Informatyki Uniwersytetu Wrocławskiego. Celem projektu jest stworzenie systemu wygodniejszego od systemu używanego do tej pory. Dodatkowo chcemy, aby z systemem zapisów zintegrowane były inne aplikacje (np. Ocena zajęć). Dzięki temu użytkownicy będą mieli dostęp do większej liczby informacji podczas podejmowania decyzji.

3.3. Podsumowanie możliwościEdytuj

Opis formatu:

  • Możliwość
    • Lista cech, które ją realizują
  • Student nie musi być dostępny przy komputerze o (z jego punktu widzenia) losowej porze, może uzupełnić swoje preferencje o dowolnej porze w ustalonym okresie (trwającym około 2 tygodnie)
    • Możliwość układania alternatywnych planów
  • Student nie musi odwiedzać wiele razy dziennie serwisu, żeby sprawdzić czy zwolniły się miejsca w grupie, która go interesuje
    • Kolejkowanie
  • Student może sprawdzić jaką wiedzą powienien dysponować przed zapisaniem się na dany przedmiot oraz na jakich przedmiotach zdobywa się tę wiedzę.
    • Propozycje przedmiotów (perspektywa wykładowcy), głosowanie (perspektywa studentów)
  • Dyrektor do spraw dydaktycznych ma wgląd do danych liczbowych takich jak liczba studentów oczekujących na zwolnienie się miejsca z danego przedmiotu i może na to odpowiednio reagować (np. otwierająć nowe grupy, zwiększająć limity).
    • Panel sterowania dla administatora systemu


3.4. Założenia i zależnościEdytuj

Zakładamy, że w danym roku akademickim z aplikacji będzie korzystać około 600 studentów.

3.5. Koszty i cenyEdytuj

4. Cechy produktu Edytuj

4.1 Zgłaszanie propozycji przedmiotów, które mają być poddane głosowaniuEdytuj

Pracownicy będą mogli zgłaszać propozycje przedmiotów, które chcieliby poprowadzić w przyszłym roku akademickim. Do informacji podawanych podczas zgłoszenia należą: nazwa przedmiotu, typ przedmiotu, poziom zaawansowania, wymagania wstępne, wstępny program zajęć, literatura.

4.2. Głosowanie na przedmioty Edytuj

Studenci będą mogli przeczytać informacje o przedmiotach zaproponowanych przez pracowników i następnie będą mogli wyrazić swoje zainteresowanie danym przedmiotem. Dzięki temu Dyrektor dydaktyczny będzie widział, które przedmioty cieszą się dużym zainteresowaniem (i znajdzie prowadzących dla wielu grup); które warto zorganizować, bo uzbiera się pełna grupa; które będą świecić pustkami.

4.3 Edytor planówEdytuj

Studenci będą mieli do dyspozycji graficzny edytor planów, którym pozwoli im w wygodny sposób wypróbować wiele możliwości. Przykładowo: w edytorze widoczne będzie, że zajęcia w ramach kilku przedmiotów na siebie zachodzą.

4.4 Dopasowywanie planówEdytuj

Gdy minie termin na tworzenie planów indywidualnych, uruchomiony będzie modul dopasowywujący plany. Jego zadaniem będzie przeglądać plany stworzone przez studentów (w kolejności malejących priorytetów) i zachłanne znajdowanie planu, który jest realizowalny (są wolne miejsca).

4.5 KolejkowanieEdytuj

4.6 Ocena zajęćEdytuj

5. Atrybuty cechEdytuj

Opis atrybutówEdytuj

Status – Ustalony po negocjacjach i przeglądzie dokonanym przez zespół programistów. Informacje statusu umożliwiają śledzenie postepu podczas definiowania linii bazowej przedsiewziecia.

Priorytet – Priorytet wprowadzenia do projektu danej cechy.

Ryzyko – Ustalane przez zespół programistów, na podstawie pradopodobieństwa, że w przedsięwzięciu wystąpią niepożądane zdarzenia typu przekroczenie kosztów,opóznienie planu lub anulowanie.

Stabilność – Ustalana przez analityka i zespół programistów, na podstawie prawdopodobieństwa, że zmieni się cecha lub zmieni się rozumienie cechy przez czlonków zespołu programistów. Ta informacja jest stosowana, aby pomóc ustalic priorytety tworzenia oprogramowania oraz określić te pozycje, dla których dodatkowe uzyskanie wymagań jest nastepnym własciwym zadaniem.

Wersja docelowa – Rejestrowana jest planowana wersja produktu, w której cecha pojawi się po raz pierwszy. To pole może byc użyte do przydzielenia cech poszczególnej wersji linii bazowej. Kiedy wersja docelowa jest połączona z polem statusu, zespól może proponować, zapisywać i omawiać różne cechy wersji bez zobowiazania do ich zapewnienia. Implementowane będą tylko te cechy, których status jest ustalony jako „wprowadzona” i dla których zdefiniowana jest wersja docelowa.

Zestawienie atrybutów cechEdytuj

4.1 Zgłaszanie propozycji przedmiotów, które mają być poddane głosowaniuEdytuj

Status: Proponowane

Priorytet: Przydatne

Ryzyko: Niskie

Stabilność: Wysoka

Wersja docelowa: beta

4.2 Głosowanie na przedmiotyEdytuj

Status: Proponowane

Priorytet: Przydatne

Ryzyko: Niskie

Stabilność: Średnia

Wersja docelowa: beta

4.3 Edytor planówEdytuj

Status: Zatwierdzone

Priorytet: Konieczne

Ryzyko: Duże

Stabilność: Niska

Wersja docelowa: alfa

4.4 Dopasowywanie planówEdytuj

Status: Zatwierdzone

Priorytet: Konieczne

Ryzyko: Średnie

Stabilność: Niska

Wersja docelowa: prototyp

4.5 KolejkowanieEdytuj

Status: Zatwierdzone

Priorytet: Ważne

Ryzyko: Średnie

Stabilność: Niska

Wersja docelowa: prototyp

4.6 Ocena zajęćEdytuj

Status: Proponowane

Priorytet: Przydatne

Ryzyko: Niskie

Stabilność: Pewna

Wersja docelowa: beta

6. Podstawowe przypadki użyciaEdytuj

  • Kształtowanie oferty :


    • Podawanie przedmiotów pod głosowanie

Użytkownik-pracownik może dodawać przedmioty. Każdy przedmiot powinien mieć opis, wymagania wstępne, liczbę punktów ECTS itp.


    • Głosowanie na przedmioty

Użytkownik-student może oddawać głosy na przedmioty zaproponowane przez użytkowników-pracowników. Liczba przedmiotów na które można zagłosować jest ograniczona.

Podawanie przedmiotów pod głosowanie powinno zasadniczo być zakończone.

  • Układanie indywidualnego planu zajęć

Użytkownik-student układa zero lub więcej planów. System będzie próbował wybrać plan o najwyższym priorytecie. Do każdego planu można dodać listę grup do których system będzie zapisywał opcjonalnie.

  • Korygowanie indywidualnego planu zajęć

Wypisywanie się z zajęć, zapisywanie się do list oczekujący na zajęcia.

  • Ocena zajęć

Ocena zajęć, na które użytkownik-student był zapisany w poprzednim semestrze.

7. Inne wymagania produktuEdytuj

7.1 Spełniane normyEdytuj

Produkt ma spełniać normy organizacji W3C, to jest kod strony zgodny z XHTML1.0, arkusze stylów zgodne z CSS 2.0. Interfejs graficzny ma być intuicyjnie, względnie podobny do istniejącego w chwili obecnej Systemu Zapisów na Instytucie Informatyki Uniwersytetu Wrocławskiego.

7.2 Wymagania stawiane systemowiEdytuj

System ma być w stanie obsłużyć jednocześnie 1000 studentów w wersji podstawowej. Interfejs musi być wystarczająco intuicyjny, żeby obyty z internetem użytkownik-student był w stanie opanować jego obsługę w ciągu dwóch minut.

7.3 Licencjonowanie i instalacjaEdytuj

System będzie wymagał niezależnego zainstalowania serwera baz danych, serwera WWW, interpretera języka Python wraz ze ściśle określonym zestawem bibliotek. Instalacja produktu będzie polegała utworzeniu odpowiedniego katalogu, rozpakowaniu w tym katalogu archiwum z plikami programu oraz edycji plików konfiguracyjnych w celu przekazania systemowi danych niezbędnych do pracy z zewnętrznymi aplikacjami.

System rozpowszechniany wraz z kodem źródłowym. Licencja będzie udzielana dożywotnio, na jedną maszynę, z możliwością dowolnej modyfikacji kodu, bez możliwości odsprzedaży czy przekazania żadnej jego części.

7.4 Wymagania efektywnościoweEdytuj

Szybkość działania powinna pozostać na poziomie akceptowanym przez przeciętnego użytkownika, tj. odpowiedź serwera na dowolne zapytanie użytkownika nie powinna trwać więcej niż sekundę. Na większość zapytań system powinien odpowiadać "od razu".

8. Wymagania dokumentacyjneEdytuj

8.1 Wymagania dokumentacyjneEdytuj

Dokumentacja w formie podręczników dla użytkownika. Dodatkowo czytelnie sformatowany i udokumentowany zgodnie z konwencją kod w języku Python.

8.2 Pomoc on lineEdytuj

Nie przewidziana. Ewentualnie w formie osobnej usługi.

8.3 Porady dotyczące instalacji, konfiguracji oraz plików informacyjnychEdytuj

Dokumentacja? Co to są pliki informacyjne?

8.4 Oznaczenia i pakowanieEdytuj

???

9. SłownikEdytuj

[Wojtek] Proponuję wprowadzić następujące terminy: Użytkownik-student, użytkownik-pracownik, użytkownik-dyrektor do spraw dydaktycznych

[Marek] Oferta dydaktyczna - zamiast plan globalny

plan zajęć - zamiast indywidualny plan

zamiast użytkownik-ddsd proponuję "użytkownik-administrator"

Więcej od Wikii

Losowa wiki