Katedra Oprogramowania
Wydział Informatyki PB
Inżynieria oprogramowania
Pracownia specjalistyczna
Celem zajęć jest praktyczne zapoznanie się z modelowaniem i projektowaniem w UML-u przy wykorzystaniu narzędzia CASE. W pierwszej części zajęć rysowane są diagramy UML na podstawie zadanych scenariuszy, natomiast w drugiej części zdobyte umiejętności są weryfikowane podczas tworzeniu (wstępnego) projektu wybranego systemu informatycznego. Praca odbywa się indywidualnie (I część) oraz w grupach 3 osobowych (II część). Podczas pracy w grupach należy wykorzystywać repozytorium do przechowywania tworzonych elementów sprawozdania.
Nr |
Temat zajęć | Uwagi |
| 1 | Przedstawienie wymagań i sposobu prowadzenia zajęć, utworzenie zespołów, pokaz działania programów do tworzenia diagramów UML (np. Visual Paradigm for UML), wybór narzędzia wersjonowania (repozytorium) |
|
| 2 | Wprawki - diagram przypadków użycia, opisywanie przypadków użycia |
|
| 3 | Wprawki - diagram czynności |
SP (d. przyp.uż.- 3 pkt.) |
| 4 | Wprawki - diagram klas, pakiety |
SP (d. czyn. - 3 pkt.) |
| 5 | Wprawki - diagram stanów |
SP (d. klas - 5 pkt.) |
| 6 | Wprawki - diagramy interakcji (przebiegu) |
SP (d. st. - 3 pkt.) |
| 7 | Wprawki - diagramy fizyczne (komponentów i wdrożenia) |
SP (d. int. - 3 pkt.) |
| 8 | Uzgadnianie tematyki zadania grupowego, określanie celów i zakresu projektowanego systemu oraz korzyści z jego wdrożenia |
SP (d. fiz. - 3 pkt.) |
| 9 | Tworzenie i opisywanie diagramów przypadków użycia, projektowanie interefjsu użytkownika |
TC (p. 2, 5.4) |
| 10 | Tworzenie diagramu klas, identyfikowanie atrybutów i metod, opracowywanie realizacji przypadków użycia, d. interakcji - poziom pojęciowy |
TC (p. 4.1) |
| 11 | Opracowywanie realizacji przypadków użycia, tworzenie diagramów przebiegu - poziom implementacyjny, czynności |
TC (p. 5.1, 5.2) |
| 12 | Przygotowywanie diagramów zmiany stanu |
TC (p. 4.2, 4.3) |
| 13 | Specyfikowanie wymagań niefunkcjonalnych i propozycji technologii informatycznych, przygotowanie proponowanego planu pracy i analiza ryzyka projektu |
TC (p. 5.3) |
| 14 | Prezentacja projektu, przedstawienie podziału pracy i przekazanie sprawozdania projektowego do oceny |
TK |
| 15 | Ewentualna weryfikacja zadeklarowanego podziału pracy i zgodności z zasadami, omówienie oceny punktowej, ewentualna poprawa sprawdzianów |
Sposób zaliczenia pracowni specjalistycznej:
Ocena końcowa jest wyliczana na podstawie:
- krótkich sprawdzianów (SP) (od 0 do 20 punktów), zdobycie
50% puntów ze sprawdzianów jest warunkiem koniecznym zaliczenia,
- zdobyczy punktowej za rozwiązanie projektowe (od 0 do 10
punktów),
- terminowości pracy:
- przygotowanie teoretyczne do zajęć: brak przygotowania to strata 0.5 punkta,
- 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 punkty),
- podziału pracy w ramach zespołu,
- obrony projektu.
Przeliczenie punktów na oceny jest następujące:
| Punkty | 30.0-27.0 | 26.75 - 24.0 | 23.75 - 21.0 | 20.75 - 18.0 | 17.75 - 15.0 |
| Ocena | 5,0 | 4,5 | 4,0 | 3,5 | 3,0 |
Zawartość sprawozdania projektowego:
0. Metryczka (uczelnia, wydział, kierunek, przedmiot, rok
i semestr studiów, prowadzący i data przekazania sprawozdania)
0.1. Skład zespołu i podział pracy
pomiędzy poszczególnych uczestników zespołu
0.2. Proponowana punktacja
0.3. Adres (publiczny) repozytorium projektu; informacje niezbędne do uzyskania dostępu
1. Treść zadania projektowego
2. Cel budowania systemu, jego zakres oraz kontekst,
przewidywalne mierzalne (z podaniem konkretnych wartości i sposobów ich wyliczenia)
i niemierzalne korzyści z jego wdrożenia
3. Słownik (definiujący ważne, specyficzne terminy związane
z dziedziną problemu, wykorzystywane w projekcie)
4. Perspektywa przypadków użycia:
4.1. Diagramy przypadków użycia (co
najmniej 10 przypadków użycia)
4.1.1. Opisy tekstowe
wszystkich aktorów
4.1.2. Opisy tekstowe
wybranych przypadków użycia (co najmniej 3 opisy):
- nazwę przypadku
- wykaz uczestniczących w nim aktorów
- opis tekstowy ciągu zdarzeń, zarówno podstawowego jak i
alternatywnych (np. awaryjnego)
- częstotliwość wykonania, przewidywane spiętrzenia oraz czasy
realizacji (typowy, maksymalny)
- opis wartości uzyskiwanych przez aktorów po zakończeniu przypadku
użycia
4.2. Diagramy czynności (3 przykładowe
diagramy)
4.3. Diagramy interakcji (przebiegu) z
opisem tekstowym komunikatów (3 przykładowe diagramy)
5. Perspektywa projektowa:
5.0. Proponowana architektura systemu (np. w postaci diagramu pakietów/komponentów) wraz z opisem
5.1. Diagram(-y) klas
5.2. Uporządkowany alfabetycznie wykaz
wszystkich klas, zawierający:
- krótki opis tekstowy
- wykaz wszystkich zidentyfikowanych atrybutów i metod (z krótkim opisem tekstowym w przypadku mniej czytelnych nazw)
5.3. Diagramy stanów (3 diagramy dla
wybranych klas) wraz z opisem tekstowym występującym na nich elementów
5.4. Propozycje interfejsu użytkownika
(okno główne, menu główne i podręczne, kluczowe formatki dialogowe, itp...)
6. Wymagania niefunkcjonalne dla system, w tym m.in.:
6.1. Oszacowanie wielkości bazy danych
6.2. Propozycja wymaganych czasów
odpowiedzi
6.3. Oszacowanie liczby i typów
potrzebnych stanowisk pracy użytkowników systemu
7. Propozycja technologii informatycznych, które mogą zostać
wykorzystane do realizacji systemu (sprzęt, oprogramowanie)
- diagram(-y) wdrożenia
8. Propozycja planu pracy zawierająca, przynajmniej:
- wyróżnione etapy (powiązane z
konkretnymi częściami systemu, realizowanymi komponentami, ...)
z podanym czasem trwania
każdego etapu (dni robocze)
- zależności pomiędzy etapami (np. co
musi być zakończone przed rozpoczęciem kolejnego etapu)
- alokacja zasobów ludzkich do
realizacji poszczególnych etapów
9. Analiza ryzyka projektu zawierająca wykaz
przewidywanych zagrożeń (tylko zagrożenia specyficzne dla projektu):
- prawdopodobieństwo/szansa
wystąpienia (np.: znikome, średnie, duże, bardzo duże)
- stopień szkodliwości w przypadku
wystąpienia (np.: duży, średni, mały)
- propozycje metod zapobiegania danemu
zagrożeniu
- plan awaryjny (sposób postępowania)
w przypadku wystąpienia zagrożenia
10. Kosztorys realizacji przedsięwzięcia (koszty projektu, oprogramowania,
systemu, szkoleń, wdrożenia oraz konsultacji)
- w rozbiciu na mniejsze jednostki
(etapy, podsystemy, moduły,...)
- warunki płatności, sposób odbioru
- może być wariantowy
Dodatek A. Przebieg (terminowość) prac zespołu
- wygenerowany wykres przedstawiający historię commit-ów do repozytorium autorów projektu.
- struktura podkatalogów w repozytorium powinna być zgodna z terminami cząstkowymi oraz powinien istnieć oddzielny podkatalog z wersją edytowalną sprawozdania.
Kilka uwag dotyczących (formy) sprawozdania:
1. Poszczególne części sprawozdania powinny być ze sobą spójne. Dobrym pomysłem może być całościowe koordynowanie
opracowywania danej funkcjonalności przez jedną osobę, poczynając od opisu przypadku użycia, przez różne diagramy czy propozycje interfejsu.
2. Przy zamieszczonych diagramach zawsze podajemy co diagram przedstawia (np. nazwę jakiegoś procesu, aktywności) a nie tylko rodzaj diagramu.
3. Diagramy i zrzuty ekranowe muszą być czytelne, proszę zwracać uwagę na zniekształcenia przy wstawianiu do dokumentu głównego.
4. Bez zbędnych upiększeń oraz sprawdzona ortografia.
Wykorzystanie narzędzi sztucznej inteligencji:
1. Nie wolno generować diagramów ani tekstu przy wykorzystaniu narzędzi (generatywnej) SI. Jeśli takie działania zostaną wykryte,
wówczas projekt zostanie "wyzerowany".
2. Można generować prototypy interfejsu (zawsze trzeba to jednoznacznie zadeklarować z podaniem narzędzia).
3. W przypadku wątpliwości co do przestrzegania zasad, autorzy mogą zostać poproszeni o wyjaśnienia.
Przygotowanie materiałów przekazywanych do oceny:
1. Dokumentacja projektu w formie elektronicznej (w formacie pdf) zawierająca wszystkie elementy określone w “Zawartości sprawozdania projektowego”
2. Spakowany (zip) katalog z oryginalnymi plikami zawierającymi diagramy UML (z podaniem nazwy i wersji narzędzia wykorzystywanego;
jeśli używane różne narzędzia to pogrupowane w podkatalogi o nazwach zgodnych z nazwą narzędzia; nazwy plików powinny jednoznacznie identyfikować rodzaj diagramu)
3. Oba przesyłane pliki powinny mieć nazwę skladającą się z nazwisk autorów (bez polskich znaków) oddzielonych podkreśleniami, np. Nowak_Kowalalski_Milosz.pdf i Nowak_Kowalski_Milosz.zip
Copyright © 2026 - Marek Krętowski. All rights reserved.
Revised:
2026-02-25