Zajęcia laboratoryjne z przedmiotu IOP Warszawa, październik 2013 dr inż. Marcin Szlenk dr inż. Andrzej Zalewski 1. Cel zajęć... 1 2. Model analityczny... 1 3. Organizacja prac... 2 3.1. Zespoły... 2 3.2. Terminy... 2 3.3. Zmiana tematu zadania... 2 4. Zasady oceny... 2 4.1. Ocena zadania... 2 4.2. Ocena końcowa... 3 5. Sposób przygotowania dokumentów... 4 6. Zadania... 4 6.1. Modelowanie przypadków użycia środowiska... 4 6.2. Modelowanie przypadków użycia systemu... 5 6.3. Modelowanie pojęć systemu... 5 7. Wskazówki... 6 8. Pytania i odpowiedzi... 6 8.1. Rozpoznanie dziedziny... 6 1. Cel zajęć Zajęcia mają na celu zapoznanie studentów z problematyką przygotowywania dokumentacji analitycznej w projekcie budowy systemu informatycznego. Poprawne wykonanie stawianych w trakcie laboratorium zadań wymaga zarówno opanowania wybranych technik i notacji, jak i zapoznania się ze wskazanymi w ramach poszczególnych zadań dziedzinami wiedzy i obszarami zastosowań systemów informatycznych. 2. Model analityczny Dokumentacja analityczna powstająca w ramach projektu informatycznego stanowi środek komunikacji i efekt porozumienia pomiędzy przyszłym użytkownikiem tego systemu a zespołem informatycznym: projektantami i programistami. Dokumentacja powinna zostać przygotowana w taki sposób, aby: 1. Użytkownicy posiadający wiedzę specyficzną dla dziedziny zastosowań byli w stanie potwierdzić, że dokumentacja ta prawidłowo opisuje procesy, których realizację będzie wspomagał system informatyczny oraz właściwie określa funkcje tego systemu. 2. Projektanci i programiści byli w stanie, jedynie na podstawie tej dokumentacji, zaproponować zgodną z oczekiwaniami użytkownika implementację opisanych w dokumentacji analitycznej funkcji systemu. 1/7
3. Organizacja prac Zajęcia laboratoryjne obejmują wykonanie 3 zadań, dotyczących różnych faz przygotowania dokumentacji analitycznej: 1. Modelowanie przypadków użycia środowiska; 2. Modelowanie przypadków użycia systemu; 3. Modelowanie pojęć systemu. Zajęcia mają charakter laboratoryjno-projektowy. Zadania wykonuje się na miejscu i/lub w domu, w konsultacji z prowadzącymi. Prowadzący są w związku z tym dostępni w godzinach zajęć laboratoryjnych, by służyć radą i pomocą. Prowadzący nie rozwiązują zadań za studentów, a jedynie wskazują jak zadanie rozwiązać poprawnie. 3.1. Zespoły Zadania będą realizowane w 3- lub 4-osobowych zespołach. W przypadku, gdy niektórzy członkowie zespołu będą się uchylali od pracy nad rozwiązaniem zadania, praca musi zostać przygotowana przez pozostałych członków zespołu. Członkowie zespołu, których nazwiska nie zostaną umieszczone w metryce dokumentu otrzymają ocenę 2. 3.2. Terminy Szczegółowy harmonogram zajęć w tym semestrze jest następujący: Data Wydarzenie 25 października 2013 Publikacja tematów 22 listopada 2013 Oddanie zadania 1 29 listopada 2013 Publikacja ocen zadania 1 20 grudnia 2013 Oddanie zadania 2 10 stycznia 2014 Publikacja ocen zadania 2 24 stycznia 2014 Oddanie zadania 3 31 stycznia 2014 Publikacja ocen końcowych 3.3. Zmiana tematu zadania Wszystkie etapy dotyczą tego samego tematu (organizacja, przedsiębiorstwo). Zmiana tematu możliwa jest w dwóch przypadkach: 1. Realizacja poprzedniego etapu wykazała, że zespół ewidentnie nie radzi sobie z danym tematem (zmiana tematu nieobligatoryjna). 2. Realizacja poprzedniego etapu wykazała, że zespół kopiuje dokumenty dostępne w Internecie lub cudze rozwiązania, np. opracowane przez studentów lat poprzednich (zmiana tematu obligatoryjna). 4. Zasady oceny 4.1. Ocena zadania Ocena rozwiązania każdego z zadań będzie obliczana jako średnia ważona ocen cząstkowych. Każda z ocen cząstkowych będzie wystawiana w skali od 2 do 5. Oceny cząstkowe dla poszczególnych zadań przedstawia poniższa tabela: 2/7
Lp. Zadanie 1. Modelowanie przypadków użycia środowiska 2. Modelowanie przypadków użycia systemu 3. Modelowanie pojęć systemu Ocena cząstkowa Waga Przedmiot oceny 40% diagramy przypadków użycia środowiska 50% specyfikacja przypadków użycia środowiska Wyjaśnienia Ocenie będzie podlegała zgodność z notacją oraz merytoryczna poprawność oraz kompletność diagramów i listy aktorów. Ocenie będzie podlegała merytoryczna poprawność i precyzja opisów oraz merytoryczna poprawność diagramów. 10% typografia i estetyka Ocenie będzie podlegała zgodność ze wskazanymi w niniejszej instrukcji zasadami przygotowania dokumentów oraz estetyka przekazanego opracowania i poprawność stylistyczna języka. 40% diagramy przypadków użycia systemu 30% specyfikacje przypadków użycia Ocenie będzie podlegała zgodność z notacją oraz merytoryczna poprawność oraz kompletność diagramów i listy aktorów. Ocenie będzie podlegała merytoryczna poprawność, kompletność, precyzja i kompletność opisów. 20% projekty ekranów Ocenie będzie podlegała czytelność oraz spójność ze specyfikacją przypadku użycia. 10% typografia i estetyka Ocenie będzie podlegała zgodność ze wskazanymi w niniejszej instrukcji zasadami przygotowania dokumentów oraz estetyka przekazanego opracowania i poprawność stylistyczna języka. 60% diagram klas Ocenie będzie podlegała zgodność z notacją oraz merytoryczna poprawność oraz kompletność diagramu. 30% specyfikacja klas Ocenie będzie podlegała merytoryczna poprawność, kompletność, precyzja i kompletność opisów. 10% typografia i estetyka Ocenie będzie podlegała zgodność ze wskazanymi w niniejszej instrukcji zasadami przygotowania dokumentów oraz estetyka przekazanego opracowania i poprawność stylistyczna języka. 4.2. Ocena końcowa Ocena końcowa z laboratorium zostanie obliczona jako średnia ocen z realizacji poszczególnych zadań i zaokrąglona do najbliższej wielokrotności liczby 0,5. 3/7
5. Sposób przygotowania dokumentów Rozwiązanie każdego zadania musi zostać przygotowane i przekazane w postaci jednolitego dokumentu. Dokumenty muszą zostać przekazane w postaci wydruku. Strony wydruku powinny zostać połączone zszywaczem, ew. spinaczem. Należy unikać oprawiania dokumentów, w tym ich bindowania, a ponadto oszczędzać papier stosując druk dwustronny. Dokument musi zostać napisany czcionką szeryfową o rozmiarze od 10 do 12 punktów przy rozmiarze interlinii 1.0. Tekst powinien zostać wyrównany do lewego i prawego marginesu. Na dole strony tytułowej dokumentu musi zostać umieszczona tabelka (metryka dokumentu) zgodna z następującym wzorcem: Przedmiot: IOP Semestr: Zima 2013 Zadanie (nr/nazwa): 1. Rozpoznanie środowiska Temat (nr/treść): 1. Moduł kontrolingowy systemu FK Zespół (członkowie): Stefan Abacki, Jan Kowalski Wszystkie strony dokumentu powinny mieć jednolitą numerację. Numery strony powinien znajdować się w prawym dolnym rogu. Na drugiej stronie dokumentu powinien znajdować się spis treści. Zamieszczone w dokumentach diagramy mogą zostać opracowane za pomocą dowolnego narzędzia wspomagającego notację UML, np. Rational Rose, MS Visio. Dokumenty muszą zostać opracowane samodzielnie cytaty z innych opracowań nie mogą stanowić więcej niż 20% treści przekazywanych do oceny dokumentów i muszą zostać wskazane ich źródła. W przypadku stwierdzenia kopiowania cudzych rozwiązań, w szczególności opracowanych przez studentów lat poprzednich, zespół automatycznie otrzymuje za zadanie ocenę 2. 6. Zadania 6.1. Modelowanie przypadków użycia środowiska Cel Dokument powinien opisywać specyfikację interakcji (dialogu) użytkowników zewnętrznych (np. klientów, innych organizacji lub istniejących systemów informatycznych) z daną organizacją (w tym jej pracownikami). Dana organizacja pełni rolę środowiska, w którym działał będzie projektowany system informatyczny. Wyniki prac Lista aktorów lista użytkowników i systemów informatycznych podejmujących interakcję ze środowiskiem wraz z ich zwięzłym i precyzyjnym opisem. Diagramy przypadków użycia środowiska diagramy ilustrujące przypadki użycia środowiska (nazywane też biznesowymi przypadkami użycia) i związki z odpowiednimi aktorami, sporządzone zgodnie z notacją UML. Przyjęty poziom abstrakcji ( szczegółowość przypadków użycia, a zatem i ich liczba) powinien być na tyle niewielki, by nie wymagał definiowania związków pomiędzy przypadkami użycia. Specyfikacje przypadków użycia środowiska zwięzły opis przypadków użycia oraz specyfikacje czynności wykonywanych w ramach poszczególnych przypadków zapisane jako diagramy czynności (activity diagram) w notacji UML. Na diagramach należy w szczególny 4/7
sposób oznaczyć czynności (węzły diagramów), które wspierać będzie projektowany system informatyczny, np. opatrując je stereotypem <<system>>. Uwaga: Dla każdego przypadku użycia na diagramie należy opracować jego specyfikację (diagram czynności). 6.2. Modelowanie przypadków użycia systemu Cel Dokument powinien opisywać specyfikację interakcji (dialogu) użytkowników z projektowanym systemem informatycznym, umożliwiając zaprojektowanie jego interfejsu i sporządzenie makiety tego systemu. Wyniki prac Lista aktorów lista użytkowników i systemów informatycznych podejmujących interakcję z projektowanym systemem. Diagramy przypadków użycia systemu sporządzone zgodnie z notacją UML diagramy ilustrujące przypadki użycia systemu i ich związki z odpowiednimi aktorami, oraz zależności pomiędzy przypadkami użycia (<<include>>, <<extend>>, generalizacja/specjalizacja). Specyfikacje przypadków użycia systemu specyfikacje przebiegu interakcji w obrębie poszczególnych przypadków użycia w postaci opisu warunku początkowego, scenariusza podstawowego, scenariuszy alternatywnych, punktów rozszerzeń i warunku końcowego. Projekty ekranów graficzny szkic lub zrzut z ekranu komputera, ekranu/formularza służącego do wprowadzania danych lub wybierania opcji przez użytkownika w ramach danego przypadku użycia. Uwaga: Dla każdego przypadku użycia na diagramie należy opracować jego specyfikację oraz projekt ekranu (jeśli z przypadkiem użycia wiąże się wprowadzanie danych, wybieranie opcji). 6.3. Modelowanie pojęć systemu Cel Dokument powinien opisywać specyfikację pojęć związanych z projektowanym systemem. Wyniki prac Diagram klas diagram klas przedstawiający pojęcia dotyczące projektowanego systemu informatycznego, sporządzony zgodnie z notacją UML. Specyfikacje klas (pojęć) powinny obejmować specyfikacje atrybutów, dla których należy wyspecyfikować odpowiedni typ niezwiązany jednak z określoną platformą implementacji, np. LiczbaCałkowita, LiczbaRzeczywista, Napis itp. Należy wyspecyfikować związki pomiędzy klasami: związek asocjacji (i jej szczególne przypadki agregację, kompozycję) wraz z licznością końców, oraz związek genralizacji/specjalizacji. Specyfikacja klas zwięzły opis znaczenia poszczególnych klas i ich atrybutów. Uwaga: Nie podajemy operacji dla klas. 5/7
7. Wskazówki Modelowanie środowiska a modelowanie wymagań systemowych Przypadki użycia na poziomie środowiska (p. 6.1) reprezentują interakcję aktorów z opisywanym środowiskiem, natomiast przypadki użycia na poziomie systemu (p. 6.2) opisują interakcję aktorów z systemem informatycznym. W obu przypadkach aktorzy mogą być inni, np. aktorem dla dziekanatu będzie wykładowca, który składa arkusz z ocenami, a aktorem dla systemu informatycznego wspierającego pracę dziekanatu będzie pracownik dziekanatu, który wpisuje oceny do systemu. Przypadki użycia systemu wynikają naturalnie z procesów opisanych przypadkami użycia środowiska. Podobna zależność dotyczy pojęć używanych przy opisie środowiska (p. 6.1) i pojęć na poziomie systemu (p. 6.3). Cześć pojęć pojawiających się przy opisie środowiska, pojawi się również przy opisie systemu. W drugim przypadku mogą pojawić się jednak nowe pojęcia związane z korzystaniem z projektowanego systemu (wprowadzaniem/wyświetlaniem określonych danych, konfiguracją). Weryfikacja jakości tworzonych dokumentów Skutecznym techniką weryfikacji przydatności dokumentu analitycznego opracowanego w ramach realizacji kolejnego zadania jest przekazanie go z prośbą o ocenę osobie zarówno nie będącej specjalistą z zakresu analizowanego procesu jak i nie zaangażowanej w prace analityczne. 8. Pytania i odpowiedzi Poniżej zamieszczone zostały odpowiedzi na pytania studentów. Lista ta będzie sukcesywnie uzupełniana. 8.1. Rozpoznanie dziedziny Pytanie: Czy ma to być cos w rodzaju propozycji kształtu programu obsługującego dane zagadnienie, czy raczej czysta analiza? Odpowiedź: Powinien Pan przeprowadzić analizę procesu prowadzenia działań kontrolnych przez NIK czyli tego jak taka kontrola przebiega kto podejmuje decyzje o przeprowadzeniu kontroli (w jakim trybie zapada decyzja o przeprowadzeniu kontroli), kto przeprowadza, jakie informacje są gromadzone w toku kontroli, jakie dokumenty (zbiory informacji) towarzyszą poszczególnym fazom kontroli, jaki jest wynik kontroli. Pytanie: Jakich głównych wytycznych należy się trzymać (z wykładu, któregoś podręcznika czy może innych źródeł)? Odpowiedź: Nie ma żadnych głównych wytycznych poza czytelnością, zwięzłością i zrozumiałością. Proszę zwięźle przedstawić sposób prowadzenia działań kontrolnych przez NIK. Zadanie nie jest algorytmiczne, lecz twórcze. Pytanie: Czy wystarczy ze strony NIKu pozyskać dokumenty dotyczące kontroli i na podstawie tego pisać, czy raczej szukać materiałów na stronach jakichś firm (jeśli tak, to jakich?) zajmujących się tworzeniem programów do obsługi tego typu organizacji? Odpowiedź: Odwołanie do odpowiednich źródeł informacji to niestety leży po Pana stronie i podlega ocenie. 6/7
Pytanie: Jaka ma być objętość stronicowa spisanego projektu, żeby nie został uznany za niewystarczający? Odpowiedź: Objętość adekwatna do zagadnienia por. odp. na pyt. dot. głównych wytycznych. Pytanie: Czy trzeba użyć jakiegoś specjalnego oprogramowania do tworzenia dokumentacji? Odpowiedź: Nie. 7/7