2006/2007 zalecenia projektowe i ocenianie

Transkrypt

2006/2007 zalecenia projektowe i ocenianie
INŻYNIERIA OPROGRAMOWANIA – LABORATORIUM
/ćwiczenia w grupach dwuosobowych/
ZAJĘCIA
PROJEKTY
1
Organizacyjne i przygotowawcze. Szkolenie BHP.
Informacja o organizacji zajęć. Zapoznanie z narzędziem (np. zadanie, załącznik 1).
2
Specyfikacja wymagań w języku naturalnym – odrębny dokument lub jako 1 rozdział
projektu.
3
Diagram PU (Przypadków Użycia) z opisem w języku naturalnym PU. Ponadto dla
4
PU należy określić warunki początkowe i końcowe (jeśli nie ma – napisać „brak”).
TERMIN dostarczenia końcowej postaci specyfikacji i diagramu PU – zajęcia 5.
5
Diagram czynności dla dwóch współpracujących ze sobą PU (na studenta).
TERMIN oddania końcowej postaci diagramu czynności – zajęcia 6.
6
Diagram klas. Klasy powinny posiadać wstępnie zdefiniowane operacje oraz atrybuty
z definicją typu i ochroną (np. publiczny, prywatny).
7
TERMIN oddania końcowej postaci diagramu klas – zajęcia 8.
8
Diagramy sekwencji oraz automatyczna generacja diagramów współpracy. Na tym
etapie może nastąpić modyfikacja oraz uzupełnienie diagramu klas (np. nowe
9
operacja w klasach, a nawet nowe klasy).
10
TERMIN oddania końcowej postaci diagramu współpracy – zajęcia 11.
11
Diagram stanów w odniesieniu do klas (np. każdy student wybiera jedną klasę
w uzgodnieniu z prowadzącym i dla niej sporządza diagram klas).
12
TERMIN oddania końcowej postaci diagramu stanów – zajęcia 13.
13
Diagram stanów lub czynności wykorzystane do definiowania operacji.
TERMIN oddania końcowej postaci diagramu stanu lub czynności – zajęcia 14.
14
Termin dodatkowy, np. dla tych, którzy z przyczyn losowych (np. choroba) nie
uczestniczyli w określonych zajęciach.
15
Wpisy do indeksów i/lub prezentacja w grupach najciekawszych projektów.
ZASADY OCENIANIA:
• Ocena projektów etapowa: za każdy wymieniony etap ocena cząstkowa. Ocena
końcowa – jako średnia arytmetyczna.
Dodatkowo na ocenę z etapu (zarówno na „plus” jak i „minus” ) mogą mieć wpływ
oceny cząstkowe wystawiane w trakcie zajęć przez prowadzącego.
•
Ponieważ nieterminowa realizacja projektu w rzeczywistości wiąże się z „karami
umownymi”, za każdy tydzień opóźnienia w złożeniu dokumentacji etapu – obniżenie
oceny końcowej o ½ (z możliwością jednorazowego anulowania kary przez
prowadzącego).
UWAGI:
1) Dokumentację składa się w formie papierowej, nie później niż tydzień po zakończeniu
prac nad danym etapem. Forma taka jest konieczna, ze względu na to, iż wybrane
projekty (losowo) będą recenzowane przez innego prowadzącego – w świecie
rzeczywistym firmy również zasięgają opinii innych ekspertów np. w celu weryfikacji
jakości.
2) Na początku każdego etapu prac będą podane „listy kontrolne” (zawierające pytania,
którymi będą kierować się prowadzący podczas „inspekcji” i które powinny ułatwić
studentom weryfikację projektu przed złożeniem).
3) Zostanie założona strona WWW związana z laboratorium i zawierająca informacje
dotyczące projektów i narzędzi (informacje, jakie zacząłem umieszczać w ubiegłym
roku można znaleźć: http://www.equus.wroc.pl/studia.html).
INFORMACJE dla prowadzących:
1) Poprzednia strona Sanowi wersję roboczą. Jeśli nie będzie uwag, to zostanie
udostępniona studentom z tym, że w punkcie 4) zostanie podany już właściwy adres
strony WWW.
2) Na drugich zajęciach można pokazać i przeanalizować gotowe projekty – sądzę, iż
najlepszym rozwiązaniem byłoby opracować zestaw folii do wykorzystania przez
wszystkich prowadzących. Można w tym celu np. poprosić o zgodę prof. Huzara
o wykorzystanie jego materiałów – diagramy z raportu. Można również opracować
własny
przykład
lub
skorzystać
z
„helpów”
do
narzędzi
(z tym, że tam nie zawsze są „dobre” rozwiązania). Oczekuję jeszcze w tej kwestii na
uwagi.
3) BIBLIOGRAFIA:
[1] Internet –dokumentacja: www.uml.org; www.omg.org
[2] pod red. J. Górski, Inżynieria oprogramowania, MIKOM, Warszawa 2000, str. 116-154
[3] Z. Huzar, Wprowadzenie do języka UML, Politechnika Wrocławska, Raport PRE 24/99
[4] Michał Śmiałek, Zrozumieć UML 2.0, HELION, Gliwice 2005
[5] Martin Fowler, UML w kropelce, LTP Warszawa 2005
[6] G. Booch, J. Rumbaugh, I. Jacobson UML przewodnik użytkownika, WNT 2000
4) Program: IBM Rational Software Architect ver. ….. ?
(będzie dostępny u dr inż. T. Babczyńskiego oraz w punkcie „ksero” dla studentów.
Można go było również pobrać z Internetu – wersja darmowa w celach edukacyjnych).