Softwaretechnik SS 2015

Beschreibung

Softwaretechnik (oder englisch Software Engineering) ist die Lehre von der Softwarekonstruktion im Großen, also das Grundlagenfach zur Methodik. Die Softwaretechnik ist bemüht, Antworten auf die folgenden Fragen zu geben:

Diese Vorlesung gibt einen Überblick über die Probleme und Lösungsansätze (Methodenlehre) und stellt essentielles Grundwissen für jede/n ingenieurmäßig arbeitende/n Informatiker/in dar.


Organisatorisches

Veranstalter

Voraussetzungen/Zielgruppe, Einordnung, Leistungpunkte etc.

Siehe den Eintrag im KVV.

Die Veranstaltung ist eine Pflichtveranstaltung für die Studiengänge Informatik Diplom und Informatik Bachelor.

Termine und Nachrichten

  • Die Einteilung zu den Übungsgruppen erfolgt über das KVV
  • Ab dem 13.04.15 um 8:00 Uhr ist die Anmeldung zu den Übungsterminen freigeschaltet

  • Der Übungsbetrieb beginnt in der 2. Vorlesungswoche
  • Das 1. Übungsblatt gibt es in der ersten Vorlesungswoche und ist zur zweiten Vorlesungswoche (ab 20.04.15) zu bearbeiten.

Prüfungsmodalitäten

Kriterien für den Erwerb der Leistungspunkte sind

Inhalt

Literatur

