Uni Wien:Software Engineering 2 VU (Zdun)

Aus VoWi
Zur Navigation springen Zur Suche springen

Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Uwe Zdun, Amirali Amiri, Georg Simhandl, Stephen John Warnett, Robert Sama
ECTS 6,00 / 4,00
Sprache English
Links ufind:051050 , Homepage
Zuordnungen
Bachelor Wirtschaftsinformatik
Bachelor Informatik
Bachelor Lehramt Informatik
Master Lehramt Informatik


Inhalt[Bearbeiten | Quelltext bearbeiten]

noch offen, bitte nicht von TISS/u:find oder Homepage kopieren, sondern aus Studierendensicht beschreiben.

Ablauf[Bearbeiten | Quelltext bearbeiten]

noch offen

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

Basierend auf dem WS22:[Bearbeiten | Quelltext bearbeiten]

  • Selbstständiges Arbeiten
  • Java 11
  • UML, hauptsächlich Klassen- und Komponentendiagramme
  • git
  • Abschluss von SE1 (ohne professionelle dringend empfohlen, die LV kann aber vor oder sogar zur gleichen Zeit wie SE1 besucht werden)
  • Empfohlen: Android Development mit Java (nicht mit Kotlin!)

Vortrag[Bearbeiten | Quelltext bearbeiten]

noch offen

Übungen[Bearbeiten | Quelltext bearbeiten]

noch offen

Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]

Die Lehrveranstaltung besteht aus zwei Teilen:

  • Theoretischer Teil: Stoff der Vorlesung, bestehend aus zwei Prüfungen
  • Praktischer Teil: Entwicklung einer Android App, bestehend aus zwei Meilensteinen
  • Zusatz: "Hands-on Task" - Eine Studie die als "Assignment" verkleidet ist. Ist laut Angaben der Studie selbst nicht verpflichtend, im Moodle jedoch steht, dass die Teilnahme an der Studie verpflichtet ist.
  • Zusatz: Feedback - Abgabe des nicht anonymen Feedbacks auf Moodle

Benotung[Bearbeiten | Quelltext bearbeiten]

  • Es gibt insgesamt 100 Punkte in der Lehrveranstaltung zu erreichen. Mindestens 50% dieser Punkte müssen erreicht werden.
  • Theoretischer Teil: Maximal 47 Punkte erreichbar, mindestens 44% müssen erlangt werden.
  • Praktischer Teil: Maximal 47 Punkte erreichbar, mindestens 44% müssen erlangt werden.
  • Zusatz: "Hands-on Task" - Maximal 5 Punkte erreichbar
  • Zusatz: Feedback - 1 Punkt erreichbar

Prüfungen des theoretischen Teils[Bearbeiten | Quelltext bearbeiten]

Der theoretische Teil wird innerhalb zwei Prüfungen á 60 Minuten ohne angebotener Ersatzleistung geprüft. Es gibt also nur insgesamt zwei Prüfungen; es sei denn, man fehlt aus gesundheitlichen Gründen bei einer von beiden. Es empfiehlt sich also, für beide Prüfungen dementsprechend viel zu lernen, da man keine zweite Chance im Semester bekommt.

Darüber hinaus ist zu erwähnen, dass bei beiden Prüfungen jeweils UML-Diagramme und Java Code per Hand auf ein Blatt Papier zu zeichnen bzw. zu schreiben sind. Unabhängig der didaktischen und bildungswissenschaftlichen Sinnhaftigkeit dieser Aufgabenstellungen empfiehlt es sich, das ganz einfach im Vorhinein zu üben, ansonsten fehlt einem bei den Prüfungen eventuell die Zeit.

Meilensteine des praktischen Teils[Bearbeiten | Quelltext bearbeiten]

Der Praktische Teil ist in zwei Meilensteine gegliedert: DESIGN und FINAL. Nach dem ersten Meilenstein ist der Großteil der Arbeit eigentlich schon getan; bei der Abwicklung des zweiten Meilensteins sorgt man nur für die Vervollständigung der Features, die Abwicklung der Tasks, das Einbauen von Design Patterns, etc. Dabei ist zu achten, dass alle Qualitätsmerkmale, Design Patterns, Aufgabenstellungen, Member Responsibilities, etc. bei der Abgabe des zweiten Meilensteins eingebaut bzw. vervollständigt sind, da diese essentiell für die Benotung des Projekts sind.

