Software Engineering ist eine komplexe Aufgabe, die von den Beteiligten ausgeprägte Kompetenzen in vielen verschiedenen Bereichen fordert. Die Vermittlung dieser Kompetenzen über das reine Fachwissen hinweg ist eine zentrale Aufgabe, die eine Software-Engineering-Ausbildung leisten muss, um Absolventen für den Einsatz in der Praxis zu qualifizieren. Ausgehend von den zu vermittelnden Kompetenzen zeigen wir, wie wir in unserer Lehrpraxis mit Hilfe eines möglichst einfach gehaltenen, aber so komplex wie nötig gestalteten durchgängigen Beispiels sowie durch innovative Lehrmethoden praxisnah eine fundierte Einführung in die komplexen Tätigkeiten des Software Engineerings vermitteln.
Anforderungen an Softwaresysteme werden heute zunehmend umfangreicher und komplexer. Analog dazu entwickeln sich auch die Technologien und Werkzeuge für Software Engineering stetig weiter und werden immer mächtiger -und damit selbst komplexer. Da sich diese Technologien und Werkzeuge laufend weiter entwickeln, ist die Halbwertzeit der dazu erworbenen Kompetenzen entsprechend kurz.
Aufgrund der Menge und Komplexität des erforderlichen Wissens und wegen der Größe der zu erstellenden Systeme wird Software in der heutigen Praxis nahezu immer im Team entwickelt. Neben den rein technisch-fachlichen Kompetenzen werden damit in zunehmendem Maße auch Fähigkeiten wichtig, die sich mit der Positionierung einer Einzelperson im Team sowie mit der Integration und Interaktion aller Beteiligten untereinander befassen.
Eine Software-Engineering-Ausbildung, die nicht nur theoretisch fundiert, sondern auch praxisnah und berufsbefähigend sein soll, muss diesen Entwicklungen Rechnung tragen. Hier stößt die Lehre sehr schnell auf das heute bereits klassische Dilemma, dass die verfügbare Lernzeit in der initialen Ausbildungsphase eines Menschenlebens seit Jahren in etwa konstant bleibt, die Menge des verfügbaren und als wichtig empfundenen Wissens aber exponentiell an-steigt (Spitzer, 2006). Da dieser Entwicklung alleine mit erhöhter Packungsdichte in der Wissensvermittlung nicht mehr beizukommen ist, ist zwangsweise Selektion erforderlich. Eine "gute" Selektion wird somit zu einer der wesentlichen Herausforderungen bei der Konzeption der Software-Engineering-Ausbildung.
Im Folgenden definieren wir zunächst kompetenzorientierte Lernziele für die Software-Engineering-Ausbildung. Diese basieren im Wesentlichen auf drei Quellen:
• klassischer Software-Engineering-Literatur,
• einer umfangreichen Befragung von Absolventen unserer Fakultät aus den letzten fünf Jahrgängen sowie
• Aussagen von Spezialisten aus der beruflichen Praxis über die Eigenschaften und Fähigkeiten, die sie von potenziellen neuen Mitarbeitern/innen erwarten.
Im Anschluss daran beschreiben wir ein Beispielprojekt und die zugehörigen Lehrkonzepte, die wir in den Bachelor-Studiengängen Informatik sowie Wirtschaftsinformatik einsetzen. Abschließend setzen wir die mit unserem Lehrkonzept gemachten Erfahrungen in Beziehung zu den zuvor definierten Kompetenzzielen.
Grundlage einer adäquaten Selektion von Ausbildungsinhalten und -methoden ist die Definition der zu erreichenden Lernziele. In der Regel stellt die Definition dieser Lernziele bereits selbst eine Auswahl dar, da in der meist begrenzten verfügbaren Zeit realistischer Weise nicht immer alle eigentlich gewünschten Ziele erreicht werden können (Lehner, 2009).
Ausbildung und Lernziele müssen sich dabei zum einen an Kompetenzen auf unterschiedlichen Wissensgebieten orientieren. Zum anderen sollen sie die Studierenden auf die Übernahme verschiedener Rollen vorbereiten. Analog zu Schott und Ghanbari (Schott u. Ghanbari, 2009) betrachten wir Kompetenzen als diejenigen Eigenschaften und Fähigkeiten, die man besitzen muss, um eine bestimmte Menge von Aufgaben sinnvoll ausführen zu können. Als Grundlage für die Definition von zu vermittelnden Kompetenzen und daraus abzuleitenden Lernzielen, empfiehlt sich zunächst der "Software Engineering Body of Knowledge" (Abran u. a., 2005). Die dort genannten Kompetenzfelder haben wir für die Durchführung der Lehre in den Bachelor-Studiengängen Informatik und Wirtschaftsinformatik priorisiert und in Tabelle 1 zusammengefasst. Der Themenbereich "Software Maintenance" wird aktuell nur am Rande adressiert. Das liegt unter anderem daran, dass Software Maintenance zum einen sehr technologiespezifisch ist und zum anderen stark auf anderen Kompetenzen aufbaut. Diese müssen somit zuerst vermittelt werden, bevor diese Thematik auf technisch anspruchsvollem Niveau behandelt werden kann.
Als ergänzende Informationsquelle haben wir eine Umfrage herangezogen, die unter unseren Absolventen der Informatik und Wirtschaftsinformatik der letzten Jahre durchgeführt wurde -also unter Personen, die sich bereits mit den bei uns erworbenen Fähigkeiten in der Industrie bewähren müssen. Darüber hinaus befragten wir erfahrene Praktiker aus der Industrie, welche konkreten Anforderungen die Praxis an unsere Absolventen stellt. Die auf diese Weise identifizierten Kompetenzbedarfe gliedern wir im Folgenden nach den vier Bereichen Sach-, Methoden-, Selbst-und Sozialkompetenz (vergleiche (Schaeper u. Briedis, 2004)). Dabei ordnen wir Kompetenzen, die mehr als einen dieser Bereiche bedienen, demjenigen Kompetenzbereich zu, zu dem sie nach unserer Einschätzung den stärksten Beitrag leisten.
Der Bereich der Sachkompetenz fokussiert das erworbene Fachwissen und dessen zielgerichtete Anwendung. Hierzu zählen die in Tabelle 1 aufgelisteten Kompetenzbereiche aus dem SWEBOK. Diese wurden aus der Praxis durch die folgenden Kompetenzforderungen ergänzt.
Um eine "ordentliche", d.h. professionelle und nachhaltige Softwareentwicklung rein technischhandwerklich überhaupt zu ermöglichken müssen Software-Ingenieure/innen modellieren und designen können. Dazu gehören unter anderem auch das Verständnis für bzw. der Einsatz von Design Patterns, SOLID-Prinzipien und ggf. Domain Driven Development (Evans, 2003).
• Beschreibung von Architekturen Software-Ingenieure/innen müssen in der Lage sein, technische und fachliche Architekturen zu konzipieren und so darzustellen, dass sie als klar verständliche Grundlage für die Kommunikation aller Projektbeteiligten dienen können.
Im Bereich der Methodenkompetenz sind grundlegende Arbeitstechniken zusammengefasst, sowie Fähigkeiten und Verfahren, die ein effektives, ergebnisorientiertes Arbeiten ermöglichen.
Wer nicht in übergeordneten Strukturen denkt, beschränkt sich auf lokale Optimierungen und tendiert dazu, "echte" Probleme nicht anzugehen. Strukturprobleme anzugehen erfordert auch Mut.
Zum Bereich der Selbstkompetenz zählen Fähigkeiten, die eigene Situation wahrzunehmen, eigene Bedüfnisse zu erkennen und zu artikulieren, eigenverantwortlich zu handeln und über all diese Punkte selbstkritisch und konstruktiv zu reflektieren.
Der Bereich der Sozialkompetenz fokussiert schließlich die Fähigkeit, die Bedürfnisse und Interessen anderer Menschen wahrzunehmen, sich mit diesen auseinander zu setzen und konstruktiv und erfolgreich mit anderen Menschen zusammenzuarbeiten.
• Verständnis für Andere Software entsteht nicht in einem luftleeren Raum, sondern durch die Zusammenarbeit verschiedenster Gruppen, wie beispielsweise Management, Benutzer, Fachexperten, QA, Operations und vielen anderen. Schon die Zielfindung in einem Entwicklungsprojekt erfordert intensive Kommunikation zwischen den Beteiligten sowie eine offene Wahrnehmung der Belange und Interessen aller Beteiligten.
In der Praxis ist Software heutzutage fast immer das Produkt eines Teams. Entsprechend kommt der Fähigkeit, sinnvoll, effektiv und gerne (!) in einem Team zusammenzuarbeiten eine fundamentale Bedeutung zu: Wer das nicht kann, kann nichts von dem, was er/sie kann, sinnvoll im komplexeren Umgebungen einbringen. Zu den zentralen Teilfähigkeiten gehören unter anderem eher pragmatische Punkte wie ein freundlicher Umgangston, nett sein und zuhören können. Gerade in kritischen Situationen gewinnt darüber hinaus theoretisch fundiertes Wissen über Team-Regeln an Bedeutung, wie beispielsweise das Tucker-Modell, das Vier-Ohren-Modell von Schulz von Thun. Ebenfalls nützlich sind Change Management, wie z.B. (Rising u. Manns, 2004), sowie ein Grundstock an psychologischem Grundwissen, wie beispielsweise in (Vigenschow u. Schneider, 2007) beschrieben.
Nicht alle dieser eigentlich wünschenswerten Kompetenzen können in der zur Verfügung stehenden Lehrund Lernzeit im vollen Umfang vermittelt werden. In den Kompetenzbereichen, die wir nicht vollständig bedienen können, soll unsere Ausbildung zumindest das Bewusstsein für die Notwendigkeit dieser Kompetenzen wecken, indem sie deutlich macht, für welche Aufgaben, Disziplinen und Rollen diese Kompetenzen erforderlich sind.
Um dem Curriculum der von uns bedienten Bachelor-Studiengänge "Informatik" und "Wirtschaftsinformatik" mit nur einem Beispiel gerecht zu werden konzipierten wir dieses als eine moderne Webapplikation. Bislang kommt dieses Beispiel in folgenden Modulen zum Einsatz, deren Umfang jeweils bei zwei SWS seminaristischem Unterricht und zwei SWS Praktikum liegt und mit fünf ECTS-Punkten gewichtet ist:
• Modul "Software Engineering I" im 3. Semester des Bachelorstudiengangs Wirtschaftsinformatik Der zweite fachliche Schnitt "Verwaltung der Leihobjekte" ist ebenfalls ausgearbeitet, je nach Fokus der Lehrveranstaltung aber nur teilweise oder gar nicht für die Studierenden verfügbar. In der Lehrveranstaltung "Softwarearchitektur" (Bachelor Informatik) erhalten die Studierenden die vorgefertigten Analyse-und Entwurfsdokumente, die sie anschließend in eine funktionsfähige Implementierung umsetzen. In "Software Engineering" (Bachelor Informatik und Wirtschaftsinformatik) dagegen erstellen die Studierenden selbst die benötigten Analyse-und Entwurfsdokumente und setzen anschließend ihre eigene Spezifikation um. Bei Bedarf ist das Beispiel um zusätzliche fachliche Schnitte erweiterbar.
Wir setzen das Lehrmaterial in den einzelnen Veranstaltungen wie folgt ein:
Software Engineering I: Hier stehen die Kompetenzfelder Requirements, Design sowie Engineering Management und Process im Vordergrund. Vorgabe für das Praktikum ist daher lediglich eine ausgearbeitete Spezifikation für den ersten fachlichen Schnitt "Benutzerverwaltung". Die Studierenden müssen mindestens einen weiteren fachlichen Schnitt selbstständig spezifizieren.
Software Engineering II: Dieses Modul deckt den Kompetenzbereich Construction ab. Hier müssen die Studierenden den im ersten Teil spezifizierten fachlichen Schnitt implementieren. Als Vorgabe erhalten sie eine referenzimplementierung des ersten Schnittes.
Software-Architektur: Lernziel ist hier die Fähigkeit, moderne Architekturen für komplexe Software-Systeme zu bewerten, zu entwerfen, zu realisieren und zu betreiben (kompetenzbereiche design. Construction, Testing). Die Studierenden bekommen für den ersten fachlichen Schnitt sowohl eine Spezifikation als auch deren Implementierung als Vorgabe. Sie müssen den zweiten fachlichen Schnitt implementieren und bekommen dazu die Spezifikation als Vorgabe.
Als Lehrmethode im seminaristischen Unterricht wurde eine Mischung aus interaktiver Vorlesung, Lernen durch Lehren, Gruppenpuzzle und Projektarbeit in wechselnden Teams eingesetzt.
Nach den bisherigen Erfahrungen adressiert unser Lehrkonzept eine Vielzahl der Schlüsselkompetenzen, die aus der Praxis geforderten wurden.
Die Studierenden durchlaufen im Rahmen der Projektarbeit mindestens einen kompletten Softwareentwicklungszyklus, vom Skizzieren erster Anforderungen bis hin zum Integrationstest. Das vorgefertigte, durchgängige Beispiel hilft dabei, neu eingeführte Techniken und deren zielgerichtete Verwendung zu veranschaulichen. Des Weiteren dient es als Anhaltspunkt für die Lösungsbestandteile, welche die Studierenden im Rahmen ihrer Projektarbeit nach und nach selbst entwickeln.
Das Beispiel ist aktuell auf der Basis von Servlets implementiert. Als Frameworks kommen Hibernate, Google Guice (Dependency Injection), Apache Click, Log4j und Selenium zum Einsatz. Die zugehörigen Technologien und Frameworks werden in der Lehrveranstaltung sukzessive vermittelt und von den Studierenden bei der Erstellung ihrer eigenen Lösungsanteile entsprechend weiterverwendet.
Für die Modellierung stehen verschiedene Modellierungswerkzeuge zur Verfügung, beispielsweise der IBM Rational Software Modeler oder die UML2-Modellierungsumgebung der aktuellen Eclipse-Version. Entwickelt wird mit dem JEE-Plug-in-Set von Eclipse.
Die Software des vorgefertigten Beispiels wird den Studierenden in einem Subversion-Repository zur Verfügung gestellt. Über dieses Repository koordinieren die Studierenden den Austausch der im Team erstellten Artefakte. Des Weiteren geben sie darüber ihre Ergebnisse ab.
Im Rahmen der Projektarbeit experimentieren die Studierenden mit verschiedenen Vorgehensmodellen. Neben einem klassischen, iterativ-inkrementell orien-tierten ingenieurmäßigen Vorgehen kommt als Repräsentant der agilen Ansätze auch Scrum zum Einsatz.
Im Rahmen der verschiedenen Phasen der Projektund Teamarbeit erhalten die Studierenden Feedback von Kommilitonen und Dozenten, sowohl über ihren Arbeitsprozess als auch über die erzielten Ergebnisse. Beispielsweise stellen einzelne Projektteams Teile ihrer Arbeiten den anderen Gruppen vor. Ziel dabei ist das Erlernen des konstruktiven fachlichen Austausches, sowohl in der Rolle des Präsentierenden als auch in der Rolle des kritisch Hinterfragenden. Beide Rollen fallen erstaunlich vielen Studierenden zunächst schwer. Eine wichtige Voraussetzung für die Vermittlung von Reflexions-und Kritikfähigkeit besteht darin, in der Lehrveranstaltung eine Atmosphäre der vertrauensvollen Zusammenarbeit zu schaffen, in der alle Beteiligten auf Augenhöhe wertschätzend miteinander umgehen.
Bzgl. der Vermittlung ethischen Handelns stoßen wir mit der Ausbildung in dieser Form schnell an Grenzen. Als Dozenten können wir hier im Wesentlichen sensibilisieren, den Blickwinkel auf grundlegende Fragestellungen richten und natürlich versuchen, als gutes Beispiel voranzugehen. Die hinter dem ethischen Handeln liegenden Wertesysteme lassen sich "mal eben so nebenbei" aber nur ansatzweise vermitteln -und auch nur dann, wenn die der Hochschule vorgelagerte Erziehung und Bildung den Grundstock dafür gelegt hat.
Durch den relativ hohen Anteil an Teamarbeit kommt dem Bereich der Sozialkompetenz quasi als "Hintergrundprozess" eine fortlaufend wichtige Rolle zu. Bereits beim Bilden der Teams und bei der Aufteilung der zu erledigenden Arbeiten treffen unterschiedliche Interessen und Vorlieben aufeinander. Die Dozenten beobachten aufmerksam, aber unaufdringlich das Zusammenspiel innerhalb der einzelnen Teams. Bei Bedarf greifen sie (möglichst minimalistisch) in das Geschehen ein, beispielsweise durch das Setzen von gruppendynamischen Impulsen. Des Weiteren moderieren sie zu ausgewählten Meilensteinen der Projektarbeit den Prozess der Gruppenreflexion über Ergebnisse und Ablauf der Teamarbeit.
Ergänzend wird theoretisch fundiertes Grundlagenwissen zu Sozialkompetenzen in spezialisierten Veranstaltungen vermittelt und gezielt praktisch eingeübt.
Mit dem hier vorgestellten Beispiel lassen sich viele zentrale Aspekte des Software Engineerings von der Machbarkeitsanalyse bis hin zum Abnahmetest zeigen. Der besondere Fokus liegt dabei auf der Integration der einzelnen Disziplinen. Dadurch werden für die Lernenden die Zusammenhänge zwischen einzelnen Arbeitsschritten und Artefakten klar ersichtlich und nachvollziehbar. Insbesondere werden dadurch die Auswirkungen einzelner Entwicklungsentscheidungen greifbar verdeutlicht. Das Beispiel und die zugehörigen Lernmaterialien ermöglichen so einen ganzheitlichen Einstieg in die komplexe Materie des Software Engineerings.
Im Rahmen einer qualitativen Evaluierung haben unsere Studierenden die folgenden repräsentativen Aussagen gemacht. Als positiv wurde die Praxisnähe des Beispiels empfunden, sowie die Tatsache, dass in den Lehrveranstaltungen ein Beispiel von realistischer Komplexität behandelt wird. Diese Komplexität wurde jedoch gleichzeitig auch als negativ empfunden, da zu Beginn der Veranstaltung sehr viele Dinge gleichzeitig zu lernen sind, beispielsweise verschiedene Frameworks. Des Weiteren wurde die Größe der Aufgabe kritisiert.
Der beschrittene Weg, für ein signifikant großes Projekt einzelne Teile in einer ausgearbeiteten Form vorzugeben, die auch kritischen Blicken aus der Praxis Stand hält, hat sich also im Ansatz bewährt. An manchen Stellen haben wir einen Teil unserer Studierenden mit der Komplexität des Beispiels aber offenbar überfordert.
In folgenden Punkten haben wir konkret Verbesserungspotenzial sowohl für das Beispiel als auch für die eingesetzten didaktischen Methoden identifiziert:
• Kleinere Wissenseinheiten vermitteln Die Darstellung von Technologien und Basistechniken müssen wir gezielt in einem überschaubaren Kontext aufbereiten.
• Referenzimplementierung inkrementell einführen Wir werden Referenzimplementierungen zukünftig 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.
Wir wollen mit den Studierenden stärker deren Lösungen diskutieren. Hier stoßen wir allerdings von der Betreuungsrelation und unserem Zeitbudget an Grenzen.