Stoffplan

  1. Einführung: 13.04.15
    Einführung
    • Software; Softwaretechnik (SWT); Aufgaben der SWT; Persönlicher Bezug; Beteiligte; Gütemaßstab: Kosten/Nutzen; Qualität; Produkt und Prozess; Prinzip, Methode, Verfahren, Werkzeug; technische vs. menschliche Aspekte; Arten von SWT-Situationen
    • Lernziele; Lernstil
  2. Fallbeispiel: 16.04.15
    Elektronische Gesundheitskarte
    • Einordnung, Anforderungen 'eRezept' (funktionale, Leistungs-, Verfügbarkeits-, Sicherheits-), techn. Ablauf, einige Details, Dokumentenlandkarte, Beteiligte, Nutznießer und Konfliktlinien, Zeitverlauf, Exkurs Digitale Signatur.
    • "Merke"-Hinweise zu: Domänen, nichtfunktionalen Anforderungen, Kooperationsbedarf, Projektrisiko.
  3. Einführung: 20.04.15
    Die Welt der Softwaretechnik
    • Routine und Innovation: Normales und radikales Vorgehen
    • Taxonomie: Probleme und Lösungen
  4. Modellierung: 23.04.15
    Modellierung und UML
    • Modelle und Modellierung (Realität vs. Modell; Phänomene vs. Konzepte); UML; Klassendiagramme; Sequenzdiagramme; Zustandsdiagramme (statechart); Aktivitätsdiagramme; sonstige Diagrammarten (Komponentendiagramme, Kollaborationsdiagramme, Inbetriebnahmediagramme, Kommunikationsdiagramme, Interaktions-Übersichts-Diagramme); UML Metamodell; Profile; einige Notationsdetails (Klassen, Assoziationen, Schnittstellen, Zustände)
  5. Ermitteln WAS: 27.04.15
    Anforderungsbestimmung
    • Erhebung (Requirements Elicitation): Anforderungen und Anforderungsbestimmung (Requirements Engineering); Arten von Anforderungen; Anforderungen und Modellierung; Harte und weiche Systeme; Probleme und Chancen erkennen; Erhebungstechniken (herkömmliche, darstellungs-basierte, soziale, wissenserhebende)
  6. Ermitteln WAS: 30.04.15
    Anwendungsfälle (Use Cases)
    • Was ist ein Use Case?; Wichtige Parameter (Bereich, Detailgrad/Zielniveau); schrittweise Präzisierung; Use-Case-Hierarchien (Überblick, Benutzerziele, Details); Checkliste für Use Cases
  7. Verstehen WAS: 04.05.15
    Analyse (statisches Objektmodell)
    • Von Use-Cases zu Klassen, Abbott's Methode (Substantive sind Kandidaten für Klassen, Verben für Operationen, Adjektive für Attribute, Eigennamen für Objekte, "ist ein" für Vererbung etc.); Checklisten zur Identifikation von Klassen, Assoziationen, Attributen, Operationen, Vererbung; Entwicklerrollen und Modellarten (Analysemodell vs. Entwurfsmodell)
  8. Verstehen WAS: 07.05.15
    Analyse (dynamisches Objektmodell)
    • Klassen finden mit dynamischer Modellierung; Zustandsdiagramme (statechart diagrams); Sequenzdiagramme; Aufbau eines Anforderungsanalyse-Dokuments; Validierung (und Gegensatz zu Verifikation)
  9. Entscheiden WIE: 11.05.15
    Software-Architektur
    • Architektur=Gesamtstruktur; Erfüllen nichtfunktionaler und funktionaler Anforderungen; globale Eigenschaften; wiederverwendbare Architekturen (Standard-Architekturen); Architekturstile (zum Selbstentwickeln von Architekturen); Modularisierung (Modulbegriff, Aufteilungskriterien)
  10. Wiederverwenden WIE: 18.05.15
    Entwurfsmuster, Teil 1
    • Was macht ein Problem schwierig?; Einfachheit durch Wiedererkennen von Mustern; Idee von Entwurfsmustern;
    • Kompositum-Muster (composite pattern); Adapter-Muster (adapter pattern); Brücken-Muster (bridge pattern); Fassaden-Muster (facade pattern)
  11. Wiederverwenden WIE: 21.05.15
    Entwurfsmuster, Teil 2
    • Arten von Entwurfsmustern; Stellvertreter-Muster (proxy pattern); Kommando-Muster (command pattern); Beobachter-Muster (observer pattern); Strategie-Muster (strategy pattern); Abstrakte-Fabrik-Muster (abstract factory pattern); Erbauer-Muster (builder pattern)
  12. Entscheiden WIE: 28.05.15
    Modularisierung
    • Modulbegriff; Kriterien für Aufteilung; Fallstudie: KWIC; KWIC 1: Datenflusskette; Einschätzen der Entwurfsqualität; KWIC 2: Zentrale Steuerung; KWIC 3: Datenabstraktion; Verhalten bei Änderungen; Verwandtschaft mit Architekturstilen
  13. Spezifizieren WIE: 01.06.15
    Schnittstellenspezifikation
    • Sichtbarkeiten (public, protected, private, package), Spezifikation von Voraussetzungen (preconditions) und Wirkungen (postconditions) mit OCL (context, pre, post, inv); Abbildung von Assoziationen in Code
  14. Prüfen OB: 04.06.15
    Analytische Qualitätssicherung, Teil 1
    • Defekttest; Auswahl der Eingaben (Funktionstest, Strukturtest); Auswahl der Testgegenstände (bottom-up, top-down, opportunistisch); Ermittlung des erwarteten Verhaltens (Referenzsystem, (Teil)Orakel); Wiederholung von Tests (Rückfalltesten, Testautomatisierung)
  15. Prüfen OB: 08.06.15
    Analytische Qualitätssicherung, Teil 2
    • Testautomatisierung (Werkzeuge, Strukturierung, JUnit); Stoppkriterien für das Testen; Defektortung; Benutzbarkeitstest; Lasttest; Akzeptanztest; manuelle statische Prüfung (Durchsicht; Inspektion; Perspektiven-basiertes Lesen); automatische statische Prüfung (Modellprüfung; Quelltextanalyse)
  16. Vorbeugen DAMIT: 11.06.15
    Konstruktive Qualitätssicherung (Qualitätsmgmt., Prozessmgmt.)
    • Projekt- vs. Prozessmgmt.; Arten von Prozessmgmt.-Leitlinien; CMM-SW/CMMI (5 Prozessreifestufen); TQM (Prinzip: Kundenzufriedenheit); ISO 9000
  17. Entscheiden WIE (Prozess): 15.06.15
    Prozessmodelle
    • Rollen, Artefakte, Aktivitäten
    • Wasserfallmodell
    • Reparatur 1: Iteration (Prototypmodell, Evolutionäre Modelle, Spiralmodell)
    • Reparatur 2: Flexiblere Planung (Agile Methoden)
    • Prozessmodell-Auswahlkriterien; Anpassbare Prozessmodelle: RUP, V-Modell XT; Erklärung "Agile Methode" (XP)
  18. Randbedingungen: 18.06.15
    Persönlichkeitstyp
    • Was und warum; Die MBTI-Dimensionen (E/I, S/N, T/F, J/P); Warnungen und Hinweise; Die Keirsey-Temperamente (SJ, SP, NT, NF); Andere Typsysteme; Typen und SW-Engineering; Stärken und Gefahren; Typische Tendenzen; Eigenen Typ herausfinden
  19. Umsetzen (Prozess): 22.06.15
    Projektmanagement, Teil 1
    • Was und wofür?; Aufgabenfelder
    • Schätzen (Schätzverfahren; Funktionspunktschätzung); Todesmarschprojekte
  20. Umsetzen (Prozess): 25.06.15
    Projektmanagement, Teil 2
    • Zeit- und Ressourcenplanung; Microsoft Project; Critical Path Method (CPM); Finden von Aufgabenzerlegungen
    • Risikomanagement; Risikolisten; DOs and DON'Ts
  21. Umsetzen (Prozess): 29.06.15
    Projektmanagement, Teil 3
    • Teams; Sportteam oder Chor?; Organisationsstrukturen; Rollen; Kommunikationsstrukturen
    • psychologische Faktoren; Schätzen von Wahrscheinlichkeiten; Motivation; Attribution; Haltungen; soziale Einflüsse
  22. Umsetzen (Prozess): 02.07.15
    Projektmanagement, Teil 4
    • Projektplan; Projektleitung; nichtlineare Dynamik (Brook's Gesetz; Selbstverstärkung von Qualitätsmängeln; Teufelskreis von Qualität und Zeitdruck)
    • Kommunikation (geplant/ungeplant, synchron/asynchron); Medien; Besprechungen
  23. Normales Vorgehen maximieren: 06.07.15
    Wiederverwendung, Teil 1
    • Arten der WV (Produkt/Prozess; Gegenstand; Ziel); Risiken und Abwägung; Hindernisse; Produktivität; WV für normales Vorgehen; Muster; Arten von Mustern; Prinzipien (Abstraktion, Strukturierung, Hierarchisierung, Modularisierung, Lokalität, Konsistenz, Angemessenheit, Wiederverwendung, Notationen)
    • Analysemuster
  24. Normales Vorgehen maximieren: 09.07.15
    Wiederverwendung, Teil 2
    • Benutzbarkeitsmuster
    • Prozessmuster
    • Mustersprachen; Anti-Muster; Werkzeuge
  25. Wissen weitergeben: 13.07.15
    Dokumentation
    • Arten von Dokumentation; Qualitätseigenschaften (übersichtlich, präzise, korrekt, hilfreich); positive und negative Beispiele
    • Prinzipien (Selbstdokumentation, Minimaldokumentation)
    • Begründungsmanagement (Fragen + Vorschläge + Kriterien + Argumente ergeben Entscheidungen)
  26. Berühmte letzte Worte: 16.07.15
    Zusammenfassung
    • Wiederholung aus 1. Vorlesung; Schnelldurchgang durch Stoffplan
    • wichtige nicht besprochene Themen; einige Empfehlungen


Übungen

Übungsblätter

Aktive Teilnahme

Man kann alternativ zum Übungsbetrieb auch ein selbstdefiniertes softwaretechnisches Projekt durchführen und sich dann weitgehend aus dem restlichen Übungsbetrieb ausklinken.
Allerdings Vorsicht: Das nötige Üben für die Klausur liegt dadurch stärker in der eigenen Verantwortung! Details dazu hier.

Projekte

Ein Projekt funktioniert wie folgt:
  1. 3 bis 5 Studierende finden sich zu einem Team zusammen.
  2. Das Team formuliert einen schriftlichen Projektvorschlag: Was wollen wir tun? Warum? Was ist das Ziel des Projekts? Wann gilt das Ziel als erreicht (Kriterien)? Welche Teilaufgaben fallen dafür an? Wer soll welche erledigen? Wie viel Aufwand wird jede verursachen?
  3. Der Tutor stimmt dem Vorschlag zu (oder verlangt Änderungen/Ergänzungen). Projektthemen können beliebige Bereiche der Softwaretechnik betreffen, dürfen aber den Schwerpunkt nicht auf Implementierung haben. Es müssen insbesondere nichttriviale Planungs- und Qualitätssicherungselemente enthalten sein.
  4. Das Team präsentiert den Vorschlag im Tutorium und bittet um Kommentare: Ergänzungs- und Verbesserungshinweise, Warnungen vor Risiken und Fallen, technische Tipps
  5. Das Team führt das Projekt selbständig durch. Der Tutor steht als Ansprechpartner für Tipps oder bei heiklen Entscheidungen zur Verfügung.
  6. Das Team präsentiert dem Tutor das Projektergebnis, wobei alle Teammitglieder eine aktive Rolle übernehmen und auf die meisten Fragen fähig sein müssen, sinnvoll zu antworten.
  7. Der Tutor akzeptiert (hoffentlich) das Ergebnis.
  8. Das Team präsentiert das Ergebnis im Tutorium. Der Tutor entscheidet, ob alle Projektmitglieder ausreichend und gut am Projekt mitgewirkt haben um die Projektarbeit anerkannt zu bekommen.

Quellen

Software

Klausurvorbereitung

Grundsätzlich wird der Stoff der Vorlesung plus Stoff der Übungen geprüft.

Die Übungsblätter geben einen guten Hinweis auf mögliche Aufgaben. Sie waren meistens wie folgt aufgeteilt: In der ersten Aufgabe wurden Begriffe abgefragt. In der Klausur werden diese Begriffe ohne weitere Erläuterung benutzt, aber explizit abgefragt werden sie allenfalls in Richtig/Falsch-Fragen, die insgesamt nur einen kleinen Teil der Klausur ausmachen werden, wenn überhaupt. Die letzten Aufgaben der einzelnen Übungsblätter waren meist Diskussionsanregungen, die in dieser Form schwerlich für Klausuren geeignet sind. Das heißt: Die zwei oder drei Aufgaben dazwischen definieren also den typischen Klausurstoff! Einige der Übungsblattaufgaben sind aus alten Klausuraufgaben hervorgegangen.

Ein Extra-Übungsblatt zur Klausurvorbereitung ist unter den Übungsblättern zu finden, zu dem auch Lösungshinweise gibt. Selbstverständlich kann es in der Klausur auch andere Aufgabenthemen und -typen geben; einige der Aufgaben dort sind aber sogar alte Klausuraufgaben.

Eine weiterer Anlaufpunkt ist das 16-seitige Miniskript zur Veranstaltung, das neben den Kernaussagen auch konkrete Lernhinweise gibt.

Zusätzliches 3-LP-Projekt (nur für Studierende auf Lehramt)

Für das in Ihrem Lehramts-Studienplan geforderte Projekt/Praktikum im Umfang von 3 LP gibt es keine explizite separate lehrveranstaltung. Da es nur wenige betroffene Studierende gibt, suchen wir statt dessen für jede/n von Ihnen eine individuelle Lösung.

Das Format ist angelehnt unter das für den Beitragstyp "Projekt" oben im Abschnitt Übung beschriebene, außer dass hier allein oder zu zweit (anstatt mit 3-5 Personen) gearbeitet wird. Bitte wenden Sie sich entweder mit einer eigenen Projektidee an Ihren Tutor oder mit der Bitte um einen Projektvorschlag an den/die Übungsleiter/in.


Historie des Stoffplans

(Kommentare)

Wenn Sie Anmerkungen oder Vorschläge zu dieser Seite haben, können Sie sie hier (möglichst mit Datum und Name) hinterlassen:

 

SWTIDSR