Kompetenzorientierte Lehre im Software Engineering
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Kompetenzorientierte Lehre
im Software Engineering
Axel Böttcher und Veronika Thurner, Hochschule München
ab | thurner@cs.hm.edu
Gerhard Müller, TNG Technology Consulting GmbH
gerhard.mueller@tngtech.com
Zusammenfassung steigt (Spitzer, 2006). Da dieser Entwicklung alleine
Software Engineering ist eine komplexe Aufgabe, die mit erhöhter Packungsdichte in der Wissensvermitt-
von den Beteiligten ausgeprägte Kompetenzen in vie- lung nicht mehr beizukommen ist, ist zwangsweise
len verschiedenen Bereichen fordert. Die Vermittlung Selektion erforderlich. Eine „gute“ Selektion wird so-
dieser Kompetenzen über das reine Fachwissen hin- mit zu einer der wesentlichen Herausforderungen bei
weg ist eine zentrale Aufgabe, die eine Software- der Konzeption der Software-Engineering-Ausbildung.
Engineering-Ausbildung leisten muss, um Absolventen Im Folgenden definieren wir zunächst kompeten-
für den Einsatz in der Praxis zu qualifizieren. Ausge- zorientierte Lernziele für die Software-Engineering-
hend von den zu vermittelnden Kompetenzen zeigen Ausbildung. Diese basieren im Wesentlichen auf drei
wir, wie wir in unserer Lehrpraxis mit Hilfe eines mög- Quellen:
lichst einfach gehaltenen, aber so komplex wie nötig • klassischer Software-Engineering-Literatur,
gestalteten durchgängigen Beispiels sowie durch in-
novative Lehrmethoden praxisnah eine fundierte Ein- • einer umfangreichen Befragung von Absolventen
führung in die komplexen Tätigkeiten des Software unserer Fakultät aus den letzten fünf Jahrgängen
Engineerings vermitteln. sowie
• Aussagen von Spezialisten aus der beruflichen Pra-
Motivation xis über die Eigenschaften und Fähigkeiten, die
sie von potenziellen neuen Mitarbeitern/innen er-
Anforderungen an Softwaresysteme werden heute zu-
warten.
nehmend umfangreicher und komplexer. Analog dazu
entwickeln sich auch die Technologien und Werkzeuge Im Anschluss daran beschreiben wir ein Beispielpro-
für Software Engineering stetig weiter und werden im- jekt und die zugehörigen Lehrkonzepte, die wir in den
mer mächtiger – und damit selbst komplexer. Da sich Bachelor-Studiengängen Informatik sowie Wirtschafts-
diese Technologien und Werkzeuge laufend weiter informatik einsetzen. Abschließend setzen wir die mit
entwickeln, ist die Halbwertzeit der dazu erworbenen unserem Lehrkonzept gemachten Erfahrungen in Be-
Kompetenzen entsprechend kurz. ziehung zu den zuvor definierten Kompetenzzielen.
Aufgrund der Menge und Komplexität des erfor-
derlichen Wissens und wegen der Größe der zu er- Definition von Lernzielen
stellenden Systeme wird Software in der heutigen Grundlage einer adäquaten Selektion von Ausbil-
Praxis nahezu immer im Team entwickelt. Neben den dungsinhalten und -methoden ist die Definition der zu
rein technisch-fachlichen Kompetenzen werden da- erreichenden Lernziele. In der Regel stellt die Definiti-
mit in zunehmendem Maße auch Fähigkeiten wichtig, on dieser Lernziele bereits selbst eine Auswahl dar, da
die sich mit der Positionierung einer Einzelperson im in der meist begrenzten verfügbaren Zeit realistischer
Team sowie mit der Integration und Interaktion aller Weise nicht immer alle eigentlich gewünschten Ziele
Beteiligten untereinander befassen. erreicht werden können (Lehner, 2009).
Eine Software-Engineering-Ausbildung, die nicht Ausbildung und Lernziele müssen sich dabei zum
nur theoretisch fundiert, sondern auch praxisnah einen an Kompetenzen auf unterschiedlichen Wissens-
und berufsbefähigend sein soll, muss diesen Entwick- gebieten orientieren. Zum anderen sollen sie die Stu-
lungen Rechnung tragen. Hier stößt die Lehre sehr dierenden auf die Übernahme verschiedener Rollen
schnell auf das heute bereits klassische Dilemma, vorbereiten. Analog zu Schott und Ghanbari (Schott
dass die verfügbare Lernzeit in der initialen Ausbil- u. Ghanbari, 2009) betrachten wir Kompetenzen als
dungsphase eines Menschenlebens seit Jahren in etwa diejenigen Eigenschaften und Fähigkeiten, die man be-
konstant bleibt, die Menge des verfügbaren und als sitzen muss, um eine bestimmte Menge von Aufgaben
wichtig empfundenen Wissens aber exponentiell an- sinnvoll ausführen zu können.
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 33 von 44Softwarekompetenzen (SWEBOK) Inf WI • Modellierung und Entwurf
Requirements ++ ++ Um eine „ordentliche“, d.h. professionelle und
Design ++ ++ nachhaltige Softwareentwicklung rein technisch-
Construction ++ + handwerklich überhaupt zu ermöglichken müssen
Testing ++ + Software-Ingenieure/innen modellieren und desi-
Maintenance – – gnen können. Dazu gehören unter anderem auch
Configuration Management o o das Verständnis für bzw. der Einsatz von Design
Engineering Management o + Patterns, SOLID-Prinzipien und ggf. Domain Dri-
Engineering Process + ++ ven Development (Evans, 2003).
Engineering Tools and Methods + +
• Beschreibung von Architekturen
Quality + + Software-Ingenieure/innen müssen in der Lage
sein, technische und fachliche Architekturen zu
Tabelle 1: Unsere Prioritäten für die Vermittlung der konzipieren und so darzustellen, dass sie als klar
Kompetenzen (– –, –, o, +, ++) in den Bachelor- verständliche Grundlage für die Kommunikation
Studiengängen Informatik (Inf) und Wirtschaftsinfor- aller Projektbeteiligten dienen können.
matik (WI) • Einarbeitung in große, fremde Projekte
Softwaresysteme entstehen heute häufig im
Kontext bereits bestehender Systemlandschaf-
Als Grundlage für die Definition von zu vermitteln- ten. Eine wichtige Fähigkeit von Software-
den Kompetenzen und daraus abzuleitenden Lernzie- Ingenieuren/innen ist somit die Einarbeitung in
len, empfiehlt sich zunächst der „Software Enginee- umfangreiche fremde Projekte. Typische Aufga-
ring Body of Knowledge“ (Abran u. a., 2005). Die dort benstellung ist das Bug-Fixing in fremdem Code,
genannten Kompetenzfelder haben wir für die Durch- aber auch das Einbauen neuer Features in ein be-
führung der Lehre in den Bachelor-Studiengängen In- stehendes System.
formatik und Wirtschaftsinformatik priorisiert und in
Tabelle 1 zusammengefasst. Der Themenbereich „Soft- • Gesamtsicht auf Zusammenspiel von Frameworks
ware Maintenance“ wird aktuell nur am Rande adres- Moderne Softwaresysteme sind gekennzeichnet
siert. Das liegt unter anderem daran, dass Software durch das Zusammenwirken vieler Bibliotheken
Maintenance zum einen sehr technologiespezifisch ist und Frameworks. Jeder dieser Bausteine ist für
und zum anderen stark auf anderen Kompetenzen auf- sich genommen nicht schwierig zu verstehen. Die
baut. Diese müssen somit zuerst vermittelt werden, Integration dieser Frameworks in einem Produkt
bevor diese Thematik auf technisch anspruchsvollem erhöht die Komplexität jedoch sprungartig. Ent-
Niveau behandelt werden kann. sprechend müssen diese Bausteine in der Lehre
nicht nur einzeln, sondern auch in ihrer Gesamt-
Als ergänzende Informationsquelle haben wir eine
sicht vermittelt werden.
Umfrage herangezogen, die unter unseren Absolven-
ten der Informatik und Wirtschaftsinformatik der letz- • Test Driven Development
ten Jahre durchgeführt wurde – also unter Personen, Test Driven Development ist in der heutigen Praxis
die sich bereits mit den bei uns erworbenen Fähigkei- eine Basistechnik der professionellen, nachhalti-
ten in der Industrie bewähren müssen. Darüber hinaus gen Softwareentwicklung. Damit einher gehen das
befragten wir erfahrene Praktiker aus der Industrie, Erlernen eines sauberen Designs, Continuous In-
welche konkreten Anforderungen die Praxis an unsere tegration, Refactoring und Techniken wie das Pair
Absolventen stellt. Die auf diese Weise identifizierten Programming.
Kompetenzbedarfe gliedern wir im Folgenden nach
den vier Bereichen Sach-, Methoden-, Selbst- und Sozi- • Verständnis für Lebensdauer von Code
alkompetenz (vergleiche (Schaeper u. Briedis, 2004)). Die Praxis zeigt, dass der Quelltext geschäftsrele-
Dabei ordnen wir Kompetenzen, die mehr als einen vanter Softwaresysteme oft über Jahrzehnte im
dieser Bereiche bedienen, demjenigen Kompetenzbe- Einsatz bleibt. Entsprechend müssen Software-
reich zu, zu dem sie nach unserer Einschätzung den Ingenieure/innen ein Verständnis für die Lebens-
stärksten Beitrag leisten. dauer von Code entwickeln die Wichtigkeit von
Informationen erkennen, die in „Clean Code“ be-
Sachkompetenz schrieben sind (Martin, 2008). Daarüber hinaus
müssen Sie in der Lage sein, selbst sauberen Code
Der Bereich der Sachkompetenz fokussiert das erwor- zu schreiben. Ebenfalls erforderlich ist ein Veständ-
bene Fachwissen und dessen zielgerichtete Anwen- nis für die Kosten von Zeit.
dung. Hierzu zählen die in Tabelle 1 aufgelisteten
Kompetenzbereiche aus dem SWEBOK. Diese wurden • Größenordnungen verstehen
aus der Praxis durch die folgenden Kompetenzforde- In der Praxis bestimmen nicht-funktionale Re-
rungen ergänzt. quirements oft zu ca. 80% die Systemarchitek-
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 34 von 44tur, während die funktionalen Anforderungen im • „Faulheit", DRY-Prinzip
Vergleich dazu eine eher untergeordnete Rolle Das Prinzip des „Don’t Repeat Yourself“ bedeutet,
spielen. Um auf systematische Weise adäquat im Normalfall keine eigenen Frameworks bauen
performante Systemarchitekturen konzipieren zu wollen, Erkennen der Notwendigkeit Automatisie-
können müssen Software-Ingenieure/innen ein rung auf allen Ebenen in möglichst großem Um-
Gefühl für Größenordnungen entwickeln, bei- fang eu erreichen. Software lebt von der Wieder-
spielsweise bzgl. algorithmischer Komplexität, An- verwendung bewährter Konzepte und Lösungen.
zahl der Transaktionen pro Sekunde, Speicher- Die so genannten „Not Invented Here“-Lösungen
bedarf pro Session, IO-Geschwindigkeit, CPU- bedeuten eine Verschwendung von Ressourcen.
Geschwindigkeit, Bandbreite, Ressourcenbedarf
pro Benutzer oder in Summe, ... Darüber hinaus • Vernünftiges Maß an Pragmatismus
ist ein Verständnig für die Auswirkungen dieser In der beruflichen Praxis müssen ständig Entschei-
Werte erforderlich sowie die Fähigkeit, ggf. pas- dungen getroffen werden, ob etwa die Menge der
sende Konsequenzen daraus herzuleiten. Ohne Tests ausreichend ist, ob ein noch abstrakteres Fra-
dieses Verständnis werden die erarbeiteten Lösun- mework einzusetzen ist, oder ob an einer Stelle
gen nicht auf angemessene Weise skalierbar. noch mehr Optimierungsaufwand getrieben wer-
den soll etc. Um in solchen für ein Projekt kriti-
• Aufwandsschätzung schen Fragen vernünftig abwägen zu können, ist
Aufwandsschätzungen bilden nicht nur die Grund- viel Erfahrung erforderlich.
lage für viele planerischen und organisatorischen
Tätigkeiten im Software Engineering, sondern • Prägnantes Dokumentieren von Anforderungen
beispielsweise auch für die Entscheidung zwi- Die in Projekten auftretenden Probleme sind oft-
schen verschiedenen Realisierungsalternativen. mals weniger technischer Natur als vielmehr or-
Um verlässliche Aussagen zu Machbarkeit, Zeit- ganisatorischer Art. Software-Ingenieure/innen
und Ressourcenbedarf treffen zu können müssen müssen oft zuerst herausfinden, welches Problem
Software-Ingenieure/innen Aufwände auf realis- der Kunde eigentlich gelöst haben will. Hier ist
tisch treffende Weise schätzen können. es insbesondere wichtig, Requirements kurz und
• Vorgehensmodelle prägnant aufschreiben zu können.
Der in der Theorie gelegentlich verfolgte Grund-
gedanke eines universell einsetzbaren Vorgehens- • Ausdrucks- und Schreibfähigkeit
modells („One size fits all“) funktioniert in der Software-Ingenieure/innen müssen in der Lage
Praxis in der Regel nicht. Entsprechend müssen sein, aussagekräftige, klar verständliche Doku-
Software-Ingenieure/innen verschiedene Vorge- mente und Dokumentation zu schreiben. „Ordent-
hensmodelle wie z.B. Scrum, XP, Crystal-Familie, liche“ Dokumente sind in der Praxis eine zentrale
RUP und V-Modell-XT kennen und deren Vor- bzw. Voraussetzung dafür, dass Lösungen bzw. Lösungs-
Nachteile und Einsatzgebiete einschätzen können. ideen von den Beteiligten verstanden und von den
Insbesondere sind Kompetenzen sowohl zu klas- Nutzern akzeptiert und eingesetzt werden und
sisch ingenieurwissenschaftlichen als auch zu ak- dass Lösungen weiterentwickelbar sind, ggf auch
tuellen agilen Vorgehensmodellen von Nöten. über einen längeren Zeitraum und mehrere Ent-
wicklergenerationen hinweg.
• Beherrschung grundlegender Werkzeuge
Damit alle Beteiligten auf technischer Ebene Selbstkompetenz
reibungsfrei zusammen arbeiten können ge- Zum Bereich der Selbstkompetenz zählen Fähigkeiten,
hört die Beherrschung grundlegender Werkzeuge die eigene Situation wahrzunehmen, eigene Bedüfnis-
zum elementaren Handwerkszeug von Software- se zu erkennen und zu artikulieren, eigenverantwort-
Ingenieuren/innen, wie beispielsweise die verwen- lich zu handeln und über all diese Punkte selbstkri-
dete IDE oder die Versionsverwaltung incl. Kennt- tisch und konstruktiv zu reflektieren.
nissen zu geeigneten Branching-Strategien.
Methodenkompetenz • Reflexions- und Kritikfähigkeit
Reflexions- und Kritikfähigkeit sind Grundvoraus-
Im Bereich der Methodenkompetenz sind grundlegen-
setzungen für eine erfolgreiche Berufstätigkeit,
de Arbeitstechniken zusammengefasst, sowie Fähig-
nicht nur im Umfeld des Software Engineerings.
keiten und Verfahren, die ein effektives, ergebnisori-
Ziel der Reflektion ist es, sich selbst und die
entiertes Arbeiten ermöglichen.
(Projekt-)Umgebung immer wieder zu hinterfra-
• Denken in Systemen gen, um so sicherzustellen, dass „das Richtige“
Wer nicht in übergeordneten Strukturen denkt, getan wird. Kritikfähigkeit ermöglicht es, das ggf.
beschränkt sich auf lokale Optimierungen und kritische Feedback Anderer nicht als persönlichen
tendiert dazu, „echte“ Probleme nicht anzugehen. Angriff zu werten, sondern als Verbesserungspo-
Strukturprobleme anzugehen erfordert auch Mut. tenzial anzuerkennen und daraus zu lernen. Auch
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 35 von 44das Geben von konstruktiv verwertbarem Feed- der Fähigkeit, sinnvoll, effektiv und gerne (!) in ei-
back ist in diesem Kontext eine wesentliche Schlüs- nem Team zusammenzuarbeiten eine fundamenta-
selkompetenz. le Bedeutung zu: Wer das nicht kann, kann nichts
von dem, was er/sie kann, sinnvoll im komple-
• Dinge „richtig“ machen xeren Umgebungen einbringen. Zu den zentra-
Die Informatik allgemein, und damit auch das len Teilfähigkeiten gehören unter anderem eher
Software Engineering, erfordern nicht nur eine pragmatische Punkte wie ein freundlicher Um-
präzise Denkweise und ein hohes Maß an Wis- gangston, nett sein und zuhören können. Gerade
sen, sondern auch eine ständige Aktualisierung in kritischen Situationen gewinnt darüber hinaus
dieses Wissens, um mit den ständig neuen Ent- theoretisch fundiertes Wissen über Team-Regeln
wicklungen Schritt halten zu können. Der Wunsch, an Bedeutung, wie beispielsweise das Tucker-
Dinge „richtig“ zu machen, gepaart mit dem Stre- Modell, das Vier-Ohren-Modell von Schulz von
ben nach lebenslangem Lernen und Verbessern, Thun. Ebenfalls nützlich sind Change Manage-
sollte in Software-Ingenieuren/innen intrinsisch ment, wie z.B. (Rising u. Manns, 2004), sowie
motiviert sein. Ohne diese Eigenschaft werden die ein Grundstock an psychologischem Grundwissen,
vielen Innovationen und die steigende Komplexi- wie beispielsweise in (Vigenschow u. Schneider,
tät eher als Belastung empfunden und nicht als 2007) beschrieben.
Anreiz. In einer solchen Konstellation kann die In-
formatik mit ihren vielen Änderungen auf Dauer Nicht alle dieser eigentlich wünschenswerten Kom-
keinen Spaß machen – und dann werden auch petenzen können in der zur Verfügung stehenden Lehr-
keine vernünftigen Ergebnisse erzielt. und Lernzeit im vollen Umfang vermittelt werden. In
den Kompetenzbereichen, die wir nicht vollständig
• Ethisches Handeln bedienen können, soll unsere Ausbildung zumindest
Softwaresysteme durchziehen heute nahezu al- das Bewusstsein für die Notwendigkeit dieser Kompe-
le Bereiche des beruflichen und privaten Le- tenzen wecken, indem sie deutlich macht, für welche
bens. Damit beeinflusst die Informatik in ho- Aufgaben, Disziplinen und Rollen diese Kompetenzen
hem Maße, wie andere Menschen leben und ar- erforderlich sind.
beiten. Software-Ingenieure/innen gestalten so-
mit mehr oder weniger direkt die Zukunft. Dies Lehrkonzept
bringt nicht nur eine kaum absehbare Vielzahl an
Um dem Curriculum der von uns bedienten Bachelor-
(Geschäfts-)Möglichkeiten mit sich, sondern auch
Studiengänge „Informatik“ und „Wirtschaftsinforma-
ein sehr hohes Maß an Verantwortung für die Rol-
tik“ mit nur einem Beispiel gerecht zu werden konzi-
le der Informatik in der Welt. Eine ganzheitliche
pierten wir dieses als eine moderne Webapplikation.
Software-Engineering-Ausbildung sollte in ange-
Bislang kommt dieses Beispiel in folgenden Modulen
henden Software-Ingenieuren/innen zumindest
zum Einsatz, deren Umfang jeweils bei zwei SWS se-
das Bewusstsein für diese Verantwortung wecken,
minaristischem Unterricht und zwei SWS Praktikum
sowie ein gewisses Maß an kritischem Weitblick
liegt und mit fünf ECTS-Punkten gewichtet ist:
aufbauen und fördern.
Sozialkompetenz (Soft Skills) • Modul „Software Engineering I“ im 3. Semester
des Bachelorstudiengangs Wirtschaftsinformatik
Der Bereich der Sozialkompetenz fokussiert schließ-
lich die Fähigkeit, die Bedürfnisse und Interessen an- • Modul „Software Engineering II“ im 4. Semester
derer Menschen wahrzunehmen, sich mit diesen aus- des Bachelorstudiengangs Wirtschaftsinformatik
einander zu setzen und konstruktiv und erfolgreich
mit anderen Menschen zusammenzuarbeiten. • Modul „Software-Architektur“ im 4. Semester des
Bachelorstudiengangs Informatik
• Verständnis für Andere
Software entsteht nicht in einem luftleeren Raum, Die zu Größe der zu unterrichtenden Gruppen liegt
sondern durch die Zusammenarbeit verschiedens- bei etwa 45 Studierenden. Für das Praktikum werden
ter Gruppen, wie beispielsweise Management, Be- die Gruppen jeweils noch einmal geteilt.
nutzer, Fachexperten, QA, Operations und vielen Thematisch bildet das Beispiel ein Verleihsystem
anderen. Schon die Zielfindung in einem Entwick- namens ShareIt ab, über das ein Freundes- und Be-
lungsprojekt erfordert intensive Kommunikation kanntenkreis dingliche Ressourcen unterschiedlicher
zwischen den Beteiligten sowie eine offene Wahr- Art (wie z.B. Bücher, DVDs, Werkzeug, etc.) unterein-
nehmung der Belange und Interessen aller Betei- ander verleihen bzw. gemeinschaftlich nutzen kann.
ligten. Technisch ist die Beispielapplikation als klassische
drei-Schicht-Architektur realisiert. Fachlich gliedert
• Teamfähigkeit sich das Beispiel bisher in die Hauptbereiche „Benut-
In der Praxis ist Software heutzutage fast immer zerverwaltung“, „Verwaltung der Leihobjekte“ und
das Produkt eines Teams. Entsprechend kommt „Ausleihe“ (siehe Abbildung 1).
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 36 von 44Studierenden den im ersten Teil spezifizierten fachli-
Verschiedene
Benutzerrollen
chen Schnitt implementieren. Als Vorgabe erhalten sie
eine referenzimplementierung des ersten Schnittes.
Fachliche Schnitte Software-Architektur: Lernziel ist hier die Fähig-
keit, moderne Architekturen für komplexe Software-
Benutzer- Leihobjekte Objekte
verwaltung verwalten ausleihen
.... Systeme zu bewerten, zu entwerfen, zu realisieren
und zu betreiben (kompetenzbereiche design. Con-
struction, Testing). Die Studierenden bekommen für
User den ersten fachlichen Schnitt sowohl eine Spezifikati-
Schichten (Layers)
Interface
on als auch deren Implementierung als Vorgabe. Sie
Dienste müssen den zweiten fachlichen Schnitt implementie-
(Business- ren und bekommen dazu die Spezifikation als Vorga-
Logik)
be.
Als Lehrmethode im seminaristischen Unterricht
Daten-
zugriff wurde eine Mischung aus interaktiver Vorlesung, Ler-
nen durch Lehren, Gruppenpuzzle und Projektarbeit
in wechselnden Teams eingesetzt.
Datenbank Abgleich Lehrkonzept vs. Lernziele
Nach den bisherigen Erfahrungen adressiert unser
Lehrkonzept eine Vielzahl der Schlüsselkompetenzen,
Abbildung 1: Struktur des durchgängigen Beispiels die aus der Praxis geforderten wurden.
Sachkompetenz
Für den ersten fachlichen Schnitt, die Benutzerver- Die Studierenden durchlaufen im Rahmen der Projekt-
waltung, werden Planung, Analyse- und Entwurfsdo- arbeit mindestens einen kompletten Softwareentwick-
kumente, Implementierung und umfangreiche Tests lungszyklus, vom Skizzieren erster Anforderungen bis
den Studierenden als Lernmaterialien zur Verfügung hin zum Integrationstest. Das vorgefertigte, durchgän-
gestellt. Diese dienen sowohl als veranschaulichendes gige Beispiel hilft dabei, neu eingeführte Techniken
Beispiel als auch als Vorlage für die von den Studie- und deren zielgerichtete Verwendung zu veranschau-
renden durchzuführenden Projektarbeiten. lichen. Des Weiteren dient es als Anhaltspunkt für
Der zweite fachliche Schnitt „Verwaltung der Leih- die Lösungsbestandteile, welche die Studierenden im
objekte“ ist ebenfalls ausgearbeitet, je nach Fokus der Rahmen ihrer Projektarbeit nach und nach selbst ent-
Lehrveranstaltung aber nur teilweise oder gar nicht für wickeln.
die Studierenden verfügbar. In der Lehrveranstaltung Das Beispiel ist aktuell auf der Basis von Servlets
„Softwarearchitektur“ (Bachelor Informatik) erhalten implementiert. Als Frameworks kommen Hibernate,
die Studierenden die vorgefertigten Analyse- und Ent- Google Guice (Dependency Injection), Apache Click,
wurfsdokumente, die sie anschließend in eine funkti- Log4j und Selenium zum Einsatz. Die zugehörigen
onsfähige Implementierung umsetzen. In „Software Technologien und Frameworks werden in der Lehrver-
Engineering“ (Bachelor Informatik und Wirtschaftsin- anstaltung sukzessive vermittelt und von den Studie-
formatik) dagegen erstellen die Studierenden selbst renden bei der Erstellung ihrer eigenen Lösungsanteile
die benötigten Analyse- und Entwurfsdokumente und entsprechend weiterverwendet.
setzen anschließend ihre eigene Spezifikation um. Bei Für die Modellierung stehen verschiedene Mo-
Bedarf ist das Beispiel um zusätzliche fachliche Schnit- dellierungswerkzeuge zur Verfügung, beispielswei-
te erweiterbar. se der IBM Rational Software Modeler oder die
Wir setzen das Lehrmaterial in den einzelnen Ver- UML2-Modellierungsumgebung der aktuellen Eclipse-
anstaltungen wie folgt ein: Version. Entwickelt wird mit dem JEE-Plug-in-Set von
Software Engineering I: Hier stehen die Kompe- Eclipse.
tenzfelder Requirements, Design sowie Engineering Die Software des vorgefertigten Beispiels wird den
Management und Process im Vordergrund. Vorgabe Studierenden in einem Subversion-Repository zur Ver-
für das Praktikum ist daher lediglich eine ausgearbei- fügung gestellt. Über dieses Repository koordinieren
tete Spezifikation für den ersten fachlichen Schnitt die Studierenden den Austausch der im Team erstell-
„Benutzerverwaltung“. Die Studierenden müssen min- ten Artefakte. Des Weiteren geben sie darüber ihre
destens einen weiteren fachlichen Schnitt selbststän- Ergebnisse ab.
dig spezifizieren. Im Rahmen der Projektarbeit experimentieren die
Software Engineering II: Dieses Modul deckt den Studierenden mit verschiedenen Vorgehensmodellen.
Kompetenzbereich Construction ab. Hier müssen die Neben einem klassischen, iterativ-inkrementell orien-
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 37 von 44tierten ingenieurmäßigen Vorgehen kommt als Reprä- ist das Erlernen des konstruktiven fachlichen Austau-
sentant der agilen Ansätze auch Scrum zum Einsatz. sches, sowohl in der Rolle des Präsentierenden als
auch in der Rolle des kritisch Hinterfragenden. Beide
Methodenkompetenz Rollen fallen erstaunlich vielen Studierenden zunächst
Um die Studierenden nicht bereits am Anfang mit schwer. Eine wichtige Voraussetzung für die Vermitt-
einer großen Vielzahl verwendeter Technologien zu lung von Reflexions- und Kritikfähigkeit besteht darin,
überfordern, dient ein minimalistisches Exzerpt dieses in der Lehrveranstaltung eine Atmosphäre der vertrau-
Beispiels als niederschwelliger Einstieg für den Lern- ensvollen Zusammenarbeit zu schaffen, in der alle
prozess. So wird an einem zunächst noch bewusst sehr Beteiligten auf Augenhöhe wertschätzend miteinan-
einfach gehaltenen System zunächst ein Überblick der umgehen.
über die wesentlichen Zusammenhänge zwischen Mo- Bzgl. der Vermittlung ethischen Handelns stoßen
dellen und Implementierung, sowie innerhalb der Im- wir mit der Ausbildung in dieser Form schnell an
plementierung über das Zusammenspiel der einzel- Grenzen. Als Dozenten können wir hier im Wesentli-
nen Technologien erarbeitet. Darauf aufbauend wird chen sensibilisieren, den Blickwinkel auf grundlegen-
dieses System sukzessive weiter ausgebaut und nach de Fragestellungen richten und natürlich versuchen,
und nach um entsprechende Komplexitäten erweitert, als gutes Beispiel voranzugehen. Die hinter dem ethi-
nicht nur bzgl. der realisierten Funktionalität, sondern schen Handeln liegenden Wertesysteme lassen sich
auch bzgl. der verwendeten Technologien. „mal eben so nebenbei“ aber nur ansatzweise vermit-
Dadurch, dass das Beispiel hinreichend komplex teln – und auch nur dann, wenn die der Hochschule
ist und die Aufgabenstellung nicht alle Entscheidun- vorgelagerte Erziehung und Bildung den Grundstock
gen vorgibt, müssen die Studierenden an verschiede- dafür gelegt hat.
nen Stellen abwägen und entscheiden, wie weit sie
bestimmte Kerntechniken anwenden (beispielsweise Sozialkompetenz
hinsichtlich des Detallierungsgrades bei der Model- Durch den relativ hohen Anteil an Teamarbeit kommt
lierung, oder bzgl. der Testabdeckung). Da auch in- dem Bereich der Sozialkompetenz quasi als „Hinter-
nerhalb des studentischen Projektes Zeit eine knappe grundprozess“ eine fortlaufend wichtige Rolle zu. Be-
Ressource darstellt, wird die Notwendigkeit der Ab- reits beim Bilden der Teams und bei der Aufteilung
wägung zwischen Perfektionismus und pragmatischer der zu erledigenden Arbeiten treffen unterschiedli-
Einschränkung des investierten Aufwandes erlebbar. che Interessen und Vorlieben aufeinander. Die Dozen-
Die Ergebnisse, die die Studierenden im Rahmen ten beobachten aufmerksam, aber unaufdringlich das
der praktischen Projektarbeit erstellen, umfassen ne- Zusammenspiel innerhalb der einzelnen Teams. Bei
ben dem eigentlichen Quelltext auch weitere Artefakte Bedarf greifen sie (möglichst minimalistisch) in das
des Software Engineerings, beispielsweise Projektplä- Geschehen ein, beispielsweise durch das Setzen von
ne, Anforderungsdokumente, Architekturmodelle und gruppendynamischen Impulsen. Des Weiteren mode-
Ähnliches. Da diese Dokumente in die Gesamtbewer- rieren sie zu ausgewählten Meilensteinen der Projekt-
tung mit einfließen, spendieren die Studierenden zwar arbeit den Prozess der Gruppenreflexion über Ergeb-
meist ein gewisses Maß an Sorgfalt in deren Erstel- nisse und Ablauf der Teamarbeit.
lung, sehen diese Dokumente zunächst aber oft als Ergänzend wird theoretisch fundiertes Grundlagen-
ein notwendiges Übel an. Das Verständnis für die fach- wissen zu Sozialkompetenzen in spezialisierten Veran-
liche Notwendigkeit dieser Dokumente (und damit staltungen vermittelt und gezielt praktisch eingeübt.
eine intrinsiche Motivation, diese Dokumente sorgfäl-
tig zu erstellen und weiter zu pflegen) erwächst im Zusammenfassung und Ausblick
Laufe der Lehrveranstaltung aus der Dauer und dem
Umfang der Projektarbeit. Typischerweise stellen die Mit dem hier vorgestellten Beispiel lassen sich viele
Studierenden nach wenigen Wochen fest, dass ihr Pro- zentrale Aspekte des Software Engineerings von der
jekt ohne klare Dokumentation ineffektiv wird, weil Machbarkeitsanalyse bis hin zum Abnahmetest zeigen.
Anforderungen unklar und doppeldeutig sind, bereits Der besondere Fokus liegt dabei auf der Integration
getroffene Entscheidungen nicht mehr einheitlich er- der einzelnen Disziplinen. Dadurch werden für die
innert werden oder weil Uneinigkeit darüber besteht, Lernenden die Zusammenhänge zwischen einzelnen
wer wann welche Schritte als nächstes durchzuführen Arbeitsschritten und Artefakten klar ersichtlich und
hat. nachvollziehbar. Insbesondere werden dadurch die
Auswirkungen einzelner Entwicklungsentscheidungen
Selbstkompetenz greifbar verdeutlicht. Das Beispiel und die zugehöri-
Im Rahmen der verschiedenen Phasen der Projekt- gen Lernmaterialien ermöglichen so einen ganzheitli-
und Teamarbeit erhalten die Studierenden Feedback chen Einstieg in die komplexe Materie des Software
von Kommilitonen und Dozenten, sowohl über ihren Engineerings.
Arbeitsprozess als auch über die erzielten Ergebnis- Im Rahmen einer qualitativen Evaluierung haben
se. Beispielsweise stellen einzelne Projektteams Teile unsere Studierenden die folgenden repräsentativen
ihrer Arbeiten den anderen Gruppen vor. Ziel dabei Aussagen gemacht. Als positiv wurde die Praxisnähe
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 38 von 44des Beispiels empfunden, sowie die Tatsache, dass in [Schaeper u. Briedis 2004] S CHAEPER, H. ; B RIE -
den Lehrveranstaltungen ein Beispiel von realistischer DIS , K.: Kompetenzen von Hochschulabsolventinnen
Komplexität behandelt wird. Diese Komplexität wurde und Hochschulabsolventen, berufliche Anforderun-
jedoch gleichzeitig auch als negativ empfunden, da zu gen und Folgerungen für die Hochschulreform. HIS-
Beginn der Veranstaltung sehr viele Dinge gleichzeitig Kurzinformation, 2004
zu lernen sind, beispielsweise verschiedene Frame-
works. Des Weiteren wurde die Größe der Aufgabe [Schott u. Ghanbari 2009] S CHOTT, F. ; G HANBARI,
kritisiert. S. A.: Modellierung, Vermittlung und Diagnostik
Der beschrittene Weg, für ein signifikant großes der Kompetenz kompetenzorientiert zu unterrich-
Projekt einzelne Teile in einer ausgearbeiteten Form ten – wissenschaftliche Herausforderung und ein
vorzugeben, die auch kritischen Blicken aus der Praxis praktischer Lösungsversuch. In: Lehrerbildung auf
Stand hält, hat sich also im Ansatz bewährt. An man- dem Prüfstand 2 (2009), Nr. 1, S. 10–27
chen Stellen haben wir einen Teil unserer Studieren- [Spitzer 2006] S PITZER, Manfred: Lernen: Gehirnfor-
den mit der Komplexität des Beispiels aber offenbar schung und die Schule des Lebens. Spektrum Akade-
überfordert. mischer Verlag, 2006
In folgenden Punkten haben wir konkret Verbesse-
rungspotenzial sowohl für das Beispiel als auch für [Vigenschow u. Schneider 2007] V IGENSCHOW, Uwe ;
die eingesetzten didaktischen Methoden identifiziert: S CHNEIDER, Börn: Soft Skills für Softwareentwickler
– Fragetechniken, Konfliktmanagement, Kommunika-
• Kleinere Wissenseinheiten vermitteln tionstypen und -modelle. dpunkt.verlag, 2007
Die Darstellung von Technologien und Basistechni-
ken müssen wir gezielt in einem überschaubaren
Kontext aufbereiten.
• Referenzimplementierung inkrementell einführen
Wir werden Referenzimplementierungen zukünf-
tig in kleineren Zwischenschritten vorgeben. Zum
Einstieg haben wir ein minimalistisches Beispiel
gebaut, das sich auf einen Server (Tomcat, Jetty)
„deployen“ lässt und einen Login für einen hart
codierten Benutzer mit entsprechendem Service,
aber ohne eine Datenbank, realisiert.
• Mehr Diskussion individueller Lösungen
Wir wollen mit den Studierenden stärker deren
Lösungen diskutieren. Hier stoßen wir allerdings
von der Betreuungsrelation und unserem Zeitbud-
get an Grenzen.
Literatur
[Abran u. a. 2005] A BRAN, A. ; M OORE, J. ; D UPUIS,
R. ; T RIPP, L.: Guide to the Software Engineering
Body of Knowledge 2004 Version SWEBOK. IEEE
Computer Society Press, 2005
[Evans 2003] E VANS, Eric: Domain-Driven De-
sign: Tackling Complexity in the Heart of Software.
Addison-Wesley Longman, Amsterdam, 2003
[Lehner 2009] L EHNER, M.: Viel Stoff – wenig Zeit.
Haupt Verlag, Stuttgart, 2009
[Martin 2008] M ARTIN, Robert C.: Clean Code: A
Handbook of Agile Software Craftsmanship. Prentice
Hall International, 2008
[Rising u. Manns 2004] R ISING, Linda ; M ANNS, Ma-
ry L.: Fearless Change: Patterns for Introducing New
Ideas. Addison-Wesley, 2004
Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 39 von 44Sie können auch lesen
