.svg)
Softwaretechnik ist kein Auswendiglern-Fach: So wählst du das richtige UML-Diagramm, vergleichst Vorgehensmodelle und leitest Testfälle sicher ab.
"Die Softwaretechnik-Klausur fragt nicht, ob du die 14 UML-Diagrammarten kennst, sondern ob du aus einem Anforderungstext ein Modell bauen kannst."
Softwaretechnik gilt als das Fach, das man „einfach lernt": Vorgehensmodelle auswendig, Diagrammarten aufzählen, fertig. In der Klausur steht dann ein halbseitiger Anforderungstext, aus dem du ein Klassendiagramm entwickeln sollst — und genau dort gehen die Punkte verloren. Die Modulbeschreibungen sagen es deutlich: geprüft wird Anwenden, nicht Aufzählen. Dieser Leitfaden zeigt dir, welche Teile des Stoffs du als Handwerk üben musst und in welcher Reihenfolge.
Ein Blick in zwei Modulhandbücher reicht, um den Ruf zu widerlegen. An der Universität Passau umfasst das Modul „Software Engineering" 5 Kreditpunkte bei 2 Vorlesungs- und 1 Übungsstunde pro Woche; der Arbeitsaufwand ist mit 45 Stunden Präsenz, 30 Stunden Übungsaufgaben und 75 Stunden Nachbearbeitung und Prüfungsvorbereitung angesetzt und endet in einer 90-minütigen Klausur. Zwei Drittel der vorgesehenen Zeit liegen also außerhalb des Hörsaals — bei einem Fach, dessen Stoff auf den Folien täuschend einfach aussieht.
Als angestrebte Kompetenz nennt Passau ausdrücklich, kleinere Softwaresysteme projektieren, Qualität beurteilen und qualitätsverbessernde Maßnahmen auswählen zu können. Das sind Entscheidungen, keine Fakten. An der Hochschule Esslingen steht im Studiengang Softwaretechnik und Medieninformatik parallel dazu, dass Studierende in der Lage sein sollen, „zwischen einem plangetriebenen oder agilen Vorgehensmodell zu entscheiden" und eine Software-Spezifikation sowie einen Entwurf selbst zu erstellen. Auch dort schließt das Modul mit einer 90-minütigen Klausur ab, begleitet von Laborübung und Projektmanagement-Seminar.
Daraus folgt die Lernstrategie: Alles, was in den Lernzielen mit „entscheiden", „erstellen", „ableiten" oder „beurteilen" beschrieben ist, musst du an Beispielen üben. Nur der kleinere Rest — Begriffe, Normnamen, Diagrammtypen — ist echtes Abruffragen-Material. Wer nur den Abrufteil lernt, bereitet sich auf ein Drittel der Klausur vor.
Die UML-Spezifikation der Object Management Group in Version 2.5.1 (verabschiedet im Dezember 2017) definiert 14 Diagrammarten, aufgeteilt in sieben strukturelle und sieben verhaltensbezogene. Diese Zahl verunsichert viele — zu Unrecht, denn der Klausurstoff ist deutlich kleiner. Das Esslinger Modul listet als UML-Inhalte Use-Case-, Klassen-, Objekt-, Sequenz-, Aktivitäts- und Zustandsdiagramme sowie die Beziehungen Assoziation, Multiplizität, Qualifizierung, Generalisierung, Aggregation und Komposition. Sechs Diagrammarten und eine Handvoll Kantentypen — das ist der realistische Umfang.
Entscheidend ist nicht, jedes Diagramm zeichnen zu können, sondern zu erkennen, welche Sorte eine Aufgabenstellung verlangt. Die Signalwörter in der Aufgabe sagen es dir:
| Signalwort in der Aufgabe | Passendes Diagramm | Was du zeigen musst |
|---|---|---|
| „wer nutzt das System wofür" | Use-Case-Diagramm | Akteure außerhalb, Systemgrenze, fachliche Anwendungsfälle |
| „welche Begriffe und Beziehungen" | Klassendiagramm | Klassen, Attribute, Assoziationen mit Multiplizitäten |
| „Zustand zu einem Zeitpunkt", Beispieldaten | Objektdiagramm | konkrete Instanzen mit Werten statt Typen |
| „Ablauf zwischen Beteiligten", „Nachricht" | Sequenzdiagramm | Lebenslinien, Reihenfolge, Rückgaben |
| „Prozess", „Verzweigung", „parallel" | Aktivitätsdiagramm | Aktionen, Entscheidungsknoten, Synchronisation |
| „reagiert auf Ereignis", „Modus" | Zustandsdiagramm | Zustände, Transitionen mit Auslöser und Bedingung |
Übe das als Zuordnungsaufgabe: Nimm alte Klausuraufgaben, lies nur die Aufgabenstellung und notiere die Diagrammart samt Begründung, ohne zu zeichnen. Zehn Aufgaben in zwanzig Minuten trainieren genau die Entscheidung, an der in der Klausur die ersten Punkte hängen.
Die klassische Modellierungsaufgabe gibt dir einen Fließtext und verlangt ein Klassendiagramm. Mit einem festen Ablauf wird daraus eine mechanische Übung statt einer Eingebung:
Dieses Vorgehen ist nahe verwandt mit dem ER-Modellieren aus der Datenbankvorlesung. Wenn dir Schritt 2 und 4 schwerfallen, lohnt der Umweg über den Leitfaden zum Datenbanken lernen mit ER-Modell und Normalisierung — dieselbe Denkweise, nur mit anderer Notation. Umgekehrt braucht Softwaretechnik kaum Programmierhandwerk; wenn dort Lücken sind, sind sie im Modul Programmieren lernen in den ersten zwei Semestern besser aufgehoben.
Klausurfragen zu Vorgehensmodellen lauten selten „Nenne die Phasen des Wasserfallmodells", sondern „Welches Modell passt zu dieser Projektsituation und warum?". Dafür brauchst du je Modell drei Dinge: den Kern, die Stärke und die Bruchstelle.
| Modell | Kern | Passt, wenn … | Bruchstelle |
|---|---|---|---|
| Wasserfall | Phasen streng nacheinander, Dokument als Übergabe | Anforderungen stabil und vorab bekannt | spät erkannte Fehler sind teuer, keine Rückkopplung |
| V-Modell | jeder Spezifikationsstufe steht eine Teststufe gegenüber | Nachweispflicht, Abnahme gegen Spezifikation | hoher Dokumentationsaufwand, wenig Flexibilität |
| Scrum | empirisch: kurze Zyklen, Inspektion und Anpassung | Anforderungen unklar oder veränderlich | braucht verfügbare Fachseite und echte Priorisierung |
Zwei Primärquellen ersparen dir hier das Lernen aus zweiter Hand. Das V-Modell XT Bund in Version 2.3, herausgegeben vom Informationstechnikzentrum Bund, beschreibt sich selbst als Vorgehensmodell zum Planen und Durchführen von Systementwicklungsprojekten und arbeitet mit Entscheidungspunkten sowie mit Tailoring, also der Anpassung an die konkrete Projektsituation. Genau diese zwei Begriffe werden gern geprüft — und sie zeigen, dass das V-Modell kein starres Phasenschema ist.
Für Scrum ist der Scrum Guide von Ken Schwaber und Jeff Sutherland (Stand November 2020) die verbindliche Quelle. Er kennt drei Verantwortlichkeiten im Scrum Team — Developer:innen, Product Owner:in, Scrum Master:in — und fünf Events: den Sprint als umschließenden Rahmen sowie Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Dazu die drei Artefakte Product Backlog, Sprint Backlog und Increment mit ihren Commitments. Wer diese Begriffe sauber beherrscht, kann jede Vergleichsfrage beantworten, ohne Lehrbuchkapitel auswendig zu lernen.
Der Testteil ist der dankbarste Abschnitt des Fachs, weil er fast immer nach Schema geht. Die internationale Norm ISO/IEC/IEEE 29119-4 (Ausgabe 2021) unterscheidet spezifikationsbasierte Verfahren — darunter Äquivalenzklassenbildung und Grenzwertanalyse — von strukturbasierten Verfahren wie Anweisungs- und Zweigtest, und definiert jeweils das zugehörige Überdeckungsmaß. Der deutschsprachige ISTQB-Lehrplan Certified Tester Foundation Level in Version 4.0.1a verwendet dieselbe Einteilung unter den Begriffen Black-Box- und White-Box-Testverfahren.
So gehst du eine typische Aufgabe an:
Rechne drei bis vier solche Aufgaben vollständig durch, dann sitzt das Verfahren. Für die Begriffsschicht darunter — welche Teststufe prüft was, welches Verfahren ist spezifikations- und welches strukturbasiert — eignet sich Abfragen besser als Lesen. Wenn du Skript und Übungsblätter in Learnboost zu einem Lernplan verarbeitest, bekommst du daraus Karteikarten für genau diese Begriffsschicht, während du die Rechenwege von Hand übst.
Der Stoff ist breit, aber gut portionierbar. Ein Rhythmus, der zu den im Modulhandbuch vorgesehenen Stunden passt:
Dass Abfragen dem Wiederlesen überlegen ist, ist gut belegt: Jeffrey Karpicke fasst in seiner Übersichtsarbeit „Retrieval-Based Learning: A Decade of Progress" (2017) den Forschungsstand dahin zusammen, dass aktives Abrufen aus dem Gedächtnis zu dauerhafterem Behalten führt als erneutes Durcharbeiten desselben Materials. Für Softwaretechnik heißt das konkret: Diagramm aus dem Kopf zeichnen, dann mit der Musterlösung vergleichen — nicht die Musterlösung noch einmal ansehen. Wie du die Fehlerauswertung systematisch aufsetzt, zeigt der 5-Schritte-Plan für Algorithmen und Datenstrukturen, der mit derselben Logik arbeitet.
Behandle Softwaretechnik als Entscheidungsfach: Diagrammart aus Signalwörtern bestimmen, Klassendiagramme in sechs festen Schritten aus dem Anforderungstext herleiten, Vorgehensmodelle über Kern, Stärke und Bruchstelle vergleichen, Testfälle nach Norm-Schema ableiten und Überdeckung ausrechnen. Jeden dieser vier Blöcke übst du an Beispielen, nicht an Folien. Die Begriffsschicht darunter — Diagrammtypen, Normbegriffe, Scrum-Events — deckst du mit Abfragen ab. Lade dein Skript und die Übungsblätter in Learnboost hoch, wenn du daraus automatisch Karteikarten, Zusammenfassungen und Probeklausuren für diesen Abrufteil willst; die Modellierungsaufgaben bleiben deine Übung, und genau sie entscheiden die Note.
Der Stoff selbst ist nicht mathematisch anspruchsvoll, der Ruf als Auswendiglern-Fach führt aber in die Falle. Die Modulhandbücher nennen als Lernziel, zwischen Vorgehensmodellen zu entscheiden und Spezifikationen selbst zu erstellen - das sind Anwendungsaufgaben. Schwer wird es nur, wenn du den Modellierungsteil nicht an Beispielen übst.
Die UML-Spezifikation kennt 14 Diagrammarten, geprüft werden in der Regel sechs: Use-Case-, Klassen-, Objekt-, Sequenz-, Aktivitäts- und Zustandsdiagramm. Dazu kommen die Beziehungstypen Assoziation, Multiplizität, Generalisierung, Aggregation und Komposition. Wichtiger als das Zeichnen ist die Entscheidung, welche Diagrammart eine Aufgabe verlangt.
Für ein typisches Modul mit 5 Kreditpunkten rechnen die Hochschulen mit rund 150 Stunden pro Semester, davon nur etwa ein Drittel Präsenzzeit. Verteilt auf das Semester sind das rund zehn Stunden pro Woche inklusive Übungsblatt. Das Fach wird während des Semesters bestanden, nicht in der Woche vor der Klausur.
Lege pro Modell eine Karte mit drei Feldern an: Kern, Stärke und Bruchstelle. Damit kannst du jede Vergleichsfrage beantworten, auch wenn die Projektsituation in der Klausur neu ist. Für V-Modell und Scrum lohnt der Blick in die Primärquellen, weil dort die geprüften Begriffe wie Tailoring, Entscheidungspunkt oder Sprint Retrospective genau definiert sind.
Anweisungsüberdeckung misst den Anteil der durch Testfälle durchlaufenen Anweisungen, Zweigüberdeckung den Anteil der durchlaufenen Verzweigungen im Kontrollfluss. Beide gelten als strukturbasierte beziehungsweise White-Box-Verfahren. Wichtig für Multiple-Choice-Fragen: 100 Prozent Anweisungsüberdeckung bedeuten nicht automatisch 100 Prozent Zweigüberdeckung.
