Welche Rolle spielt Softwaretechnik 2 im Studium?

Das Modul "Softwaretechnik 2" wird - wenig überraschend - dem Studienbereich "Softwaretechnik" zugerechnet, der in den Studiengängen von Springer Campus einen recht großen Raum einnimmt. Das Modul ist Pflicht, sowohl im Studiengang "Web- und Medieninformatik" als auch im Studiengang "Wirtschaftsinformatik". Als inhaltliche Voraussetzung gilt das Modul "Softwaretechnik 1", bei dem es um Basistechniken und die Basiskonzepte Statik, Dynamik und Logik geht. Dieser Einschätzung würde ich mich anschließen. In SWT1 wird vor allem eine solide Grundlage in UML vermittelt, die man in SWT2 braucht. Springer Campus empfiehlt, auch das Modul "Softwaremanagement 1" vorher zu belegen, weil es das Verständnis von SWT2 erleichtere. Dazu kann ich nichts näheres sagen, weil ich SWM1 nicht vorher belegt hatte. Ich hatte den Eindruck, mit dem Stoff gut zurecht zu kommen und SWM1 als Grundlage nicht unbedingt zu brauchen. Möglicherweise wären mir die Kursabschnitte zur Aufwandsschätzung so leichter gefallen.

SWT2 ist auch ein Pflichtmodul in den Weiterbildungszertifikaten "Requirements Engineer", "Software-Architekt" und "Software-Manager". Wer sich für eine dieser wissenschaftlichen Weiterbildungen interessiert, sei es als Etappenziel auf dem Weg zum Bachelor oder auch als eigenständige Weiterbildung, der muss sich mit den Inhalten dieses Moduls beschäftigen.

Das Lehrbuch

Inhaltlich geht es in SWT2 um Requirements Engineering, Aufwandsabschätzung und die Modellierung von Anforderungen. Ein neues Lehrbuch bekommt man nicht. Man bearbeitet die verbleibenden Kapitel vom (hervorragenden) "Lehrbuch der Softwaretechnik - Basiskonzepte und Requirements Engineering" von Helmut Balzert, welches ja schon SWT1 zu Grunde lag. Während SWT1 mit über 400 Seiten ein umfangreicher Kurs war, fällt SWT2 mit nur ca. 150 restlichen Seiten deutlich kompakter aus. Ich habe den Eindruck, dass sich das nicht ganz im Zeitaufwand niederschlägt. Viele Kapitel zum Requirements-Engineering sind vergleichsweise trockene Themen, durch die man sich mühsam durchbeißen muss. In SWT1 nahmen große UML-Diagramme viel Raum auf den Seiten ein, so dass man oft schneller voran kam. Dieses Modul ist etwas textlastiger. Gleichwohl scheint mir, dass der Arbeitsaufwand ungleichmäßig verteilt ist. Ich hätte es besser gefunden, die Kapitel zur Logik aus SWT1 noch SWT2 zuzuteilen. Allerdings ginge dabei die klare thematische Gliederung der Module verloren. Wahrscheinlich muss man sich damit abfinden, dass die Module trotz formal gleichem Workload mal anstrengender und mal etwas leichter ausfallen. Dies bezieht sich allerdings nur auf den Arbeitsumfang. Inhaltlich ist SWT2 anspruchsvoll und relevant.

Requirements Engineering

Beim Requirements Engineering geht es im wesentlichen um das Erfassen von Anforderungen für Software-Projekte. In der Vergangenheit sind immer wieder große Software-Projekte spektakulär gescheitert. Ein wesentlicher Grund war, dass die Anforderungen an das Produkt zu Beginn nicht präzise ermittelt wurden, Entwurf und Implementierung also schon vorangeschritten waren, als wesentliche Anforderungen erst bekannt wurden. So etwas endete oft damit, dass sich der erstellte Code als unbrauchbar erwiest, weil der Entwurf schon in den Grundzügen an den Anforderungen vorbei ging. Die nötigen Änderungen wären teurer gewesen als ein kompletter Neubeginn. Requirements Engineering beschäftigt sich mit Techniken und Vorgehensweisen, um relevante Anforderungen zu Beginn eines Projektes (und im laufenden Projekt) zu ermitteln, um ausufernde Kosten, Terminverzögerungen oder gar ein Scheitern des Projektes zu vermeiden.

