Wydział Informatyki - Informatyka (S1)
Sylabus przedmiotu Inżynieria oprogramowania:
Informacje podstawowe
| Kierunek studiów | Informatyka | ||
|---|---|---|---|
| Forma studiów | studia stacjonarne | Poziom | pierwszego stopnia |
| Tytuł zawodowy absolwenta | inżynier | ||
| Obszary studiów | charakterystyki PRK, kompetencje inżynierskie PRK | ||
| Profil | ogólnoakademicki | ||
| Moduł | — | ||
| Przedmiot | Inżynieria oprogramowania | ||
| Specjalność | przedmiot wspólny | ||
| Jednostka prowadząca | Katedra Inżynierii Oprogramowania | ||
| Nauczyciel odpowiedzialny | Łukasz Radliński <lradlinski@zut.edu.pl> | ||
| Inni nauczyciele | Michał Fedorov <Michal.Fedorov@zut.edu.pl> | ||
| ECTS (planowane) | 4,0 | ECTS (formy) | 4,0 |
| Forma zaliczenia | zaliczenie | Język | polski |
| Blok obieralny | — | Grupa obieralna | — |
Formy dydaktyczne
Wymagania wstępne
| KOD | Wymaganie wstępne |
|---|---|
| W-1 | Programowanie 2 |
| W-2 | Algorytmy 1 |
| W-3 | Narzędzia inżynierskie |
Cele przedmiotu
| KOD | Cel modułu/przedmiotu |
|---|---|
| C-1 | Zapoznanie studenta z podstawami inżynierii oprogramowania - metodami, metodykami technikami i narzędziami zapewniającymi wysoką jakość wytwarzanego oprogramowania w ustalonym terminie i budżecie. |
Treści programowe z podziałem na formy zajęć
| KOD | Treść programowa | Godziny |
|---|---|---|
| laboratoria | ||
| T-L-1 | Analiza i konfiguracja narzędzi wspomagających realizację projektu programistycznego. Studium wykonalności. | 2 |
| T-L-2 | Definicja zadania projektowego, opracowanie harmonogramu prac | 2 |
| T-L-3 | Specyfikacja wymagań oprogramowania | 2 |
| T-L-4 | Modelowanie i analiza wymagań - diagramy przypadków użycia, diagramy czynności | 4 |
| T-L-5 | Projektowanie architektury oprogramowania - diagramy klas, komponentów, rozmieszczenia, sekwencji, maszyny stanowej | 3 |
| T-L-6 | Opracowanie modelu danych, projektu bazy danych, generowanie struktury bazy danych | 3 |
| T-L-7 | Projektowanie interfejsu użytkownika i interakcji z użytkownikiem | 2 |
| T-L-8 | Opracowanie planu testowania, scenariuszy testowych | 2 |
| T-L-9 | Implementacja prototypu oprogramowania | 6 |
| T-L-10 | Dokończenie opracowania dokumentacji projektowej, procedura wdrożenia, podsumowanie wkładu uczestników | 2 |
| T-L-11 | Prezentacja i ocena projektów oraz prototypu oprogramowania | 2 |
| 30 | ||
| wykłady | ||
| T-W-1 | Wprowadzenie do inżynierii oprogramowania | 2 |
| T-W-2 | Inżynieria wymagań | 2 |
| T-W-3 | Analiza i modelowanie oprogramowania – diagramy UML | 6 |
| T-W-4 | Projektowanie architektury systemu | 2 |
| T-W-5 | Narzędzia wspomagające inżynierię oprogramowania | 2 |
| T-W-6 | Zapewnienie jakości i testowanie oprogramowania | 6 |
| T-W-7 | Ryzyko w projektach informatycznych | 2 |
| T-W-8 | Szacowanie i prognozowanie w inżynierii oprogramowania | 2 |
| T-W-9 | Ewolucja i konserwacja oprogramowania | 1 |
| T-W-10 | Metodyki wytwarzania oprogramowania | 3 |
| T-W-11 | Zaliczenie wykładów | 2 |
| 30 | ||
Obciążenie pracą studenta - formy aktywności
| KOD | Forma aktywności | Godziny |
|---|---|---|
| laboratoria | ||
| A-L-1 | Laboratorium | 30 |
| A-L-2 | przygotowanie dokumentacji i prototypu | 16 |
| A-L-3 | konsultacje | 2 |
| A-L-4 | przygotowanie do zaliczenia | 2 |
| 50 | ||
| wykłady | ||
| A-W-1 | Uczestnictwo w wykładach | 30 |
| A-W-2 | Udział w konsultacjach | 2 |
| A-W-3 | Samodzielne studiowanie tematyki wykładów i przygotowanie się do zaliczenia | 18 |
| 50 | ||
Metody nauczania / narzędzia dydaktyczne
| KOD | Metoda nauczania / narzędzie dydaktyczne |
|---|---|
| M-1 | Wykład informacyjny połączony z metodą badania przypadków oraz komputerową demonstracją |
| M-2 | Ćwiczenia laboratoryjne |
| M-3 | Zespołowe zadania projektowe |
Sposoby oceny
| KOD | Sposób oceny |
|---|---|
| S-1 | Ocena formująca: Ocena poszczególnych zadań - etapów procesu wytwarzania oprogramowania. |
| S-2 | Ocena formująca: Ocena za prezentację implementacji opracowanego oprogramowania. |
| S-3 | Ocena podsumowująca: Ocena końcowa za laboratoria uwzględniająca oceny z indywidualnych zadań / punktów kontrolnych, dokumentację techniczną i użytkową, sposób użycia narzędzi wspomagających, implementację i prezentację projektu/prototypu. |
| S-4 | Ocena podsumowująca: Pisemne zaliczenie wykładów |
Zamierzone efekty uczenia się - wiedza
| Zamierzone efekty uczenia się | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów uczenia się prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_C12_W01 Student posiada podstawową wiedzę z zakresu modeli procesów wytwórczych oraz zarządzania projektami informatycznymi | I_1A_W05 | — | — | C-1 | T-W-1, T-W-5, T-W-11, T-W-9, T-W-7, T-W-10, T-W-8 | M-1 | S-4 |
| I_1A_C12_W02 Student posiada podstawową wiedzą z zakresu analizy, projektowania, implementacji i testowania oprogramowania | I_1A_W05 | — | — | C-1 | T-W-4, T-W-3, T-W-1, T-W-2, T-W-5, T-W-6, T-W-11, T-W-9 | M-1 | S-4 |
Zamierzone efekty uczenia się - umiejętności
| Zamierzone efekty uczenia się | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów uczenia się prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_C12_U01 Student umie rozwiązywać zadania inżynierskie z każdego etapu procesu wytwarzania oprogramowania | I_1A_U10 | — | — | C-1 | T-L-3, T-L-4, T-L-1, T-L-9, T-L-11, T-L-2, T-L-7, T-L-8, T-L-10, T-L-5, T-L-6 | M-2, M-3 | S-2, S-1, S-3, S-4 |
Zamierzone efekty uczenia się - inne kompetencje społeczne i personalne
| Zamierzone efekty uczenia się | Odniesienie do efektów kształcenia dla kierunku studiów | Odniesienie do efektów zdefiniowanych dla obszaru kształcenia | Odniesienie do efektów uczenia się prowadzących do uzyskania tytułu zawodowego inżyniera | Cel przedmiotu | Treści programowe | Metody nauczania | Sposób oceny |
|---|---|---|---|---|---|---|---|
| I_1A_C12_K01 Student umie współpracować w zespole przy realizacji prostego projektu programistycznego. | I_1A_K02 | — | — | C-1 | T-L-3, T-L-4, T-L-1, T-L-9, T-L-11, T-L-2, T-L-7, T-L-8, T-L-10, T-L-5, T-L-6 | M-2, M-3 | S-3 |
Kryterium oceny - wiedza
| Efekt uczenia się | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_C12_W01 Student posiada podstawową wiedzę z zakresu modeli procesów wytwórczych oraz zarządzania projektami informatycznymi | 2,0 | nie spełnia kryteriów okreslonych dla oceny 3 |
| 3,0 | potrafi wymienić i zdefiniować wybrane podstawowe procesów wytwórczych, potrafi wymienić i zdefiniować wybrane podstawowe metryki wytwarzania oprogramowania, | |
| 3,5 | potrafi wymienić i zdefiniować wszystkie podstawowe procesy wytwórcze, potrafi wymienić i zdefiniować większość głównych metryk wytwarzania oprogramowania | |
| 4,0 | potrafi precyzyjnie opisać wybrane procesy wytwórcze, potrafi precyzyjnie opisać wybrane metryki wytwarzania oprogramowania | |
| 4,5 | potrafi precyzyjnie opisać wszystkie procesy wytwórcze, potrafi precyzyjnie opisać większość głównych metryk wytwarzania oprogramowania | |
| 5,0 | potrafi objaśnić wpływ procesów wytwórczych na przedsiewzięcie informatyczne, potrafi objaśnić metryki wytwarzania oprogramowania dotyczące wszystkich aspektów wytwarzania oprogramowania | |
| I_1A_C12_W02 Student posiada podstawową wiedzą z zakresu analizy, projektowania, implementacji i testowania oprogramowania | 2,0 | nie spełnia kryteriów okreslonych dla oceny 3 |
| 3,0 | potrafi wymienić i zdefiniować wybrane podstawowe diagramy UML i ich zadania, elementy składowe projektu oprogramowania, poziomy testowania, typy testów, role i artefakty procesu testowania oraz metody testowania | |
| 3,5 | potrafi wymienić i zdefiniować wszystkie podstawowe diagramy UML i ich zadania, elementy składowe projektu oprogramowania, poziomy testowania, typy testów, role i artefakty procesu testowania oraz metody testowania | |
| 4,0 | potrafi precyzyjnie opisać wybrane podstawowe diagramy UML i ich zadania, elementy składowe projektu oprogramowania, poziomy testowania, typy testów, role i artefakty procesu testowania oraz metody testowania | |
| 4,5 | potrafi precyzyjnie opisać wszystkie podstawowe diagramy UML i ich zadania, elementy składowe projektu oprogramowania, poziomy testowania, typy testów, role i artefakty procesu testowania oraz metody testowania | |
| 5,0 | potrafi objaśnić artchitekturę dokumentu standardu UML, cały proces analizy, projektowania, implementacji i testowania oprogramowania |
Kryterium oceny - umiejętności
| Efekt uczenia się | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_C12_U01 Student umie rozwiązywać zadania inżynierskie z każdego etapu procesu wytwarzania oprogramowania | 2,0 | nie spełnia kryteriów określonych dla oceny 3 |
| 3,0 | umie stosować wybrane podstawowe diagramy UML w celu uzyskania spójnej dokumentacji projektowej, odwzorowywać je w kodzie | |
| 3,5 | umie stosować wszystkie podstawowe diagramy UML w celu uzyskania spójnej dokumentacji projektowej, odwzorowywać je w kodzie | |
| 4,0 | umie stosować dowolne podstawowe diagramy UML w celu uzyskania spójnej dokumentacji projektowej, odwzorowywać je w kodzie; umie identyfikować przypadki testowe i wykorzystywać podstawowe techniki testowe i narzędzia do przedmiotu testowania | |
| 4,5 | umie stosować dowolne podstawowe diagramy UML w celu uzyskania spójnej dokumentacji projektowej, odwzorowywać je w kodzie; umie identyfikować przypadki testowe i wykorzystywać podstawowe techniki testowe i narzędzia do przedmiotu testowania | |
| 5,0 | umie stosować dowolne podstawowe diagramy UML w celu uzyskania zgodnej dokumentacji projektowej, odwzorowywać je w kodzie; umie identyfikować przypadki testowe i wykorzystywać podstawowe techniki testowe do przedmiotu testowania; umie identyfikować metryki niezbędne do szacowania i zarzadzania projektem; umie dostosowywać procesy wytwórcze do konkretnego przedsięwzięcia informatycznego |
Kryterium oceny - inne kompetencje społeczne i personalne
| Efekt uczenia się | Ocena | Kryterium oceny |
|---|---|---|
| I_1A_C12_K01 Student umie współpracować w zespole przy realizacji prostego projektu programistycznego. | 2,0 | |
| 3,0 | Student potrafi pełnić dwie role przy współpracy w zespole przy realizacji prostego projektu programistycznego | |
| 3,5 | Student potrafi pełnić kilka ról przy współpracy w zespole przy realizacji prostego projektu programistycznego | |
| 4,0 | Student potrafi pełnić większość ról przy współpracy w zespole przy realizacji prostego projektu programistycznego | |
| 4,5 | Student potrafi pełnić wszystkie role przy współpracy w zespole przy realizacji prostego projektu programistycznego | |
| 5,0 | Student potrafi wykazać się wysokim poziomem kreatywności w pełnieniu wszystkich ról przy współpracy w zespole przy realizacji prostego projektu programistycznego |
Literatura podstawowa
- Bass L., Clements P., Kazman R., Architektura oprogramowania w praktyce, Helion, Gliwice, 2011, II
- Bernd Bruegge, Allen H. Dutoit, Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java, Helion, Gliwice, 2011
- Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides, Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Helion, Gliwice, 2010
- Larman C., UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji, Helion, Gliwice, 2011, III
- Robert C. Martin, Czysty kod. Podręcznik dobrego programisty, Helion, Gliwice, 2010
- Sacha K., Inżynieria oprogramowania, PWN, Warszawa, 2010
- Sommerville I., Inżynieria oprogramowania, WNT, Warszawa, 2003
Literatura dodatkowa
- Eeles P., Cripps P., The Process of Software Architecting, Addison-Wesley, 2010
- Górski J. (red.), Inżynieria oprogramowania w projekcie informatycznym, Mikom, Warszawa, 2000
- Leffingwell D., Widrig D., Zarządzanie wymaganiami, WNT, Warszawa, 2003
- Steve McConnell, Kod doskonały. Jak tworzyć oprogramowanie pozbawione błędów., Helion, Gliwice, 2010, 2
- Rational Unified Process. Best Practices for Software Development Teams, Rational Software White Paper, Rational Software, 2001
- Sutherland J., Schwaber K., The Scrum Guide. Przewodnik po Scrumie: Reguły gry, 2011