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).