Die Benotung bzw. "Bewertung" der Meilensteine selbst ist schwammig und verwerflich. Man bekommt pro Bewertungskriterium ein Schlagwort wie "OK", "MEDIOCRE" oder "ACCEPTABLE" - Weiteres Feedback wird nicht wirklich gegeben, bis auf vielleicht einem oder zwei Sätzen in den "remarks and recommendations."

"OK" - Alle Punkte, die mit OK benotet worden, sind richtig umgesetzt, sagen jedoch nichts von der Qualität aus.

"ACCEPTABLE" - Alle Punkte, die mit ACCEPTABLE benotet worden, sagen aus, dass sich die Umsetzungsqualität im ersten Drittel befindet.

"MEDIOCRE" - Alle Punkte, die mit MEDIOCRE benotet worden, sagen aus, dass sich die Umsetzungsqualität im zweiten Drittel befindet.

"INSUFFICIENT" - Alle Punkte, die mit INSUFFICIENT benotet worden, sagen aus, dass sich die Umsetzungsqualität im dritten Drittel befindet.

Nach welchem Schema und Kriterien nun benotet wird ist ebenfalls intransparent und wird in der Lehrveranstaltung nicht kommuniziert.

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

noch offen

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

Basierend auf dem WS22:[Bearbeiten | Quelltext bearbeiten]

Der Zeitaufwand ist erheblich mehr als 6 ECTS, da man "ins kalte Wasser" von Android Development geworfen wird, ohne in der Lehrveranstaltung eine Einführung bzw. Tutorial o. Tutorium bereitgestellt zu bekommen. Darüber hinaus werden für beide Prüfungen des theoretischen Teils keine Ersatzprüfung bzw. Ersatzleistungen geboten, sollte man eine davon nicht positiv belegen. Deshalb ist es empfehlenswert, sich gut auf beide Prüfungen vorzubereiten, was nochmals einiges an zusätzlichem Aufwand bedeutet.

Es empfiehlt sich also während dieser Lehrveranstaltungen keine anderen aufwändigen Veranstaltungen zu besuchen, vor allem wenn man keine professionelle Programmier-Erfahrung besitzt.

Unterlagen[Bearbeiten | Quelltext bearbeiten]

noch offen

Tipps[Bearbeiten | Quelltext bearbeiten]

  • Genau auf die Aufgabenstellung des Gruppenprojekts achten, diese ist eventuell manchmal mehrdeutig oder schwammig formuliert; sofern es Klärungsbedarf gibt, nicht zögern den Gruppenbetreuer zu fragen
  • Das Auswendiglernen ist für beide Prüfungen des theoretischen Teils empfehlenswert. Es wird kein Verständnis geprüft, sondern das Gedächtnis.
  • Wenn beim ersten Meilenstein (DESIGN) des Gruppenprojekts schon das ganze "Gerüst" der app da ist, erledigt sich der zweite Meilenstein schon fast von selbst.
  • Der Code des Gruppenprojekts selbst wird nicht bewertet - ob die UML-Diagramme schön sind jedoch schon. Man möge deshalb nur auf die Struktur bzw. Architektur der app achten; ob der Code selbst tatsächlich sauber ist, ist für die Bewertung vollkommen egal. (Ob das sinnvoll für einen selbst ist, ist jedoch eine andere Frage.)
  • Man möge darauf achten, die Design Patterns bzw. Entwurfsmuster die in der LV behandelt werden genauestens in den Code einzubauen, auch wenn es in der Architektur der app eigentlich keinen Sinn macht. Das Einbauen der Design Patterns ist Pflicht und spielt eine große Rolle bei der Bewertung.
  • Es ist erlaubt externe Bibliotheken bzw. dependencies im Gruppenprojekt zu verwenden. Das kann je nach Aufgabenstellung bzw. Task von enormer Hilfe sein.
  • Unser Supervisor konnte unsere Fragen oft nicht beantworten und manche Antworten wirkten wie aus dem Ärmel geschüttelt. Besser Fragen in Moodle stellen, dann hat man die Antwort auch schriftlich und kann sich darauf beziehen.

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

noch offen

Materialien

Diese Seite hat noch keine Anhänge, du kannst aber neue hinzufügen.