Zum Inhalt springen

  • Beiträge
    72
  • Kommentare
    239
  • Aufrufe
    11.840

Modul: Softwaretechnik 2


kurtchen

565 Aufrufe

 Teilen

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.

 Teilen

5 Kommentare


Empfohlene Kommentare

  • Community Manager
Markus Jung

Geschrieben

Vielen Dank, auch für die fachlichen Hintergründe - ruft manches in Wissen aus dem Studium wieder hervor ;).

Link zu diesem Kommentar

3 Wochen nach der Klausur ist nun auch das Klausur-Ergebnis für "Software-Technik 2" da. Mit 83% der möglichen Punkte fand ich mein Ergebnis eigentlich ganz respektabel. Da ich mir ein paar Bonuspunkte erarbeitet hatte, konnte ich die Note sogar noch ein Stück verbessern. Ein bisschen ärgere ich mich, denn nur 0.25 Punkte mehr und die Note wäre noch ein bisschen besser ausgefallen.

 

In der Präsenzklausur habe ich - so glaube ich - gegeben, was ich geben konnte. Aber speziell im Online-Test wäre noch ein bisschen mehr drin gewesen, weil ich da bei einer Aufgabe geschwächelt habe, die ich eigentlich mit dem Wissen aus dem Kurs problemlos hätte lösen müssen. Das hätte er sein können, der Viertelpunkt zur besseren Note.

 

Ich glaube, mit einem etwas besseren Zeitmanagement in der Präsenzklausur wäre eventuell auch noch ein bisschen mehr drin gewesen. Aber das kann man rückblickend leicht sagen. Man schaut sich die Aufgaben an, sieht, wieviel Punkte zugeordnet sind und fällt eine strategische Entscheidung, wie man sich die Zeit einteilen will. Und natürlich ist es auch nicht hilfreich, den gefassten Plan mehrfach zu ändern.

 

Aber in ein paar Wochen werde ich solche Details nicht mehr wissen. Dann zählt nur noch, dass das Ergebnis unterm Strich ja ganz erfreulich ist. Und nicht, was hätte sein können, wenn dies oder jenes gewesen oder nicht gewesen wäre, was sowieso nichts bringt.

 

Inzwischen bearbeite ich "Software-Technik 3". Finde ich schwieriger und interessanter als SWT2 und etwas leichter als SWT1. Inhaltlich ging es bis jetzt um Entwurfsmuster. Aktuell beschäftige ich mich mit Internationalisierung und Lokalisierung von Software, wofür Java ja schon einige sehr praktische Klassen mitbringt. Ein schöner Kurs bis jetzt. Aber leider noch sehr viel Stoff, der bis zum nächsten Klausurtermin in die Birne muss.

Link zu diesem Kommentar
  • Community Manager
Markus Jung

Geschrieben

vor 23 Stunden, kurtchen schrieb:

Ein bisschen ärgere ich mich, denn nur 0.25 Punkte mehr und die Note wäre noch ein bisschen besser ausgefallen.

 

Lohnt sich bei einem Viertelpunkt vielleicht eine Klausureinsicht?

Link zu diesem Kommentar
kurtchen

Geschrieben

Ich finde nein. Da müsste ich das Gefühl haben, unfair oder nicht nachvollziehbar schlecht bewertet worden zu sein. Und das habe ich definitiv nicht. Ich konzentrier mich aufs Lernen, die Note ergibt sich.

Link zu diesem Kommentar
  • Community Manager
Markus Jung

Geschrieben

Okay. Unfair oder nicht nachvollziehbar nicht, aber gerade bei einem Viertelpunkt könnte ja schon ein kleiner Rechenfehler irgendwo zum Beispiel bei der Addition der Punkte die Lösung bringen etc.

 

Aber wenn es für dich so okay ist und du die Zeit lieber auf das Lernen konzentrierst, ist das auch eine gute Sichtweise.

Link zu diesem Kommentar

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden


×
×
  • Neu erstellen...