Wydział Inżynierii Mechanicznej i Mechatroniki - Mechatronika (S1)
Sylabus przedmiotu Inżynieria oprogramowania:
Informacje podstawowe
Kierunek studiów | Mechatronika | ||
---|---|---|---|
Forma studiów | studia stacjonarne | Poziom | pierwszego stopnia |
Tytuł zawodowy absolwenta | inżynier | ||
Obszary studiów | nauk technicznych, studiów inżynierskich | ||
Profil | ogólnoakademicki | ||
Moduł | — | ||
Przedmiot | Inżynieria oprogramowania | ||
Specjalność | przedmiot wspólny | ||
Jednostka prowadząca | Instytut Technologii Mechanicznej | ||
Nauczyciel odpowiedzialny | Magdalena Krakowiak <Magdalena.Krakowiak@zut.edu.pl> | ||
Inni nauczyciele | |||
ECTS (planowane) | 3,0 | ECTS (formy) | 3,0 |
Forma zaliczenia | zaliczenie | Język | polski |
Blok obieralny | — | Grupa obieralna | — |
Formy dydaktyczne
Wymagania wstępne
KOD | Wymaganie wstępne |
---|---|
W-1 | Studnet posiada wiedzę z podstaw programowania i algorytmizacji. |
W-2 | Student zna podstawy programowania obiektowego. |
Cele przedmiotu
KOD | Cel modułu/przedmiotu |
---|---|
C-1 | Zapoznanie studentów z paradygmatem inzynierii oprogramowania: metodami, metodologiami i narzedziami zapewniającymi wysoką jakość wytwarzanego oprogramowania w ramach ustalonych terminów i w określonym budżecie. |
C-2 | Ukształtowanie umiejętności z zakresu posługiwania się wybranymi technikami wspomaganami narzędziami CASE. |
Treści programowe z podziałem na formy zajęć
KOD | Treść programowa | Godziny |
---|---|---|
laboratoria | ||
T-L-1 | Analiza narzędzi do opracowania projektu informatycznego. Studium wykonalności. | 2 |
T-L-2 | Dla zadanego systemu informatycznego tworzenie hierarchii diagramów DFD. Specyfikacja procesów prostych. | 2 |
T-L-3 | Na podstwie tablicy krzyzowań tworzenie diagramów ELH. Uwzględnianie nietypowego i awaryjnego cyklu życia każdego obiektu. | 2 |
T-L-4 | Tworzenie diagramu STD. Szczegółowy opis akcji i warunku zmiany stanu. Sprawdzanie porawności diagramu. | 3 |
T-L-5 | Tworzenie diagramu klas. Specyfikacja własności i metod. | 3 |
T-L-6 | Tworzenie diagramów przypadków użycia. | 3 |
15 | ||
projekty | ||
T-P-1 | Zajęcia organizacyjne - zasady zaliczania, plan pracy, podział na grupy i przydział tematów. | 1 |
T-P-2 | Specyfikacja wymagań projektu oraz wstępne harmonogramowanie projektu. | 2 |
T-P-3 | Sprawozdanie z poprzednich zajęć. Modelowanie funkcji i procesów. Omówienie diagramu kontekstowego i metod dekompozycji procesów. Sprawdzanie kompletności i jakości diagramu DFD. | 3 |
T-P-4 | Sprawozdanie z poprzednich zajęć. Modelowanie historii życia obiektów. Budowa tablicy krzyzowań - obiekt/zdarzenie. | 2 |
T-P-5 | Sprawozdanie z poprzednich zajęć. Modelowanie zmian stanów. Specyfikacja stanów nietypowych i awaryjnych. | 2 |
T-P-6 | Sprawozdanie z poprzednich zajęć. Diagramy klas - identyfikacja klas i obiektów. | 2 |
T-P-7 | Sprawozdanie z poprzednich zajęć. Diagramy przypadków użycia - sporządzanie słownika pojęć, identyfikacja aktorów i ich ról, określenie przypadków użycia. | 2 |
T-P-8 | Rozliczenie końcowego projektu przydzielonego systemu informatycznego. | 1 |
15 | ||
wykłady | ||
T-W-1 | Wprowadzenie do inżynierii oprogramowania. Podstawowe pojęcia i definicje. Kryzys oprogramowania. Charakterystyczne cechy oprogramowania. Inżynieria oprogramowania a inżynieria systemów. Mity zwiazane z inżynierią oprogramowania. Metody inżynierii oprogramowania. | 2 |
T-W-2 | Typowe czynności w cyklu życiowym oprogramowania. Modelu cyklu życia oprogramowania - modele sekwencyjne, modele iteracyjne, tworzenie z użyciem wielokrotnym i formalne transformacje. Narzędzia CASE i ich klasyfikacja. | 3 |
T-W-3 | Miary i pomiary w procesie wytwórczym. Miary procesu, produktu, mierzenie oprogramowania. Podstawowe miary: linie kodu, punkty funkcyjne, COCOMO II. Efektywność usuwania defektów - związek z planowaniem jakości i poziomem dojrzałości procesu. Proces mierzenia oprogramowania. | 2 |
T-W-4 | Techniki programowania strukturalnego. Modelowanie funkcji i procesów (diagramy DFD), modelowanie zmian stanów (diagramy STD) i zdarzeń (diagramy ELH). | 4 |
T-W-5 | Techniki programowania obiektowego. Język UML. Model a diagram w UML. Diagramy klas. Diagramy przypadków użycia. | 4 |
15 |
Obciążenie pracą studenta - formy aktywności
KOD | Forma aktywności | Godziny |
---|---|---|
laboratoria | ||
A-L-1 | Udział w zajęciach laboratoryjnych | 15 |
A-L-2 | Konsultacje do laboratoriów | 2 |
A-L-3 | Realizacja praktyczna przydzielonego zadania projektowego (praca własna) | 13 |
30 | ||
projekty | ||
A-P-1 | Uczestnictwo w zajęciach | 15 |
A-P-2 | Konsultacje do projektu | 2 |
A-P-3 | Opracowywanie sprawozdań - praca własna | 6 |
A-P-4 | Opracowanie kompletnego projektu (praca własna). | 7 |
30 | ||
wykłady | ||
A-W-1 | Udział w wykładach | 15 |
A-W-2 | Konsultacje do wykładów | 2 |
A-W-3 | Samodzielne studiowanie tematyki wykładów | 6 |
A-W-4 | Przygotowanie do zaliczenia (praca własna) | 8 |
31 |
Metody nauczania / narzędzia dydaktyczne
KOD | Metoda nauczania / narzędzie dydaktyczne |
---|---|
M-1 | Metoda objaśniająco-poglądowa - wykład z prezentacjami i przykładami. |
M-2 | Metoda problemowa z dyskusją - w ramach zajęć praktycznych realizacja zadań indywidualnych. |
Sposoby oceny
KOD | Sposób oceny |
---|---|
S-1 | Ocena podsumowująca: Wykład: ocena podsumowująca na podstawie zaliczenia pisemnego. |
S-2 | Ocena formująca: Projekt: ocena kształtująca na podstawie bieżących sprawozdań z wykonanych zadań |
S-3 | Ocena podsumowująca: Projekt: ocena podsumowująca na podstawie wykonanego zadania i obecności oraz aktywności na zajęciach. |
S-4 | Ocena podsumowująca: Laboratorium: ocena podsumowująca na podstawie wykonanego zadania i obecności oraz aktywności na zajęciach. |
Zamierzone efekty kształcenia - wiedza
Zamierzone efekty kształcenia | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów kształcenia prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
---|---|---|---|---|---|---|---|
ME_1A_C50_W02 Wiedza z metod strukturalnych i obiektowych projektowania systemów informatycznych. | ME_1A_W02, ME_1A_W05 | T1A_W02, T1A_W05 | — | — | — | — | — |
Zamierzone efekty kształcenia - umiejętności
Zamierzone efekty kształcenia | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów kształcenia prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
---|---|---|---|---|---|---|---|
ME_1A_C50_U01 Student powinien być w stanie specyfikować projekt systemu informatycznego oraz przeprowadzać jego analizę projektową | ME_1A_U06 | T1A_U03, T1A_U07, T1A_U08 | InzA_U01, InzA_U02 | — | — | — | — |
Kryterium oceny - wiedza
Efekt kształcenia | Ocena | Kryterium oceny |
---|---|---|
ME_1A_C50_W02 Wiedza z metod strukturalnych i obiektowych projektowania systemów informatycznych. | 2,0 | Student nie opanował podstawowej wiedzy z zakresu przedmiotu. |
3,0 | Student zna podstawy metod strukturalnych i obiektowych projektowania systemów informatycznych, ale popełnia liczne błędy przy ich charakterystyce. Nie potrafi wykorzystac wiedzy teoretycznej w praktyce. | |
3,5 | Student zna podstawy metod strukturalnych i obiektowych projektowania systemów informatycznych. Potrafi je scharakteryzować. Popełnia błędy w zastosowaniu praktycznym - budowie diagramów dla wybranych prostych przykładów. | |
4,0 | Student orientuje się w temacie metod strukturalnych i obiektowych projektowania systemów informatycznych. Potrafi je dobrze scharakteryzować. Potrafi samodzielnie zbudować odpowiednie diagramy dla wybranych prostych przykładów. | |
4,5 | Student biegle orientuje się w temacie metod strukturalnych i obiektowych projektowania systemów informatycznych. Potrafi je dobrze scharakteryzować. Popełnia nieliczne błędy przy budowie odpowiednich diagramoów dla wybranych złożonych przykładów. | |
5,0 | Student biegle orientuje się w temacie metod strukturalnych i obiektowych projektowania systemów informatycznych. Potrafi samodzielnie zbudować odpowiednie diagramy dla wybranych złożonych przykładów. |
Kryterium oceny - umiejętności
Efekt kształcenia | Ocena | Kryterium oceny |
---|---|---|
ME_1A_C50_U01 Student powinien być w stanie specyfikować projekt systemu informatycznego oraz przeprowadzać jego analizę projektową | 2,0 | Student ma istotne braki w przygotowaniu teoretycznym. Nie umie wykorzystać posiadanej wiedzy praktycznie. Nie potrafi poprawnie rozwiązywać problemów projektowych. |
3,0 | Student ma problemy z wykorzystaniem wiedzy teoretycznej. Popełnia liczne błędy w specyfikowaniu projektu prostego systemu informatycznego i jego analizie. | |
3,5 | Student posiadł umiejętności w stopniu pośrednim miedzy oceną 3,0 i 4,0. | |
4,0 | Student umiejętnie wykorzystuje wiedzę teoretyczną do realizacji zadań projektowych - samodzielnie jest w stanie specyfikować projekt prostego systemu informatycznego i dobrze przeprowadzić jego analizę. | |
4,5 | Student posiadł umiejętności w stopniu pośrednim miedzy oceną 4,0 i 5,0. | |
5,0 | Student umiejętnie wykorzystuje wiedzę teoretyczną do realizacji zadań projektowych - samodzielnie jest w stanie specyfikować projekt złożonego systemu informatycznego i dobrze przeprowadzić jego analizę. |
Literatura podstawowa
- Jaszkiewicz A., Inżynieria oprogramowania, Helion, Gliwice, 1997
- Pressman R. S., Praktyczne podejście do inżynierii oprogramowania, WNT, Warszawa, 2004
- Bruegge B., Dutoit A. H., Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java, Helion, Gliwice, 2011