=Paper=
{{Paper
|id=None
|storemode=property
|title=Iterativ-inkrementelle Vermittlung von Software-Engineering-Wissen
|pdfUrl=https://ceur-ws.org/Vol-956/S3_Paper1.pdf
|volume=Vol-956
|dblpUrl=https://dblp.org/rec/conf/seuh/Thurner13
}}
==Iterativ-inkrementelle Vermittlung von Software-Engineering-Wissen==
https://ceur-ws.org/Vol-956/S3_Paper1.pdf
Iterativ-inkrementelle Vermittlung
von Software-Engineering-Wissen
Veronika Thurner, Hochschule München
thurner@hm.edu
Zusammenfassung re Engineering Body of Knowledge (Abran u. a., 2005),
Viele Ansätze der Software Engineering Lehre behan- der nach den 11 identifizierten Wissensbereichen der
deln in sequenzieller Abfolge die einzelnen Wissensbe- Version von 2004 in der aktuell entwickelten Version
reiche nacheinander. Sie verlaufen damit analog zum 3 auf 15 Wissensbereiche ausgebaut werden wird (IE-
Wasserfallmodell, bei dem ebenfalls einzelne Diszipli- EE, 2012). Diese Erweiterung des SWEBOK ist eines
nen nacheinander erschöpfend abgearbeitet werden, von vielen Indizien dafür, dass mit einer gravieren-
wobei die Sinnhaftigkeit und der Beitrag der dabei den Vereinfachung des Software Engineerings bis auf
erzielten Zwischenergebnisse zum Gesamtergebnis oft Weiteres erst mal nicht zu rechnen ist.
erst relativ spät im Projekt erkennbar wird. Den Lehrenden stellen der Umfang und die Komple-
xität der zu vermittelnden Domäne vor zwei zentrale
In der Praxis komplexer Software Engineering Pro-
Fragen. Die eine, angesichts der in der Regel streng be-
jekte haben sich heute iterativ-inkrementelle bzw. agi-
grenzten verfügbaren Ausbildungszeit unvermeidliche
le Ansätze gegenüber dem Wasserfallmodell durchge-
lauet:
setzt. Dabei wird in kleinen in sich abgeschlossenen
Zyklen, in vielen überschaubaren Schritten und mit • Was lasse ich weg?
kurzen Feedback-Zyklen nach und nach ein System
weiterentwickelt. Oder, positiver formuliert:
Der hier vorgestellte Lehr-/Lernansatz greift diese • Was ist die Essenz, die ich vermitteln muss/will?
Idee auf und überträgt sie auf die Vermittlung von
Die andere, bei diesem Meer von untereinander ab-
Software Engineering Wissen. Dabei wird von der
hängigen Wissensbereichen ähnlich drängende Frage
ersten Lehreinheit an mit einer inkrementellen Folge
ist:
von Beispielsystemen gearbeitet, die quasi bei null
anfängt und sukzessive immer komplexer wird. Jedes • Wo fange ich an?
der enthaltenen Systeme spiegelt dabei eine kleine,
aber vollständige Iteration durch den Software Life Zur ersten Frage existieren bereits diverse allge-
Cycle wider, von der Anforderungsskizze über Entwurf meinere und konkretere Überlegungen, welche die
und Implementierung bis hin zum Test. zugrunde liegende Problematik zwar vielleicht noch
nicht endgültig lösen, aber zumindest Handlungsspiel-
räume aufzeigen (Lehner, 2009).
Motivation Systematische Überlegungen zur zweiten Frage
Software Engineering ist heute eine komplexe und nach dem richtigen Einstiegspunkt und einer sinn-
sehr vielschichtige Disziplin. Entsprechend hoch sind vollen Vermittlungs- bzw. Lernreihenfolge stehen im
die Anforderungen, die an ihre Ausführenden gestellt Fokus der vorliegenden Arbeit.
werden. So sind beispielsweise bereits für die Bewälti- Hierfür wird zunächst die aktuelle Verteilung der
gung kleiner, überschaubarer Projekte Kenntnisse und Lerninhalte auf die einzelnen Fächer im Software-
Kompetenzen in so unterschiedlichen Bereichen wie Engineering-Lernpfad dargestellt und beleuchtet, wel-
Analyse oder Implementierung erforderlich, verbun- che Probleme sich in der Lehr-/Lernpraxis aus der
den mit Modellierungssprachen, Architekturprinzipien derzeit etablierten, am Wasserfallmodell orientierten
und aktuellen Frameworks für die konkrete Umset- Reihenfolge der inhaltlichen Vermittlung ergeben. Dar-
zung. Neben diesen eher technischen Kerndisziplinen auf aufbauend wird kurz die Idee vorgestellt, die
und Wissensbereichen werden darüber hinaus Fähig- Lerninhalte des Software Engineerings nach einem
keiten in Projektmanagement, Vorgehensmodellen etc. iterativen, inkrementellen Prozess zu vermitteln. An-
benötigt, sowie diverse grundlegende überfachliche schließend wird das Beispiel erläutert, anhand dessen
Kompetenzen (Selbst-, Sozial- und Methodenkompe- die einzelnen Lerninhalte schrittweise eingeführt und
tenzen). von den Studierenden in die Praxis umgesetzt wer-
Einen guten Überblick über das Lernspektrum für den. Eine Analyse der ersten mit diesem Lehrkonzept
angehende Softwareingenieure vermittelt der Softwa- gewonnenen Erfahrungen runden die Arbeit ab.
A. Spillner, H. Lichter (Hrsg.): SEUH 13 71
Problemstellung die dabei gefällten Entscheidungen und erstellten Spe-
Den groben Rahmen der Antwort auf die „Wo fange zifikationen letztendlich auf den Quelltext und das zu
ich an?“-Frage definieren im Hochschul-Kontext in der entwickelnde System auswirken bleibt dabei zunächst
Regel die Studienpläne. eine rein theoretische Überlegung, da der Round Trip
zur technischen Umsetzung erst ein Semester später
Einbettung in das Curriculum stattfindet.
Wir betrachten hier als konkretes Beispiel den Studien- Selbst wenn die Software-Engineering-Lehrveran-
gang Bachelor Wirtschaftsinformatik an der Hochschu- staltungen durchgängig über zwei Semester hinweg
le München, der für den Bereich Software Engineering konzipiert und durchgeführt werden bleibt der große
den folgenden Ausbildungspfad vorsieht: zeitliche Abstand zwischen Modellierung und Imple-
• 1. Semester: Softwareentwicklung 1 mentierung problematisch. Letztlich dauert es insge-
Einführung in das objektorientierte Programmier- samt zu lange, bis in den Köpfen der Studierenden
paradigma und die Grundzüge der Programmie- ein rundes Bild der gesamten Disziplinen im Software
rung am Beispiel der Sprache Java Life Cycle entsteht, sodass Zusammenhänge und Ab-
hängigkeiten zwischen den einzelnen Techniken und
• 2. Semester: Softwareentwicklung 2 Disziplinen oft erst sehr spät erkannt werden. Dadurch
Vertiefung der Programmierkenntnisse und Ein- sinkt nicht nur die Lernintensität, sondern auch der
satz fortgeschrittener objektorientierter Program- Spaßfaktor, da der Nutzen vieler Inhalte erst gegen
mierkonzepte am Beispiel der Sprache Java Ende des Entwicklungszyklus deutlich wird.
Falls zwischen dem dritten und vierten Semester
• 3. Semester: Software Engineering 1
dann auch noch der/die Dozierende wechselt und
Objektorientierte Analyse und Entwurf mit
im Praktikum ein anderes Anwendungsbeispiel ver-
UML, Architekturauswahl, Aufwandsschätzung,
wendet kommt der/die Studierende unter Umständen
Qualitäts- und Projektmanagement
überhaupt nicht an den Punkt, an dem selbsterstellte
• 4. Semester: Software Engineering 2 Spezifikationen zu einem laufenden System umgesetzt
Werkzeuge zur Automatisierung der Entwicklung, werden müssen. Dadurch fehlt ein sehr wesentlicher
modellgetriebene Entwicklung, Konfigurationsma- Erkenntnisschritt im gesamten Lernprozess, da die
nagement, Verifikation und Test, Softwarearchi- Studierenden nicht unmittelbar an der eigenen Arbeit
tekturen, Prozessmodelle und agile Vorgehensmo- erfahren, wie sich ihre bei der Modellierung gefällten
delle Entscheidungen bei der Implementierung auswirken
und wieviel Mehraufwand ggf. erforderlich ist, um
Jede dieser Veranstaltungen ist verpflichtend und Modellierungsfehler auszubügeln, die ihren Ursprung
umfasst je zwei Semesterwochenstunden seminaristi- in Anforderungsanalyse und Entwurf haben, aber erst
schen Unterricht und zwei Semesterwochenstunden bei der Implementierung erkannt werden.
Praktikum. An den Praktikumsgruppen nehmen in der
In der aktuellen Lehrpraxis wird daher mitunter
Regel ca. 20 Studierende teil. Der seminaristische Un-
bereits im modellierungslastigen Semester zusätzlich
terricht ist auf ca. 40–50 Studierende ausgelegt, wobei
zur Erstellung eines komplett ausmodellierten Pflich-
hier bedingt durch die aktuellen starken Jahrgänge
tenheftes nebst vollständigen Entwurfsmodellen we-
zum Teil erheblich nach oben abgewichen werden
nigstens eine rudimentäre Umsetzung von Teilen der
muss.
Systemfunktionalität gefordert, auch wenn ein großer
Ergänzt werden diese Pflichtfächer durch ein um-
Teil der dafür benötigten Kenntnisse erst ein Semester
fangreiches Angebot an Wahlfächern, deren Spektrum
später systematisch in der Lehrveranstaltung behan-
von Personalführung bis Webtechniken reicht und die
delt wird. Insbesondere implementierungsschwächere
ab dem 4. Semester besucht werden können.
Studierende sind damit in der Regel völlig überfor-
Auftretende Schwierigkeiten dert.
Obiger Studienplan legt also fest, dass nach einer Die potenziellen Programmiergurus schaffen es da-
Grundausbildung in objektorientierter Programmie- gegen bis zu einem gewissen Grad, sich durch ent-
rung in den Software-Engineering-Veranstaltungen zu- sprechende Rechere und Selbststudium die erforderli-
nächst im 3. Semester die frühen, eher modellierungs- chen Implementierungstechniken anzueignen. Dafür
orientierten Disziplinen sowie Management-Themen machen sie aber im Gegenzug zum Teil erhebliche
behandelt werden, während die eher technischen, im- Abstriche bei der Modellierung, welche jedoch das
plementierungsnahen Disziplinen sowie Vorgehens- eigentliche „offizielle“ Lernziel der ersten Software-
modelle erst im 4. Semester auf der Tagesordnung Engineering-Lehrveranstaltung gewesen wäre. Außer-
stehen. dem wird Software Engineering 2 von diesem Perso-
Diese Aufteilung bewirkt, dass die Studierenden nenkreis dann gerne als langweilig empfunden, weil
also ein Semster lang Anforderungen erfassen und die benötigten Inhalte ja schon zum großen Teil in
analysieren, daraus Entwürfe ableiten und all das mit Software Engineering 1 autodidaktisch erschlossen
umfassenden UML-Modellen konkretisieren. Wie sich wurden.
72 A. Spillner, H. Lichter (Hrsg.): SEUH 13
Software Engineering Lehre nach gegrenzt. Sorgfältige Mitschriften aus so aufgebauten
dem Wasserfallmodell Veranstaltungen können sich gut als Refernz für die
Prüfungsvorbereitung bzw. als Nachschlagewerk eig-
Über ein ganzes Semester hinweg betrachtet sind viele nen, weil alle Informationen, die zu einem Themen-
Software Engineering Lehrveranstaltungen so aufge- bereich gehören, im zugehörigen Kapitel zu finden
baut, dass sie zunächst einen sehr groben Überblick sind.
über den Stoff des gesamten Kurses vermitteln. An- Letzten Endes ist dieser didaktische Ansatz analog
schließend werden Woche für Woche die zu behan- zum Wasserfallmodell im Software Engineering, mit
delnden Themen abgearbeitet, in der Regel streng vergleichbaren Vor- und Nachteilen. So erkauft man
sequenziell hintereinander. Jedes Thema wird dabei sich mit dem Vorteil der klaren Struktur den (gewich-
umfassend und erschöpfend behandelt, bevor zum tigen) Nachteil, dass Querbeziehungen zwischen Lern-
nächsten Thema vorangeschritten wird. inhalten aus frühen und aus späten Lehr-/Lernphasen
Beispielsweise lernen Studierende im Software En- erst sehr spät aufgedeckt werden. Des Weiteren blei-
gineering auf diese Weise also zunächst alle Facet- ben bei der übenden bzw. praktischen Anwendung des
ten der Use-Case-Modellierung kennen. Wenn diese Gelernten die Auswirkungen von Entscheidungen aus
abgeschlossen sind folgen Ablaufbeschreibungen mit- frühen Phasen relativ lange unklar für die Studieren-
tels Aktivitätsdiagrammen. Danach werden Klassen- den, da der Round Trip über den gesamten Software
diagramme durchgenommen, gefolgt von Sequenz- Life Cycle sich oft über mehrere Wochen oder Mo-
diagrammen, und so weiter (Abbildung 1). Wenn die nate hinzieht und die ausführbaren Ergebnisse erst
ganzen Modellierungsthemen abgehandelt sind folgt entsprechend spät vorliegen.
im nächsten großen Themenblock dann die Softwa-
rearchitektur. Iterativ-inkrementelle Vermittlung
von Software Engineering Wissen
Aus diesem Dilemma heraus entstand die Idee, den
Grundgedanken der heute in der Praxis vorherrschen-
den (Rupp u. Joppich, 2009) iterativen, inkrementel-
len Entwicklung auch auf den Lernprozess für ange-
hende Softwareingenieure zu übertragen.
Zur Umsetzung dieses didaktischen Ansatzes vermit-
telt der seminaristische Unterricht genau diejenigen
theoretischen Grundkenntnisse, die für das jeweilge
Inkrement erforderlich sind. Jede Lehr-/Lerneinheit
berührt somit die verschiedenen Kerndisziplinen der
Entwicklung (mit ggf. unterschiedlicher Gewichtung),
also mehrere Entwicklungsschritte, mehrere UML-
Diagrammtypen, mehrere Implementierungskonzepte
und ggf. mehrere Werkzeuge. Dafür wird in einem In-
krement jeder dieser Lernbereiche jeweils nur um ein
kleines Stückchen Information und Wissen erweitert.
Parallel dazu wird im Praktikum ein kleines System
iterativ und inkrementell modelliert und entwickelt.
Jedes Inkrement deckt eine komplette Iteration durch
den Software Life Cycle ab. Die initialen Inkremen-
te sind zunächst sehr klein und einfach und mit viel
detaillierter Anleitung hinterfüttert. Je weiter das Pro-
jekt fortschreitet, umso anspruchsvoller werden die
Inkremente und die dafür benötigten Werkzeuge und
Technologien. Essenziell dabei ist, dass am Ende je-
der Iteration ein lauffähiges System entsteht, anhand
dessen sich die Zusammenhänge zwischen den ein-
zelnen Disziplinen, verwendeten Technologien und
angewendeten methodischen Vorgehensweisen unmit-
Abbildung 1: Lehre nach dem Wasserfallmodell telbar erkennen lassen.
Damit die Studierenden ein Verständnis dafür ent-
Der Vorteil dieses Ansatzes liegt darin, dass die Ver- wickeln, dass sie im Rahmen des Lehrkonzeptes le-
anstaltung klar gegliedert ist. Insbesondere wird je- diglich eines von mehreren möglichen Vorgehensmo-
des Thema umfassend und abschließend behandelt. dellen durchführen wurde entgegen der inhaltlichen
Des Weiteren sind die Themen klar voneinander ab- Aufteilung in der Modulbeschreibung die Themen Pro-
A. Spillner, H. Lichter (Hrsg.): SEUH 13 73
Abbildung 2: Einfaches Inkrement 1
Abbildung 3: Komplexeres Inkrement 2
zessmodelle und agile Vorgehensmodelle aus dem 4.
Semester in das 3. Semester vorgezogen. Im Gegen-
zug wurden die Themen der Aufwandsschätzung und
des Projektmanagements vom 3. in das 4. Semester
verlagert.
Struktur des zentralen Beispiels Abbildung 4: JettyServer mit Standardfehlerseite
Kern des Lehrkonzeptes ist ein durchgängiges Beispiel,
das in Grundzügen vorentwickelt ist und von den
Studierenden im Rahmen des Praktikums sukzessive ren nutzt die Webseite CSS und HTML zur Forma-
erweitert wird. Eine Urversion davon wurde bereits in tierung der Inhalte (siehe Abbildung 5).
(Thurner u. Böttcher, 2010) vorgestellt.
Die folgende Aufzählung skizziert knapp die Funk-
tionalität, die sukzessive in den einzelnen Inkremen-
ten umgesetzt wird. Darauf aufbauend verdeutlicht
Tabelle 1, welche Techniken und Wissensbereiche in
den einzelnen Inkrementen jeweils zum Einsatz kom-
men.
Abbildung 5: Startseite mit variablem Titel
1. Der Administrator startet einen Jetty-Server als
leichtgewichtigen Application Server. Anschlie-
ßend greift der Normalbenutzer über den Brow- 4. Ein erster Button ist das zentrale neue Element der
ser auf den lokalen Port zu, unter dem der nächsten Ausbaustufe (Abbildung 6). Für dessen
Jetty-Server bereit steht. Anhand der angezeig- Umsetzung wird die Verwendung eines Formulars
ten Standard-Fehlerseite ist erkennbar, dass der und eine Listener-Methode eingeführt sowie auf
Application Server im Hintergrund läuft (siehe eine Antwortseite weitergeleitet (Abbildung 7).
Abbildung 4). Die Modellebene wird ergänzt um ein einfaches
Sequenzdiagramm, welches das Zusammenspiel
2. In der zweiten Aufbaustufe wird die Anfrage an der beteiligten Klassen veranschaulicht. Des Wei-
einen Handler weitergeleitet, die als Antwort den teren wird das Aktivitätsdiagramm erweitert zu
minimalistisch formatierten statischen Text „Hello einem noch recht einfachen Ablauf, bei dem Be-
World“ erzeugt. nutzer und System in mehreren Schritten mitein-
ander interagieren.
3. Das nächste Inkrement führt das Zusammenspiel
von Java-Klasse und parametrisierter Webseite ein. 5. Darauf aufbauend umfasst das nächste Inkrement
Dabei ist das titel-Attribut der Java-Klasse an die ein Textfeld, in das der Benutzer seinen Namen
$titel-Variable der Webseite gebunden. Des Weite- eingeben kann (Abbildung 8). Nach Absenden
74 A. Spillner, H. Lichter (Hrsg.): SEUH 13
Abbildung 6: Startseite mit Button
Abbildung 8: Startseite mit Texteingabefeld
Abbildung 7: Statische Antwortseite
Abbildung 9: Personalisierte Begrüßungsseite
der Anfrage über den Button erscheint eine per-
sonalisierte Begrüßungsseite (Abbildung 9). Für dessen möglichst simpel anzufangen und die nachfol-
deren Umsetzung wurde der eingegebene Daten- genden einzelnen Inkremente angemessen klein zu
wert in der Session abgelegt und zum Generieren halten. Dazu wurde das ursprüngliche Beispiel (Thur-
der Antwortseite wieder ausgelesen. ner u. Böttcher, 2010) solange sukzessive immer wei-
ter abgespeckt und vereinfacht, bis es nur noch die
6. Die nächste Ausbaustufe bietet dem Benutzer wesentlichen zu zeigenden Inhalte, Techniken und
auf der Startseite zwei Buttons an und er- Zusammenhänge umfasst.
laubt so eine Auswahlmöglichkeit (Abbildung 10). Die daraus resultierende minimalisierte Version von
Entsprechend wird das Aktivitätsdiagramm um Spezifikation und System war für den Einstieg jedoch
die Konzepte der Fallunterscheidung und des Er- immer noch viel zu komplex. Daher wurde in einem
eignisses erweitert. Auch das Sequenzdiagramm zweiten Schritt, noch einmal ganz von vorne mit ei-
wird um alternative Blöcke ergänzt. nem leeren Projekt anfangend, eine Folge von Spezifi-
kationen und Systemen erstellt, die von der Komple-
7. Das folgende Inkrement realisiert eine Login- xität und vom Funktionsumfang her bei null anfängt
Möglichkeit über eine Gastkennung. Dazu wird und in winzigen Einzelschritten sukzessive aufgebaut
das System um eine neue Komponente erweitert, wird. Am Ende dieser Folge steht die minimalisierte
die die Business Services kapselt. Zur Qualitätssi- Version, auf die das urspüngliche umfangreiche Bei-
cherung der Business Services wird deren Funk- spiel zuvor eingedampft worden war.
tionalität mit Hilfe von Unit-Tests abgesichert. Die Nach den bisher gewonnenen ersten Erfahrun-
GUI erhält als neues Element ein Passwort-Feld. gen kommen die Studierenden gut mit dem iterativ-
Zu den bisher bekannten Notationselementen in inkrementellen Lernansatz zurecht. Insbesondere wer-
Aktivitäts- und Sequenzdiagrammen werden nun den die Zusammenhänge zwischen den einzelnen Dis-
Rückkopplungen über join-Knoten bzw. Wiederho- ziplinen und Techniken schneller und deutlicher wahr-
lungsblöcke hinzugefügt. genommen als beim eher sequenziell orientierten Auf-
bau früherer Veranstaltungen. Des Weiteren erschei-
8. Weitere Ausbaustufen fokussieren Schritt für nen durch die relativ kleinen Schritte von Inkrement
Schritt die Realisierung von Entity-Klassen, deren zu Inkrement die Studierenden weniger überfordert,
Persistierung in einer Datenbank sowie die Um- als dies beispielsweise beim in der Vergangenheit an-
setzung von Menüs zur Benutzerführung. Parallel gewendeten Lehransatz mit Gruppenpuzzle und Ler-
zu den Konzepten der technischen Umsetzung nen durch Lehren der Fall war.
werden auch hier die benötigten Modellierungs- Dadurch, dass beim iterativen Vorgehen bereits be-
notationen sukzessive weiter ausgebaut. handelte Inhalte und Wissensbereiche immer wieder
aufgegriffen und inkrementell weiter ausgebaut wer-
Erste Erfahrungen den, werden außerdem die Kerninhalte regelmäßig
Der hier vorgestellte Lehr-/Lernansatz wird in diesem wiederholt und scheinen sich so besser einzuprägen.
Semester erstmals auf diese Weise an der Hochschule Nachteilig beim iterativ-inkrementellen Lehr-
München erprobt. /Lernansatz ist, dass bei dieser Vorgehensweise die In-
Die zentrale Herausforderung in der Vorbereitungs- formationen zu den einzelnen behandelten Themenbe-
phase bestand darin, in jedem Schritt jeweils nicht reichen (wie z. B. einzelne Diagrammtypen der UML)
zuviel Lernstoff auf einmal anzugehen, sondern statt quer über die Lehrmaterialien verteilt sind, da jedes
A. Spillner, H. Lichter (Hrsg.): SEUH 13 75
Wissens- Inkr. 1 Inkr. 2 Inkr. 3 Inkr. 4 Inkr. 5 Inkr. 6 Inkr. 7
bereich
Use Case Akteur, System-
Diagramm Use Case, grenze,
Assoziati- Business
on / System
Use Case
Use Case textuelle Normal- Alternativer
Beschrei- Kurzbe- ablauf, Ablauf
bung schrei- Fehlerfall
bung,
Vorbe-
dingung,
Ergebnis
Aktivitäts- Start, Stop, Schwimm- Folge von Fallunter- Wieder-
diagramm Aktion, bahn Aktionen scheidung, holung
Kontroll- Ereignis
fluss
Kompo- Kompo- Schnittstelle
nenten- nente,
diagramm Beziehung
Sequenz- Kommunika- Nachricht Alternative Schleifen-
diagramm tionspartner, mit Metho- Blöcke Block
Lebens- denaufruf,
linie, Antwort
Nachricht,
Aktionsse-
quenz
Webtechni- Webappli- HTML, CSS, Tren- Weiterleiten Konzept
ken kation HTTP, nung von auf Ant- der Sessi-
Request, Darstel- wortseite on, Daten-
Response, lung und transfer
Bedeutung Logik über Sessi-
Servlet on
Architektur Bedeutung Handler Schichten- Listener- Business
Applica- architektur Methode Service
tion Server
GUI- Startseite, Rendering, Textfeld Passwort-
Framework Zusammen- onInit(), Feld,
(Apache spiel Klas- Form, Fehlermel-
Click) se und Control, dung
Webseite, Button
@Bindable
Attribut,
$Variable
Unit-Test Unit-Tests
für den
Business
Service
Tabelle 1: Wissenselemente, die in den ersten Inkrementen der Systemfolge behandelt werden
76 A. Spillner, H. Lichter (Hrsg.): SEUH 13
Veranstaltung durch die enge Verzahnung zwischen
Modellierung und Umsetzung erheblich gestiegen ist,
ebenso wie deren Verständnis für die Notwendigkeit
und die Aussagekraft der "bunten Bildchen".
Die Teilkohorte der implementierungsschwächeren
Studierenden hatte dagegen teilweise erhebliche Pro-
bleme mit der Bewältigung der Praktikumsaufgaben.
Durch die Notwendigkeit, die erstellten Modelle un-
mittelbar in ein lauffähiges System umzusetzen, wur-
Abbildung 10: Auswahlmöglichkeit durch zwei But- den Lücken aus den implementierungsnahen Grundla-
tons genfächern erneut evident. Darüber hinaus erzwang
die drohende Umsetzung der Modelle bereits eine
Thema mehrfach und in zunehmenden Detaillierungs- hohe Sorgfalt und Präzision in den Diagrammen, wel-
stufen aufgegriffen wird. che bei einer reinen Modellierungsaufgabe nicht im
Abhilfe lässt sich hier schaffen durch Bereitstellung gleichen Maße zweifelsfrei offensichtlich geworden
entsprechender Begleitliteratur, sofern diese themen- wäre. Es war daher aufgrund dieser engen Verzah-
weise aufgebaut ist. Auch die Erstellung eines ergän- nung weniger leicht möglich, sich durch die Aufgaben
zenden Skriptes wäre natürlich denkbar, war jedoch “irgendwie durchzuwursteln", was bei einigen Studie-
aus Zeitgründen vor dieser ersten Umsetzungsphase renden zu einer deutlich realistischeren Einschätzung
noch nicht möglich. Statt dessen werden die Studie- des eigenen Leistungsstandes geführt hat. Das war
renden dazu angeleitet, sich als Nachschlagewerk ei- teilweise sehr heilsam, hat aber bei einigen auch zu
gene Zusammenfassungen zu den einzelnen Themen- nicht unerheblichem Frust geführt.
gebieten zu erstellen und diese semesterbegleitend
kontinuierlich auf- und auszubauen. Diese dürfen (auf Zusammenfassung und Ausblick
5 beidseitig beschriebene A4-Blätter beschränkt) dann Der hier vorgestellte iterativ-inkrementelle Lehr-
als Hilfsmittel in die Prüfung mitgenommen werden. /Lernansatz für Wissensbereiche und Kompetenzen
Die obigen Aussagen spiegeln ausschließlich den des Software Engineerings stellt eine Möglichkeit dar,
Eindruck wider, den die Dozentin in den Lehrveran- die umfangreichen und stark miteinander verzahnten
staltungen und aus Gesprächen mit den Studierenden Themengebiete so aufzuschlüsseln, dass die einzelnen
gewonnen hat. Prüfungsergebnisse, die als Kennzahl Lehr-/Lerneinheiten einerseits nicht überfrachtet sind
für die Bewertung des Lernerfolgs herangezogen und und andererseits die Zusammenhänge zwischen den
mit den Ergebnissen anderer Ansätze verglichen wer- Wissensbereichen frühzeitig deutlich erkennbar und
den könnten, liegen zum aktuellen Zeitpunkt jedoch für die Studierenden auch selbst praktisch nachvoll-
noch nicht vor. ziehbar werden.
In vergangenen Durchführungen der Lehveranstal- Erste Erfahrungen aus der Umsetzung des Ansatzes
tung Software Engineering 1 lag der Fokus überwie- verlaufen bisher vielversprechend. Aktuell werden der
gend auf der Modellierung und den frühen Phasen, Lehransatz und die benötigten Materialien kontinu-
wie in der Modulbeschreibung vorgegeben. Durch das ierlich erweitert und ausgebaut. Eine Messung des
iterativ-inkrementelle Lehrkonzept sind Aspekte der Lernerfolges über Prüfungsleistungen steht derzeit
Implementierung stärker in den Vordergrund gerückt. noch aus.
Dies wird sich in der Gestaltung der Prüfung entspre- Interessant ist des Weiteren auch die Frage, ob
chend widerspiegeln, um dadurch die von den Stu- der systemimmanente hohe Wiederholunganteil des
dierenden erworbenen Kompetenzen im Bereich des iterativ-inkrementellen Lehr-/Lernansatzes auch die
Zusammenspiels von Modellierung und Implementie- Nachhaltigkeit des Gelernten positiv beeinflusst. Um
rung zu bewerten. hier eine Aussage treffen zu können ist jedoch eine
Bei der initialen Umsetzung des Lehrkonzeptes er- Langzeitstudie mit entsprechenden Vergleichsgruppen
wies sich die Granularität der einzelnen Inkremen- erforderlich.
te immer wieder als zentraler Knackpunkt. War die
Menge an neuen Konzepten klein genug und deren Literatur
Anbindung an bereits erarbeitetes Vorwissen ausrei- [Abran u. a. 2005] A BRAN, A. ; M OORE, J. ; D UPUIS,
chend, so erforderte die anschließende Betreuung der R. ; T RIPP, L.: Guide to the Software Engineering
Studierenden in den Praktika in etwa vergleichbaren Body of Knowledge 2004 Version SWEBOK. IEEE
Aufwand wie in den Vorjahren. Erwies sich die Granu- Computer Society Press, 2005
larität bzw. Komplexität des Inkrementes dagegen als
zu hoch, schnellte der Betreuungsaufwand extrem in [IEEE 2012] IEEE, Computer-Society: Software En-
die Höhe. gineering Body of Knowledge, vorläufiger Stand der
Des Weiteren war zu beobachten, dass die Motivati- Version 3. www.computer.org/portal/web/swebok,
on der implementierungsstarken Studierenden in der abgerufen am 28.10.2012, 2012
A. Spillner, H. Lichter (Hrsg.): SEUH 13 77
[Lehner 2009] L EHNER, M.: Viel Stoff – wenig Zeit.
Haupt Verlag, Stuttgart, 2009
[Rupp u. Joppich 2009] R UPP, C. ; J OPPICH, R.:
Dokumentenberge oder Bierdeckel – Requirements
Engineering in Zeiten der Agilität. heise Developer,
http://www.heise.de/developer/artikel/Requirements-
Engineering-in-Zeiten-der-Agilitaet-804971.html,
abgerufen am 28.10.2012, 2009
[Thurner u. Böttcher 2010] T HURNER, V. ; B ÖTTCHER,
A.: Beispielorientiertes Lernen und Lehren im Soft-
ware Engineering. In: ESE 2010: Embedded Software
Engineering Kongress, 2010, S. 591–595
78 A. Spillner, H. Lichter (Hrsg.): SEUH 13