Das klassische Vorgehen ist ein dreistufiges. Die Anforderungen werden aus Kundensicht definiert. Das Ergebnis ist ein Lastenheft, das i.d.R. auch Angebotsgrundlage ist. Dann werden die Anforderungen aus dem Lastenheft spezifiziert. Das Ergebnis ist das deutlich umfangreichere Pflichtenheft, zu dem auch Abnahmekriterien gehören. Die im Pflichtenheft spezifizierten Anforderungen werden dann klassischerweise in eine fachliche Lösung in Form eines OOA-Modells überführt. Damit sind wir aber schon im Bereich Anforderungs-Modellierung.

Es gibt aber auch agile Softwareentwicklung. Hier ist das Ziel mit möglichst wenig Dokumenten außer dem Code auszukommen. Ein Kunde oder Kundenrepräsentant wird ins Entwicklungsteam integriert, die Anforderungen werden in Form von User Stories erhoben, die beschreiben, was das Softwaresystem für die Benutzer leisten soll. Kennzeichnend für agile Entwicklung ist, dass die Anforderungen nicht vollständig vor sondern nach und nach während des Projektes ermittelt werden.

Der inhaltliche Fokus von SWT2 liegt aber klar auf dem klassischen sequentiellen Vorgehen. Im Rahmen der Einsendeaufgaben erstellt man auch selbst ein Lasten- und ein Pflichtenheft, was sich vergleichsweise lange hinzieht und ungewohnt viel Schreibarbeit ist. Hier geht es unter anderem darum, Anforderungsschablonen anzuwenden, die eine klare inhaltliche Gliederung vorgeben und zum Teil auch mit einheitlichen Formulierungen arbeiten. Hier muss man sich ein bisschen disziplinieren. Man muss zum Beispiel sehr präzise unterscheiden, was ein System leisten SOLL und was es leisten MUSS. Beim Pflichtenheft ist es wesentlich, Abnahmekriterien zu formulieren, die eindeutig überprüfbar sind. Hier kam es mir tatsächlich einmal zu Gute, dass ich eine pädagogische Ausbildung habe. Bildungs- und Förderziele sollten ebenfalls so formuliert sein, dass sie konkretes und beobachtbares Verhalten beschreiben, damit man nachprüfbar ist, ob der Lernende sie erreicht hat. Schwammige Formulierungen wie "das Sozialverhalten der Schüler soll sich verbessern", lassen viel Interpretationsspielraum. Man kann mir so zwar nicht beweisen, dass meine Maßnahme wirkungslos war, aber ich kann umgekehrt auch nicht beweisen, dass ich etwas erreicht habe. Hier sah ich also eine gewisse Analogie, die mir das Verständnis erleichterte.

Aufwandsschätzung

In den folgenden Kapiteln geht es um das Schätzen des Entwicklungsaufwandes. Das ist ein sehr wichtiger Schritt, weil ein Unternehmen, das Software entwickelt, dem Kunden ein Angebot machen muss. Schätzt man den Aufwand zu hoch ein, geht der Kunde zu einem günstigeren Mitbewerber und man bekommt den Auftrag nicht. Schätzt man ihn zu niedrig ein, sind die Entwicklungskosten höher als der vereinbarte Preis und man verliert Geld. Eine möglichst gute Aufwandsschätzung ist also wesentlich für den wirtschaftlichen Erfolg, auch wenn es gute Gründe geben kann, eine Software unter den tatsächlichen Entwicklungskosten anzubieten. Zum Beispiel weil man damit in eine neue Anwendungsdomäne vordringen kann und sich eine Codebasis erarbeitet, die man in künftigen, ähnlichen Projekten wiederverwenden kann. Solche Entscheidungen sollte man dann aber bewusst und strategisch treffen.

