(studia niestacjonarne, uzupełniające)
Celem zajęć jest praktyczne zweryfikowanie wiedzy dotyczącej procesu wytwarzania oprogramowania oraz zapoznanie się z narzędziami wspomagającymi proces wytwórczy. Studenci pracując w grupach mają za zadanie stworzenie (i w miarę możliwości rzeczywiste wdrożenie) funkcjonującej aplikacji. Modelowanie i projektowanie przy wykorzystaniu UML, natomiast aplikacja wykonana w technologii obiektowej z zastosowaniem dostępnych API. Zarządzanie zmianami kodu źródłowego z wykorzystaniem SVN. Praca odbywa się w grupach 3-4-osobowych.
|
Nr |
Temat zajęć |
| 1 |
Przedstawienie wymagań i sposobu prowadzenia zajęć, utworzenie zespołów, wybranie kierowników, uzgadnianie tematyki zadania projektowego (tematy projektów) |
| 2 |
Faza inicjacji: wstępne rozpoznawanie wymagań (wizja, słownik), opracowywanie planów pracy |
| 3 (L) |
Laboratorium: narzędzia zarządzania zmianami kodu |
| 4 |
Faza rozwinięcia: rozpoznawanie wymagań (wyszukanie aktorów, opracowanie modelu przypadków użycia, opracowanie wymagań niefunkcjonalnych), analiza ryzyka, definiowanie architektury (architektura systemu, realizacja przypadków użycia, klasy analizy); |
| 5 |
Faza budowy: Iteracja I (opracowanie planów integracji, planów testów, implementacja komponentów podstawowej funkcjonalności, implementacja komponentów testowych, testowanie jednostkowe) |
| 6 (L) |
Laboratorium: narzędzia dynamicznego testowania kodu i profilowania aplikacji |
| 7 |
Faza budowy: Iteracja II (usuwanie defektów, implementacja pozostałych komponentów), (integracja systemu, testowanie systemu, usuwanie defektów, przeglądy kodu, tworzenie instalatorów) |
| 8 |
Faza przekazania: opracowanie dokumentacji administracyjnej i użytkownika, instalacja systemu, testowanie akceptacyjne, wdrożenie |
Szablony dokumentów:
Wizja (wizja.zip 80 KB)
Słownik (slownik.zip 88 KB)
Plany pracy (plan.zip 140 KB)
Specyfikacja wymagań (srs_adv.zip 145 KB)
Architektura systemu (arch.zip 113 KB)
Model implementacji (imp.zip 104 KB)
Plan testów (test.zip 224 KB)
strona tytułowa do dokumentów (tytul.zip 77KB)
Sposób zaliczenia pracowni specjalistycznej:
Ocena końcowa jest wyliczana na podstawie:
– zdobyczy punktowej z projektu (od 0 do 20 punktów),
– terminowości pracy:
– terminy cząstkowe (TC): każdy tydzień opóźnienia to strata 0.5 punkta,
– termin końcowy (TK): każdy tydzień opóźnienia strata 2.5 punkta),
– podziału pracy w ramach zespołu,
– obrony projektu.
Przygotowanie materiałów przekazywanych do oceny:
1. Dokumentacja projektu w formie papierowej (sprawdzona ortografia, wydruk dwustronny, …)
2. Płytka CD zawierająca następujące katalogi:
– doc/src – źródła dokumentacji (rysunki, diagramy, …)
– doc/screenshots – zrzuty ekranu programu
– doc – pliki dokumentacji (projekt, podręczniki instalacji, użytkownika etc.)
– src – źródło oprogramowania, po ściągnięciu z repozytorium
– svn/svn – repozytorium svn z zeus’a
– svn/log – logi wygenerowane przez statsvn
– bin/noinst – binarna wersja oprogramowania bez instalatora (ale z opisem jak uruchomia)
– bin/inst – binarna wersja oprogramowania z instalatorem
– lib – dodatkowe biblioteki używane w projekcie (o ile wykorzystywane)
– lib/doc – dokumentacje używanych bibliotek
– lib/src – kod źródłowy używanych bibliotek
– lib/bin – wersje binarne używanych bibliotek
– data – przykładowe dane wejściowe (jeżeli takie są potrzebne)
– examples – przykładowe wyniki działania programu (np. wygenerowane krzyżówki)
– tools – oprogramowanie używane do stworzenia projektu lub potrzebne do uruchomienia stworzonego oprogramowania
(np. maszyna wirtualna javy, baza danych, eclipse w wersji używanej do stworzenia projektu, etc.)
oraz
– index.html – plik HTML uruchamiany przez autorun, z odwołaniami do poszczególnych elementów na płycie (do logów statcvs również, zrzutów ekranu, etc.) oraz z metryczką projektową (rok akademicki, semestr i rodzaj studiów, przedmiot, nazwa projektu, autorzy, podział pracy, proponowana ocena etc.). Należy zadbać, aby również ta strona wyglądała przyzwoicie, gdyż w przypadku potencjalnej szerszej prezentacji projektu (jako wzorca do naśladowania albo unikania) będzie to wizytówka autorów projektu;
– doc/javadoc/html/index.html lub doc/doxygen/html/index.html – dokumentacja kodu źródłowego w formacie html.
Wszystkie pliki dokumentacji w formacie edytora w którym zostały stworzone (doc, sxw, …) i w formacie pdf
Płytka podpisana następująco: ZIO, rok akademicki, semestr, rodzaj studiów, nazwiska studentów
(np. ZIO, 2008/09, II, niestacjonarne, mgr., Adamski, Kowalski, Nowak)
Ze względów praktycznych na jednej płycie CD może być umieszczonych kilka projektów, przy czym każdy z nich powinien znajdować się w oddzielnej strukturze katalogów z dostępem przez plik index.html z katalogu głównego.
Przeliczenie punktów na oceny jest następujące:
| Punkty | 20.0-18.0 | 17.75 – 16.0 | 15.75 – 14.0 | 13.75 – 18.0 | 11.75 – 10.0 |
| Ocena | 5,0 | 4,5 | 4,0 | 3,5 | 3,0 |