Katedra Oprogramowania
Wydział Informatyki PB
Inżynieria oprogramowania II
Pracownia specjalistyczna
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. 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 | Faza rozwinięcia: rozpoznawanie wymagań (wyszukanie aktorów, opracowanie modelu przypadków użycia, opracowanie wymagań niefunkcjonalnych), analiza ryzyka |
4 (L) | Laboratorium:
narzędzia zarządzania zmianami kodu (CVS, Subversion, MS SourceSafe) |
5 | Faza rozwinięcia: definiowanie architektury (architektura systemu, realizacja przypadków użycia, klasy analizy), zarządzanie zmianami (przykładowe narzędzia - aplikacje klienckie CVS: TortoiseCVS, WinCVS/gCVS, aplikacje klienckie SVN: TortoiseSVN) |
6 | Faza rozwinięcia: rozwijanie projektu (klasy i model projektowy), dokumetowanie kodu: javadoc, doxygen |
7 | Faza budowy: Iteracja I (opracowanie planów integracji, planów testów, implementacja komponentów podstawowej funkcjonalności, implementacja komponentów testowych, testowanie jednostkowe) |
8 (L) | Laboratorium:
narzędzia dynamicznego testowania kodu |
9 | Faza budowy: Iteracja II (usuwanie defektów, implementacja pozostałych komponentów ) |
10 (L) | Laboratorium:
narzędzia profilowania aplikacji |
11 | Faza budowy: Iteracja II (integracja systemu, testowanie systemu, usuwanie defektów, przeglądy kodu) |
12 (L) | Laboratorium: tworzenie
instalatorów |
13 | Faza przekazania: opracowanie dokumentacji administracyjnej i użytkownika, instalacja systemu, testowanie akceptacyjne, wdrożenie |
14 | Prezentacja stworzonego systemu i przekazanie wszystkich stworzonych elementów do oceny |
15 | Obrona systemów i ocena wkładu poszczególnych członków zespołu |
Szablony dokumentów:
Wizja (wizja.zip 80 KB)
Słownik (slownik.zip 88 KB)
Plany pracy (plan.zip 140 KB)
Specyfikacja przypadków użycia (spu.zip 120 KB)
Specyfikacja wymagań (srs.zip 92 KB)
Specyfikacja dodatkowa (ss.zip 97 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:
projektu, czyli:
- 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.
referatów przygotowywanych indywidualnie (dla
zainteresowanych):
- dodatkowe 2 punkty do wyniku 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: IO2, rok akademicki, semestr, rodzaj studiów, nazwiska
studentów
(np. IO2, 2004/05, VII, dzienne 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.
Przykładowe tematy referatów:
COCOMO2
Refaktoring oprogramowania
Prezentacja oprogramowania (narzędzia IBM Rational, MS
Visio, ...)
Istota programowania kontraktowego (język Eiffel)
...
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 |
Copyright © 2005-9 Marek Krętowski, Tomasz Łukaszuk, Marek Grześ,
Krzysztof Jurczuk, Marcin Czajkowski.
Revised: 2009-10-05