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

Powrót   


Copyright © 2026 - Marek Krętowski. All rights reserved.
Revised:
2026-02-25