Aufwandsschätzung ist leider alles andere als einfach. Im Kurs lernt man verschiedene Schätzverfahren kennen, wozu auch algorithmische Verfahren wie Function Points oder Object Points gehören. Viele der Verfahren sind selbst recht aufwendig, so dass allein die Durchführung der Schätzung schon beträchtliche Kosten verursacht. Auch formalere Verfahren wie Functions Points müssen mit Erfahrungswerten aus dem Unternehmen sozusagen kalibriert werden, um ermittelte Aufwandspunkte in Entwicklermonate umrechnen zu können. Hier spielen viele Faktoren eine Rolle. Eine Rolle spielt zum Beispiel die Erfahrung der Entwickler mit ähnlichen Projekten, der Anteil von Code, der wiederverwendet werden kann, aber auch die Sprache, in der entwickelt werden soll.

Natürlich darf man nicht erwarten, allein auf Grundlage eines Studienmoduls in der Lage zu sein, eine Aufwandsschätzung vorzunehmen. Man lernt Methoden kennen, mit denen Unternehmen versuchen, dieses Problem zu lösen. Man lernt relevante Begriffe und Konzepte. Und man entwickelt ein Bewusstsein, für die damit verbundenen Probleme. Einsendeaufgaben hier beinhalten z.B. das Bestimmen von Function Points für ein skizziertes Projekt.

Anforderungen modellieren

Im letzten Kursabschnitt geht es um objektorientierte Analyse, also das Erstellen eines OOA-Modells auf Grundlage einer Spezifikation. Wichtigstes Ergebnis ist in der Regel ein UML-Klassendiagramm, das die Statik des Systems modelliert. Der Kurs vermittelt 10 sogenannte OOA-Muster, wiederkehrende Formen der Verknüpfung von Klassen, mit charakteristischer Semantik und charakteristischen Multiplizitäten. Hier muss man wieder Diagramme zeichnen und dieser Kursteil war dann schon wieder lebendiger und näher dran an der Programmierung. Für mich persönlich war das der Teil des Kurses, der mir am meisten Spaß gemacht hat. Eine typische Einsendeaufgabe hier wäre das Wiedererkennen der behandelten Muster in kleinen Spezifikationen, die man modellieren soll.

Prüfungen

Online-Test und Online-Klausur deckten die Inhalte des Kurses noch einmal breit ab. Eine kleine Warnung vorweg: Ich hatte ein Lastenheft mit Glossar zu schreiben. Da steckt viel Schreibarbeit drin und es ist nicht ganz einfach, sich die Zeit gut einzuteilen. Hier habe ich Punkte verschenkt, weil ich mich mit Schreiben zu lange aufgehalten habe und die verlorene Zeit beim Modellieren nicht mehr rausholen konnte. Hilfreich wäre vielleicht, gewisse Text- und UML-Schablonen schon griffbereit zu haben.

Ich hatte den gleichen Tutor wie in SWT1. Auch in SWT3 er mich voraussichtlich wieder begleiten. Die Kurse bauen aufeinander auf und es ist sehr schön, hier einen kontinuierlichen Ansprechpartner zu haben, der einen durch einen längeren Lernprozess begleitet.

Die Präsenzklausur deckte die Inhalte breit ab, wenn auch mit unterschiedlicher Gewichtung. Ich hatte relativ viel Modellierung, was mir eigentlich Spaß gemacht hat. Mal sehen, ob ich das auch in eine gute Note umsetzen konnte. Der Zeitdruck war im Vergleich zur Online-Klausur geringer, so dass die Online-Klausur hier als gute Vorbereitung gelten kann. So ist es mir am liebsten.

Ausblick

Ich bin nun sehr gespannt auf SWT3, wo es unter anderem um Entwurfsmuster gehen wird. Laut meinem Tutor wird dort auch wieder mehr programmiert. Darauf freue ich mich schon richtig.