Software ist Teil der modernen Welt und nahezu überall zu finden. Daher gewinnt Software Engine-‐ering zunehmend an Bedeutung. Um Software zu entwickeln oder weiterzuentwickeln, sind vielfälti-‐ge Kompetenzen und Kenntnisse nötig. Das stellt auch die Hochschulausbildung und damit verbun-‐den die didaktische Forschung im Software Engi-‐neering vor große Herausforderungen. In diesem Beitrag wird zunächst das For-‐schungsinteresse beschrieben und begründet. Dann wird der Kompetenzbegriff diskutiert und erläu-‐tert. Nachfolgend werden die methodischen Schrit-‐te beschrieben, mit denen das Kompetenzprofil eines Software Ingenieurs erhoben wird. Dabei wird zunächst die Vorgehensweise beschrieben, bevor erste Ergebnisse vorgestellt werden. Zuletzt folgt ein Ausblick, wie die Hochschulausbildung im Software Engineering noch besser auf Kompe-‐tenzentwicklung ausgerichtet werden kann.
Durch die stetig wachsende Komplexität von Soft-‐‑ ware steigen auch die Anforderungen an Informa-‐‑ tiker, die mit einer zunehmenden Anzahl von komplexen Rollen, Schnittstellen und Aufgaben konfrontiert werden.
Software wird häufig in großen Teams mit ei-‐‑ ner Vielzahl fachlicher Rollen entwickelt. Das reicht vom Anforderungsanalysten über den Software Ar-‐‑ chitekten und den Programmierer bis hin zum Software Tester. In jeder dieser Rollen sind zum Teil sehr unterschiedliche Kompetenzen notwen-‐‑ dig. Da Software normalerweise nicht für Informa-‐‑ tiker, sondern für "ʺfachfremde"ʺ Auftraggeber ent-‐‑ wickelt wird, muss zum Beispiel derjenige, der Anforderungen erhebt, über ein hohes Maß an in-‐‑ terdisziplinärer Kommunikationsfähigkeit verfü-‐‑ gen. Ein Software Ingenieur im Bereich Anforde-‐‑ rungsanalyse muss in der Lage sein, sich auf für ihn fremde Denkmuster und Denkstrukturen ein-‐‑ zulassen, sie zu verstehen und auch zwischen ihnen und der Informatik zu vermitteln. Des Weite-‐‑ ren muss ein Anforderungsanalytiker mit einem gewissen Verständnis für den künftigen Anwen-‐‑ dungskontext der zu entwickelnden Software aus-‐‑ gestattet sein, um funktionale und nichtfunktionale Anforderungen möglichst umfassend erheben zu können. Dies setzt ein gewisses Maß an Empathie und Weitblick voraus, sich in die künftige Anwen-‐‑ dungssituation und den Anwender hineinzuver-‐‑ setzen. So birgt jede Rolle im Prozess des Software Engineering ihre besonderen Herausforderungen.
Software Ingenieure müssen sich jedoch unab-‐‑ hängig von ihrer Rolle in ein Entwicklungsteam eingliedern können und benötigen neben ihrem fachlichen Wissen auch eine Vielzahl weiterer Kompetenzen. So müssen sie etwa in der Lage sein, Herausforderungen und Probleme rechtzeitig zu erkennen und einzuschätzen, benötigen also ein gewisses Problembewusstsein, um im richtigen Moment angemessen agieren und reagieren zu können. Software Ingenieure müssen ihr erworbe-‐‑ nes Wissen ständig auf neue Situationen anpassen und erlernte Methoden selbständig anwenden.
Dieser Artikel konkretisiert und strukturiert den Kompetenzbegriff im Kontext von Software Engineering und stellt ein Modell zur Beschreibung von Kompetenzen vor. Er beleuchtet, wie es entwi-‐‑ ckelt wurde und welche Anforderungen es erfüllen soll. Er zeigt auf Grundlage des vorgeschlagenen Beschreibungsmodells erste Ergebnisse zu Soll-‐‑ Kompetenzen eines Software Ingenieurs.
Ein Software Ingenieur benötigt neben einer Viel-‐‑ zahl an fachlichen auch überfachliche Kompeten-‐‑ zen, damit er sein fachliches Wissen in komplexen Situationen überhaupt erfolgreich umsetzen kann. Da es in Lernprozessen keine direkten und klaren Ursache-‐‑Wirkungs-‐‑Zusammenhänge gibt, können Kompetenzen lediglich trainiert und gefördert, jedoch nicht direkt vermittelt werden. Das stellt die Hochschulausbildung im Software Engineering vor große Herausforderungen. Sie möchte sowohl fach-‐‑ liche als auch überfachliche Kompetenzen im Soft-‐‑ ware Engineering trainieren. Daher starteten sechs bayerische Hochschulen das Projekt EVELIN (Ex-‐‑ perimentelle VErbesserung des Lernens von Soft-‐‑ ware EngINeering), um genau hier anzusetzen und das Lehren und Lernen von Software Engineering in seiner gesamten Bandbreite besser verstehen zu können und im Rahmen der Hochschullehre zielge-‐‑ richtet Rahmenbedingungen zu schaffen, die das Trainieren von Kompetenzen optimal ermöglichen.
Bevor es aber möglich ist, sich darüber Gedan-‐‑ ken zu machen, wie man am besten Kompetenzen trainieren kann, stellen sich folgende Fragen: • Was meint überhaupt "ʺKompetenz"ʺ? • Wozu dient eine Kompetenzbeschreibung? • Wie beschreibt man Kompetenzen sinnvoll? • Was genau kennzeichnet einen guten Software Ingenieur? Welche Kompetenzen soll ein Soft-‐‑ ware Ingenieur haben?
Der Kompetenzbegriff ist relativ unscharf. Es gibt zahlreiche Definitionen, was unter Kompetenzen verstanden werden kann.
Spricht man allgemein von einer Kompetenz,
um z.B. eine bestimmte Problemstellung lösen zu
können, treten verschiedene Kompetenzarten in
Kombination auf. Um etwa Anforderungen erfas-‐‑
sen zu können, bedarf es sowohl fachlich-‐‑metho-‐‑
discher (z.B. Anforderungen korrekt beschreiben)
als auch sozial-‐‑kommunikativer Kompetenzen (z.B.
Kommunikationsfähigkeit, Teamfähigkeit). Auch
Fähigkeiten und Fertigkeiten. • Überfachliche Kompetenzen beinhalten die motivationalen, volitionalen und sozialen Be-‐‑ reitschaften und Fähigkeiten. Somit beschreiben überfachliche Kompetenzen hier diejenigen Kompetenzen, die gemeinhin nicht di-‐‑ rekt als "ʺFachwissen"ʺ bezeichnet werden, sondern vielmehr alle Fähigkeiten, die nötig sind, um Fachwissen situationsbezogen und zielgerichtet in komplexen Situationen anwenden zu können.
Die derzeitige Unterscheidung von lediglich zwei Kompetenzarten ohne weitere Unterteilungen liegt darin begründet, dass aktuell noch keine Aus-‐‑ sagen über feinere sinnvolle Differenzierungen getroffen werden können. Das Interesse liegt zu-‐‑ nächst auf einer klaren Strukturierung von For-‐‑ schungsdaten. Erst später ist möglicherweise eine weitere Differenzierung sinnvoll und notwendig.
Die erforderlichen fachlichen und überfachlichen Kompetenzen im Software Engineering sollen er-‐‑ hoben, analysiert und beschrieben werden, um darauf aufbauend Lehrziele, didaktische Methoden und kompetenzorientierte Prüfungen (weiter) zu entwickeln. Die erhobenen Kompetenzen werden in einem Kompetenzprofil zusammengefasst und stellen so ein umfassendes Bild dar, was ein Soft-‐‑ ware Ingenieur unmittelbar nach der Hochschul-‐‑ ausbildung kennen und können soll. Kompetenz-‐‑ profile sollen sowohl für den Bereich der Kernin-‐‑ formatik als auch für Software Engineering im Ne-‐‑ benfach wie etwa Mechatronik erfasst werden. Darauf aufbauend soll erforscht werden, welche Einflussfaktoren die Kompetenzförderung im Software Engineering begünstigen, so dass in der Hochschulausbildung gezielt kompetenzfördernde Rahmenbedingungen geschaffen werden können.
Die Kompetenzbeschreibung ist somit eine we-‐‑ sentliche Grundlage für die weitere empirisch-‐‑ experimentelle Didaktikforschung. Kompetenzbe-‐‑ schreibungen werden benötigt, um die Ziele der akademischen Ausbildung klar beschreiben zu können und eine Vergleichsmöglichkeit zu schaf-‐‑ fen, inwieweit diese Ziele dann tatsächlich erreicht wurden. Dazu ist eine systematische, vergleichbare Beschreibung von Kompetenzen notwendig. Kom-‐‑ petenzbeschreibungen bilden diese Vergleichs-‐‑ grundlage, um später in Experimenten zu evaluie-‐‑ ren, wie sich die Soll-‐‑ von den Ist-‐‑Kompetenzen Studierender unterscheiden und ob die gezielte Veränderung einzelner Einflussvariablen auf den Lernprozess die Kompetenzentwicklung begünstigt hat. Die Beschreibung von Kompetenzprofilen stellt in diesem Zusammenhang eine Datenbasis zu ver-‐‑ schiedenen Zeitpunkten sowie verschiedener Ko-‐‑ horten und Studiengänge dar, die dann miteinan-‐‑ der abgeglichen werden können.
Fachliche und überfachliche Kompetenzen un-‐‑ terscheiden sich in ihrer Art, Beschreibung, Förde-‐‑ rung und auch Messung stark und werden daher zunächst separat betrachtet. Überfachliche Kompe-‐‑ tenzen sind sehr schwer zu fassen, zudem kaum eindeutig definierbar und messbar.
Fachliche Kompetenzen werden mit einem ge-‐‑
eigneten Beschreibungsschema erfasst, analysiert
und beschrieben. Eine Grundlage dafür bildet
SWEBOK
Die systematische Erfassung der Soll-‐‑Kompe-‐‑ tenzen ist Voraussetzung dafür, Lernprozesse bes-‐‑ ser analysieren und verstehen zu können. Zentrale Fragen sind dann: Welche Faktoren wirken über-‐‑ haupt auf das Lernen? Und wie können diese Ein-‐‑ flussfaktoren systematisch erfasst werden, so dass dann zielgerichtet diejenigen angepasst und verän-‐‑ dert werden können, die Lernprozesse unterstützen und so die Soll-‐‑Kompetenzen gezielt fördern? Hin-‐‑ zu kommt die Schwierigkeit, dass Wechselwirkun-‐‑ gen zwischen den Einflussfaktoren bestehen: die Änderung einzelner Faktoren hat immer Auswir-‐‑ kungen auf andere. Es gilt, diese Einflussfaktoren auf Lernprozesse im Software Engineering und ihre Wechselwirkungen untereinander mittels Groun-‐‑ ded Theory besser zu verstehen, zumal es speziell für den Bereich Software Engineering noch keine etablierte Theorie gibt.
Den methodischen Rahmen für das gesamte Vor-‐‑
haben bildet die Forschungsstrategie Grounded
Theory
Den Ausgangspunkt der Grounded Theory bil-‐‑
den nicht theoretische Vorannahmen. Vielmehr
handelt es sich um einen zirkulären Analysepro-‐‑
zess, der zugleich induktive und deduktive Vorge-‐‑
henselemente beinhaltet. Ausgangspunkt ist eine
erklärende Hypothese, die versucht, von einer Fol-‐‑
ge auf Vorhergehendes zu schließen (Abduktion).
Dann wird ein Typisierungsschema für Hypothe-‐‑
sen entwickelt (Deduktion), das mit Forschungsda-‐‑
ten abgeglichen wird (Induktion)
Grounded Theory besitzt unter anderem fol-‐‑ gende wesentliche Merkmale: • Eine Theorie wird aus Daten generiert, statt "ʺnur"ʺ verifiziert. Der Fokus liegt auf der Entde-‐‑ ckung und Einbeziehung neuer Erkenntnisse, nicht auf der Verifizierung, denn das würde neu auftauchende Perspektiven unterdrücken. Folglich kann eine Theorie nie "ʺfertig"ʺ sein, da jederzeit neue Aspekte auftauchen können. • Ziel ist es, durch das Vergleichen von Gruppen zum einen Kategorien zu bilden und zum an-‐‑ deren bestehende Beziehungen zwischen die-‐‑ sen Kategorien an den Tag zu bringen. Nach Glaser et al. (1998, S. 48f.) "ʺ... muss unterstri-‐‑ chen werden, dass die Hypothesen zunächst einen vorläufigen Status haben: Sie beschreiben mutmaßliche, nicht getestete Zusammenhänge zwischen den Kategorien und ihren Eigenschaf-‐‑ ten -‐‑ was natürlich nicht heißt, dass man die Hypothesen nicht so gut wie möglich verifizie-‐‑ ren sollte. [...] Hypothesen zu generieren heißt, sie im empirischen Material zu verankern -‐‑ nicht, genug Material anzuhäufen, um einen Beweis führen zu können."ʺ • Grounded Theory fordert eine parallele Daten-‐‑ erhebung und -‐‑analyse, und zwar vom Beginn der Forschung an bis zur ihrem Ende. • Theoretisches Sampling meint, dass die Stich-‐‑ probe sich während des gesamten Forschungs-‐‑ prozesses weiter entwickelt, so dass bis zum Ende keine endgültigen Aussagen über die er-‐‑ hobenen und einbezogenen Daten getroffen werden können. Die entstehende Theorie steu-‐‑ ert, wann im Forschungsprozess welche Daten wo erhoben werden. • Grundsätzlich gilt ein Mix qualitativer und quantitativer Forschungsmethoden als zielfüh-‐‑ rend. Daraus resultiert permanente Offenheit für neue Aspekte, die jederzeit in den Forschungsprozess aufgenommen werden.
Das Vorgehen der Grounded Theory korrespon-‐‑ diert gut mit dem Anspruch einer angewandten Forschung, da hier sowohl die Forschungsmetho-‐‑ dik als auch die Anwendungsorientierung von zu erhebenden Daten ausgehen und diese strukturie-‐‑ ren. Zudem soll kein vorgefertigtes Bild verifiziert werden, das es für das Lernen von Software Engi-‐‑ neering ohnehin noch nicht gibt. Ein solches Mo-‐‑ dell könnte nur auf theoretischer Basis entwickelt werden, hätte dann aber wenig Bezug zur Anwen-‐‑ dungsrealität.
Software Engineering ist gekennzeichnet durch ein sehr komplexes Praxisfeld sowie eine Vielzahl zu trainierender Kompetenzen, die zudem von der jeweiligen Rolle abhängen, die ein Software Ingeni-‐‑ eur einnimmt. Damit ist der Wissenstransfer von der Theorie auf die praktische Anwendung im Software Engineering eine besondere Herausforde-‐‑ rung. Lernen von Software Engineering muss also auf den sehr komplexen Anwendungskontext aus-‐‑ gerichtet sein und wird von zahlreichen Faktoren beeinflusst. Um Anhaltspunkte für Ausgangshypo-‐‑ thesen und einen möglichst umfassenden Blick auf diese Einflussfaktoren zu erhalten, ist es sinnvoll, diese Faktoren auf einer detaillierteren Ebene sys-‐‑ tematisch zu analysieren.
Wird vor diesem Hintergrund die Grounded Theo-‐‑ ry auf das Lernen von Software Engineering ange-‐‑ wandt, ergibt sich folgendes konkretes Vorgehen: Die Kompetenzbeschreibungen ermöglichen einen Vergleich von tatsächlich zu verschiedenen Zeit-‐‑ punkten bei verschiedenen Studierendengruppen erhobenen Ist-‐‑ mit den zu erreichenden Soll-‐‑ Kompetenzen. Auf Grundlage dieser Ergebnisse werden Hypothesen zu den Einflussfaktoren auf das Lernen von Software Engineering gebildet und überprüft. Konkret bedeutet dies, dass zunächst sowohl die Soll-‐‑Kompetenzen als auch die Ist-‐‑Kom-‐‑ petenzen Studierender erhoben werden.
Dann werden gezielt Einflussvariablen auf den Lernprozess modifiziert und die studentischen Ist-‐‑ Kompetenzen zu einem späteren Zeitpunkt erneut erhoben. Zuvor definierte Messkriterien zeigen, ob und in welchem Maß sich die Kompetenzen verän-‐‑ dert haben, und lassen Rückschlüsse auf die verän-‐‑ derten Einflussvariablen zu. Diese Messkriterien werden über konkrete, auf die Rahmenbedingun-‐‑ gen angepasste Lehrziele aus den Soll-‐‑Kompeten-‐‑ zen abgeleitet.
Dieser Prozess wird mehrfach durchlaufen, um ein besseres Verständnis über die Einflussfaktoren auf das Lernen von Software Engineering zu erhal-‐‑ ten und um so den Lernprozess möglichst kompe-‐‑ tenzfördernd gestalten zu können.
Ausgehend von ersten Hypothesen und Daten sollen gezielte Veränderungen und Modifikationen an den Lehr-‐‑Lern-‐‑Prozessen vorgenommen und dokumentiert werden, so dass Schritt für Schritt bestehende Lehrveranstaltungen weiterentwickelt werden können. Dabei werden -‐‑ wie bereits be-‐‑ schrieben -‐‑ Messkriterien festgelegt, anhand derer Kompetenzentwicklung zu verschiedenen Zeit-‐‑ punkten ablesbar und vergleichbar sein soll. Diese Daten werden dann zu verschiedenen Zeitpunkten erhoben. Aus dem Vergleich der veränderten Ein-‐‑ flussvariablen und den Messwerten der Soll-‐‑ und Ist-‐‑Kompetenzen zu verschiedenen Zeitpunkten werden so Rückschlüsse auf mögliche lernfördern-‐‑ de Einflussfaktoren gezogen, die dann gezielt mo-‐‑ difiziert werden.
Somit gliedert sich das Vorgehen in zwei we-‐‑ sentliche Schritte: Das Strukturieren und gezielte Verändern von Einflussvariablen auf den Lernpro-‐‑ zess und die Kompetenzanalysen zu verschiedenen Zeitpunkten.
Abb. 4: Überblick über das Forschungsdesign
Um die Einflussfaktoren auf Lehr-‐‑Lern-‐‑Prozesse
systematisch erfassen zu können, wurden diese
zunächst in Struktur-‐‑, Prozess-‐‑ und Ergebnisvariab-‐‑
len
Um Kompetenzen zu verschiedenen Zeitpunkten erfassen und dokumentieren und Vergleiche anstel-‐‑ len zu können, ist ein einheitliches Beschreibungs-‐‑ schema erforderlich.
Während zu fachlichen Kompetenzen zahlrei-‐‑ che Vorarbeiten zu finden sind, existieren für über-‐‑ fachliche Kompetenzen nur sehr allgemeingültige Einteilungen (vgl. Kap. 3). Daher werden fachliche und überfachliche Kompetenzen separat betrachtet, wodurch sich auch das Vorgehen unterscheidet.
SWEBOK strukturiert fachliche Inhalte des Soft-‐‑ ware Engineering und bietet somit einen Anhalts-‐‑ punkt, welche fachlichen Kompetenzen im Soft-‐‑ ware Engineering relevant sein können.
Allerdings vernachlässigt SWEBOK überfachli-‐‑ che Kompetenzen völlig. Zudem ist keine mit SWEBOK vergleichbare "ʺLandkarte"ʺ für überfachli-‐‑ che Kompetenzen im Software Engineering be-‐‑ kannt. Auch ist noch unklar, wie trennscharf sich überfachliche Kompetenzen unterscheiden lassen. Lässt sich eine Kompetenz eindeutig beispielsweise den motivationalen oder volitionalen Kompetenzen zuordnen? Diese Frage ist erst nach Erhebung ers-‐‑ ter konkreter überfachlicher Kompetenzen zu be-‐‑ antworten.
Da im Bereich überfachlicher Kompetenzen für Software Engineering also noch keinerlei Vorerhe-‐‑ bungen oder vorstrukturierende Daten vorhanden sind, sind somit die zu erwartenden Inhalte unklar. Daher bietet sich ein iteratives Forschungsdesign an, das bottom-‐‑up mit völlig offenem Blick über-‐‑ fachliche Kompetenzen erfasst und dann erst struk-‐‑ turiert. Es wurde ohne ein vorhandenes Schema zur Beschreibung der Kompetenzen begonnen. Dieses entsteht erst parallel mit der Datenerhe-‐‑ bung. Die Entwicklung eines Beschreibungsmo-‐‑ dells für überfachliche Kompetenzen ist einer ers-‐‑ ten Datensammlung nachgelagert.
Überfachliche Soll-‐‑Kompetenzen werden aus Sicht unterschiedlicher Stakeholder und zunächst in einem ersten Schritt aus Sicht von Unternehmen für den Bereich Kerninformatik ermittelt. Dazu wurden Interviews, die zu den fachlichen Kompe-‐‑ tenzen geführt wurden (siehe unten), nochmals im Hinblick auf überfachliche Kompetenzen ausge-‐‑ wertet. Durch die Nähe zur Datenbasis der Inter-‐‑ views entsteht in diesem bottom-‐‑up-‐‑Prozess ein Verständnis für die überfachlichen Kompetenzen und ihre Ausprägung. Dieses Vorgehen ermöglicht einen unverstellten Blick auf die tatsächlichen Er-‐‑ fordernisse im Berufsleben und erzeugt schon wäh-‐‑ rend des Forschungsprozesses ein Gefühl dafür, was etwa mit "ʺTeamfähigkeit"ʺ gemeint ist. Sonst häufig wenig aussagekräftige Worthülsen wie z.B. Teamfähigkeit erfahren durch dieses bottom-‐‑up-‐‑ Vorgehen eine Konkretisierung für den Bereich Software Engineering. Dies ist auch der Grund, warum es in einem ersten Schritt nicht sinnvoll ist, Stakeholder direkt danach zu fragen, welche über-‐‑ fachlichen Kompetenzen benötigt werden. Als Antwort wäre primär eine Aufzählung dieser Worthülsen zu erwarten, es bliebe jedoch offen, was genau im Kontext von Software Engineering darunter zu verstehen ist.
Als erster Schritt zu einem Beschreibungssche-‐‑ ma für überfachliche Kompetenzen wurden die vorhandenen Interviews zunächst im Hinblick auf jegliche überfachliche Aussagen codiert. Es ent-‐‑ standen 32 Codes, die unterschiedlich häufig auf-‐‑ traten. Diese Codes deuten auf ein Schema zur Beschreibung überfachlicher Kompetenzen hin, sind jedoch noch weiter zu clustern und zu struktu-‐‑ rieren. Gemäß Grounded Theory geschieht dies parallel mit der Erhebung und Auswertung weite-‐‑ rer Daten. In diesem iterativen Prozess entsteht somit neben dem Beschreibungsschema für über-‐‑ fachliche Kompetenzen zeitgleich auch die inhaltli-‐‑ che Beschreibung überfachlicher Kompetenzen, die ein Software Ingenieur benötigt.
Aufgrund anderer Voraussetzungen und Vor-‐‑ kenntnisse wurde bei fachlichen Kompetenzen zuerst top-‐‑down ein theoretisches Modell entwi-‐‑ ckelt und in einem zweiten Schritt mit konkreten Daten, also Kompetenzen, gefüllt und validiert. Das vorgeschlagene Modell zur Beschreibung fach-‐‑ licher Kompetenzen wurde so in einer Pilotstudie auf seine Verwendbarkeit überprüft. Dazu wurden mittels halbstrukturierter Interviews fachliche Soll-‐‑ Kompetenzen erhoben und klassifiziert, die Unter-‐‑ nehmen von Absolventen im Bereich Kern-‐‑Infor-‐‑ matik erwarten.
Als Grundlage für mögliche Inhalte und somit für den Interviewleitfaden wurde u.a. SWEBOK herangezogen. Um auch angrenzende Themen-‐‑ komplexe wie beispielsweise Programmiertechni-‐‑ ken und Datenbanken einfließen zu lassen, wurden auch entsprechende fachliche Inhalte vorhandener Lehrveranstaltungen berücksichtigt.
Es wurden Gespräche mit sieben Vertreten von Wirtschaftsunternehmen verschiedener Branchen (vgl. Tabelle 1) im Bereich Software Engineering geführt, aufgezeichnet, transkribiert und ausgewer-‐‑ tet. Befragt wurden einerseits Personen mit Ent-‐‑ scheidungskompetenz bei der Auswahl neuer Mit-‐‑ arbeiter und Nähe zu den fachlichen Inhalten, also z.B. Geschäftsführer oder Gruppen-‐‑/Abteilungs-‐‑ leiter, andererseits Absolventen der eigenen Hoch-‐‑ schule mit inzwischen mehrjähriger Berufserfah-‐‑ rung.
Nr Branche
der ehem. Absol-‐‑ vent(in) 1 2 3
4 5 6 7
und Betrieb einer Marketingplattform
und Betrieb einer Marketingplattform
X
Tabelle 1: Zusammensetzung der Stichprobe Zwar gewährleistet diese Auswahl noch keine re-‐‑ präsentative Stichprobe, aber immerhin eine relativ gute Abdeckung des fachlichen Spektrums und unterschiedliche Perspektiven. Folgt man der Grounded Theory, genügt dies, um erste Annah-‐‑ men und Hypothesen zu bilden, die dann den Ausgangspunkt für die weitere Forschung bilden, jedoch noch nicht den Anspruch haben, eine bereits vorhandene These zu validieren.
Zunächst sind Kompetenzen mittels eines geeigne-‐‑ ten Modells zu analysieren und beschreiben. Dazu wurden existierende Klassifikationsschemata auf ihre Eignung im EVELIN-‐‑Kontext überprüft.
Die Untersuchung vorhandener Schemata ergab ein klares Bild der Anforderungen an ein geeignetes Beschreibungsmodell im EVELIN-‐‑Kontext. Ein Kompetenzprofil für Software Engineering ist keine rein inhaltliche Sammlung von Stichworten, denn aufgrund der Anwendung in verschiedenen Fach-‐‑ disziplinen soll es auch ausdrücken können, wie gut Studierende die jeweilige Kompetenz beherr-‐‑ schen. Auch darf ein Kompetenzprofil nicht auf Lehrzielebene formuliert sein, denn hier muss auf-‐‑ grund der verschiedenen Schwerpunkte einzelner Studiengänge und der Vorstellungen und Priorisie-‐‑ rungen der Lehrenden eine gewisse Flexibilität vorhanden sein. Gleichzeitig muss ein Beschrei-‐‑ bungssystem auch die Beschreibung, Strukturie-‐‑ rung und Einordnung von Lehrzielen unterstützen, so dass es als "ʺKompass"ʺ für die Lehr-‐‑Lern-‐‑Planung anwendbar ist. Die Lehrziele leiten sich aus dem entsprechenden Kompetenzmodell ab.
Das Modell soll die Beschreibung von Soll-‐‑ und Ist-‐‑Kompetenzen zu verschiedenen Zeitpunkten und deren Vergleich ermöglichen. Da dieses Be-‐‑ schreibungsmodell ein Werkzeug für Planung, Messung und Analyse sein soll, muss es möglichst einfach, aber dennoch ausreichend ausdruckskräf-‐‑ tig, verständlich und handhabbar sein.
Wichtig ist auch die Kompatibilität mit anderen
Denkansätzen und Beschreibungsmodellen wie z.B.
der Taxonomie von Lernzielen im kognitiven Be-‐‑
reich nach
Auch sollte eine Hierarchie aufeinander auf-‐‑ bauender Kompetenzen zwar abbildbar, jedoch nicht zwingend sein.
Klassifikationsschemata für Lernaufgaben und Taxonomien für Software Engineering-‐‑Inhalte wurden mit diesen Anforderungen abgeglichen.
Die Taxonomie kognitiver Lernziele von
Anderson und Krathwohl (2001) veröffentlich-‐‑ ten eine überarbeitete Fassung der Taxonomie nach Bloom. Gegenüber der Ursprungstaxonomie wur-‐‑ den zunächst die Klassen in aktive Verben umbe-‐‑ nannt und die beiden letzten vertauscht, da dies nach Meinung der Autoren der steigenden Kom-‐‑ plexität der kognitiven Prozesse besser entspricht. Die wesentliche Änderung ist jedoch die Einfüh-‐‑ rung einer zweiten Dimension, welche die Art des Wissens repräsentiert. Damit ergibt sich das in Ab-‐‑ bildung 1 gezeigte zweidimensionale Schema, das zwischen einer kognitiven und einer Wissensdi-‐‑ mension unterscheidet. Abb. 1: Lernzieltaxonomie nach Anderson und
Krathwohl (2001) Eine weitere Änderung ist der Verzicht auf die kumulativen Eigenschaften der Klassen.
Bei der Anwendung dieser Taxonomie zeigen
sich jedoch grundlegende Probleme. Lehrziele bzw.
Kompetenzen müssen in diesem Schema immer
sowohl einer Wissenskategorie als auch einer Kate-‐‑
gorie in der kognitiven Dimension zugeordnet
werden. Dabei soll die Formulierung der Lehrziele
einen Hinweis für die Einordnung in das Schema
geben, was auch die eigentliche Intension des Mo-‐‑
dells erkennen lässt: Es soll in erster Linie ein Pla-‐‑
nungs-‐‑ und Kontrollwerkzeug für den Unterricht
sein und geht davon aus, dass bereits formulierte
Lehrziele existieren
Fuller et al. (2007) untersuchten verschiedene
Taxonomien zur Beschreibung von Kompetenzen
im Bereich der Informatik, darunter auch die Taxo-‐‑
nomien nach Bloom sowie nach Anderson und
Krathwohl. Ihre Erkenntnisse decken sich weitge-‐‑
hend mit denen der Untersuchung im Rahmen von
EVELIN. Darunter fällt etwa die problematische
Einordnung in höhere Klassen, die Fragwürdigkeit
der hierarchischen Ordnung bei Bloom sowie die
zu hohe Komplexität des zweidimensionalen Mo-‐‑
dells von Anderson
Abb. 2: Matrix-‐‑Taxonomie
Zunächst wird ein Zielfeld für eine Kompetenz festgelegt, das Studierende über verschiedene Pfa-‐‑ de erreichen können. Dabei bewegt sich der Lern-‐‑ prozess vom Startpunkt aus sequenziell entlang der Ebenen zum nächsthöheren Level. Im Lernprozess kann kein Feld übersprungen werden und es ist immer nur eine Bewegung von links nach rechts bzw. von unten nach oben möglich. Im Normalfall beginnt der Lernprozess dabei in REMEBER | NONE (-‐‑).
Hier wird deutlich, dass eine andere Zielset-‐‑ zung als die unseres Projektes vorliegt. Bei Fuller et al. liegt der Fokus auf der Beschreibung, Beobach-‐‑ tung und Planung von Lernpfaden einzelner Stu-‐‑ dierender oder homogener Studierendengruppen. Während Fuller et al. Prozesse analysieren, beab-‐‑ sichtigt EVELIN, zunächst "ʺZustände"ʺ zu beschrei-‐‑ ben.
Keines der analysierten Modelle eignet sich unein-‐‑ geschränkt für eine Kompetenzbeschreibung im Rahmen von EVELIN. Für fachliche Kompetenzen wurde daher ein eigenes Modell entwickelt, das bewusst wesentliche Elemente bestehender Taxo-‐‑ nomien aufgreift, um sie im Hinblick auf die bereits genannten Anforderungen sinnvoll zu kombinieren und zu erweitern.
Das EVELIN-‐‑Modell (vgl. Abbildung 3) besteht aus den Klassen Erinnern, Verstehen, Erklären, Verwenden, Anwenden und (Weiter-‐‑)Entwickeln, die sich wie folgt charakterisieren lassen: Abb. 3: EVELIN-‐‑Modell zur Beschreibung fachli-‐‑ cher Kompetenzen
• sich an Informationen erinnern und sie wortge-‐‑ nau wiedergeben können Verstehen • den Sinn / die Bedeutung von Informationen verstehen • definieren können • implizites Wissen • thematisch zugehörige, aber neue Informatio-‐‑ nen zuordnen können Erklären • Zusammenhänge, Abhängigkeiten und Ähn-‐‑ lichkeiten zwischen Informationen erkennen und in eigenen Worten erklären können • Ursache-‐‑Wirkungs-‐‑Zusammenhänge theore-‐‑ tisch benennen können • Informationen strukturieren können • Vor-‐‑ und Nachteile erkennen, bewerten und theoretisch analysieren • Verorten von Informationen in Systemen • sachliche Analyse • begründen
• Anwenden in definiertem / eingeschränktem
Kontext und / oder unter Anleitung • Umsetzung in kleinen Schritten oder mittels einer Schablone • "ʺKochen nach Rezept"ʺ • Verstehen muss keine Rolle spielen
• selbständiges, eigenverantwortliches Anwen-‐‑ den auch in "ʺschwierigem"ʺ Umfeld und / oder Lösungswege situationsgerecht auswählen und umsetzen können • Verstehen spielt eine Rolle (Weiter-‐‑)Entwickeln • Nutzen von vorhandenem Wissen zur Entwick-‐‑ lung oder Weiterentwicklung von Lösungen • Schaffen von neuen Erkenntnissen, Forschung Dabei sind Erinnern, Verstehen und Erklären auf theoretischer Ebene angesiedelt, während Verwen-‐‑ den, Anwenden und Entwicklung mit praktischer Umsetzung verbunden sind.
Wie in Abschnitt 6.3. beschrieben, wurde eine Be-‐‑ fragung von Unternehmensvertretern durchge-‐‑ führt. Da die Ergebnisse nur einen Baustein in Form einer ersten Datenerhebung zur Bildung von Hypothesen bei der Erstellung der Soll-‐‑ Kompetenzprofile darstellen, können die Aussagen zu einzelnen Kompetenzen auch noch nicht zu eindeutigen Ausprägungen verdichtet werden, sondern zeigen Tendenzen auf. Dazu trägt auch bei, dass Unternehmen wegen unterschiedlicher Tätigkeitsschwerpunkte unterschiedliche Vorstel-‐‑ lungen von Software Engineering haben. Die Ent-‐‑ wicklung von Software für Banken und Versiche-‐‑ rungen hat etwa auch Auswirkungen auf die er-‐‑ warteten Kompetenzen im Bereich Softwaretest. Nachfolgend werden wesentliche Ergebnisse der Untersuchung dargestellt, eine detaillierte Diskus-‐‑ sion findet sich in Claren (2012).
Bei Vorgehensmodellen gibt es eine Tendenz hin zu umfangreichen theoretischen Kompetenzen. So erwarten die Befragten sowohl bei agilen als auch bei plan-‐‑getriebenen Modellen eher Kompetenzen, die sich mit "ʺErklären"ʺ klassifizieren lassen. Eine gute theoretische Basis ist hier wichtig, da die Vor-‐‑ gehensmodelle meist unternehmensspezifisch an-‐‑ gepasst sind und dafür bei Neueinsteigern eine Einarbeitung erforderlich ist. Lediglich bei testge-‐‑ triebener Entwicklung ist die Ausprägung "ʺAn-‐‑ wendung"ʺ stärker vertreten.
Beim Thema Requirements Engineering erwarten die Befragten ein Verständnis dafür, welche Rollen Lasten-‐‑ bzw. Pflichtenhefte im Anforderungspro-‐‑ zess einnehmen. Auch wenn die Mehrheit der Be-‐‑ fragten keine spezielle Technik zur Formulierung von Anforderungen nutzt, erwartet sie dennoch grundlegendes Verständnis dafür, wie sich gute von schlechten Anforderungen unterscheiden. Ab-‐‑ solventen sollten Techniken zur Anforderungser-‐‑ hebung sicher und gezielt anwenden können.
Im Gebiet der Modellierung werden deutlich an-‐‑ wendungsorientierte Kompetenzen erwartet. Ab-‐‑ solventen sollten sowohl im Bereich der System-‐‑ modellierung (z.B. mit der UML) als auch der Da-‐‑ tenmodellierung (z.B. ER-‐‑Modelle) ausgeprägte praktische Erfahrungen im Studium sammeln. Im Gegensatz dazu spielt das Thema Prozessmodellie-‐‑ rung bei den Befragten eine eher untergeordnete Rolle.
Auch im Themenkomplex Datenbanken dominie-‐‑ ren praktisch ausgerichtete Kompetenzen. Vor al-‐‑ lem bei Datenbankentwurf und Datenabfrage er-‐‑ warten die meisten Befragten Kompetenzen auf dem Niveau "ʺAnwenden"ʺ. Auch bei der Daten-‐‑ bankprogrammierung, wie z. B. dem Erstellen von Triggern und Funktionen, gibt es eine leichte Ten-‐‑ denz in diese Richtung, wobei es manchen Inter-‐‑ viewten hier auch genügt, wenn Absolventen "ʺver-‐‑ stehen"ʺ.
Hier lassen sich bei zwei Kompetenzen Aussagen über die erwarteten Ausprägungen treffen. Bei der Beherrschung objektorientierter Programmiertech-‐‑ niken sind sich die Befragten überwiegend einig, dass sich ein Absolvent auf Anwendungsniveau befinden sollte. Bei Design-‐‑Patterns werden keine praktischen Kompetenzen erwartet. Berufseinstei-‐‑ ger sollten nach Meinung der Befragten begreifen, was hinter diesem Begriff steckt, und die Prinzipien grundlegender Entwurfsmuster verstehen.
Bei Kompetenzen im Bereich Softwaretest sind die Meinungen sehr unterschiedlich. Lediglich bei "ʺUnittest"ʺ und "ʺTestfallentwurf"ʺ können die Mehr-‐‑ zahl der Antworten mit "ʺAnwenden"ʺ klassifiziert werden. Außerdem wird erwartet, dass Studienab-‐‑ solventen die grundlegenden Eigenschaften, Unter-‐‑ schiede und Zusammenhänge verschiedener Test-‐‑ metriken verstanden haben.
Die Erwartungen im Bereich Konfigurationsma-‐‑ nagement lassen sich auf rein theoretische Kompe-‐‑ tenzen reduzieren. Bei den Themen Change Ma-‐‑ nagement, Build Management / Continuous In-‐‑ tegration sowie Versionskontrollmechanismen können alle Antworten den theoretischen Klassen "ʺErinnern"ʺ, "ʺVerstehen"ʺ und "ʺErklären"ʺ zugeordnet werden. Die Erwartungen bei Build Management sind am geringsten, da sich Absolventen nur an grundlegende Aspekte "ʺerinnern"ʺ sollen. Bei Chan-‐‑ ge Management oder Versionskontrolle variieren die Antworten stark, jedoch jeweils mit leichter Tendenz zu "ʺErklären"ʺ.
Projektmanagement ist überwiegend durch über-‐‑ fachliche Kompetenzen geprägt (z.B. Kommunika-‐‑ tions-‐‑ und Teamfähigkeit). Fachliche Kompetenzen spielen zunächst kaum eine Rolle, da es eher unüb-‐‑ lich ist, dass ein Absolvent sofort ein Projekt leitet.
Wie bereits erläutert kann derzeit noch kein exaktes Schema angegeben werden, das beschreibt, in wel-‐‑ cher Ausprägung welche überfachlichen Kompe-‐‑ tenzen für Software Engineering konkret erforder-‐‑ lich sind. Es lässt sich jedoch ein erster Eindruck vermitteln, welche Kompetenzen konkret für den Bereich Software Engineering benötigt werden und was darunter zu verstehen ist. Derzeit handelt es sich um die Sichtweise von Software Ingenieuren und Führungskräften. Es geht im Folgenden nicht darum, die genannten Kompetenzen quantitativ aufzuzählen, sondern vielmehr zu verstehen, was zentrale Anforderungen an einen Software Ingeni-‐‑ eur sind und was damit gemeint ist.
Dazu wurden in den Interviews insgesamt 306 Stellen codiert, die Rückschlüsse auf überfachliche Kompetenzen zulassen. Insgesamt wurden 32 Codes vergeben, wobei sich über 70 % der codier-‐‑ ten Stellen auf die 12 am häufigsten genannten Codes verteilen (vgl. Tabelle 2).
Anzahl Anteil Doku-‐‑ Codings an allen ku-‐‑ in % mente Code
keit/ Kreativität
tionsstrukturen
36
30
28
18
18
16
16
15
14
13
12
10
Unternehmen erwarten also fachlich gut ausgebil-‐‑
dete Absolventen, die in der Lage sind, komplexe
Prozesse in Unternehmen zu verstehen. Mitarbeiter
im Bereich Software Engineering sollen ihre eigene
Fachlichkeit realistisch einschätzen. Sie sollen zwar
in der Lage sein, sich mit ihrem Wissen im Unter-‐‑
nehmen zu verorten, jedoch auch die Bereitschaft
mitbringen, sich in Aufbau-‐‑ bzw. Ablauforganisati-‐‑
onen einzufügen. Gleichzeitig wird eine gewisse
Aktivität und Selbständigkeit vorausgesetzt. Man
erwartet, keine genauen Vorgaben machen zu müs-‐‑
sen, wie und wann etwas zu tun ist. Vielmehr soll
ein Software Ingenieur sich innerhalb eines Korri-‐‑
dors aktiv und eigenverantwortlich bewegen und
seine Kompetenzen selbständig einbringen und
auch weiterentwickeln. Ebenso notwendig ist die
Bereitschaft, sich ständig auf Neues und Unvorher-‐‑
gesehenes einzulassen. Es wird erwartet, dass Ab-‐‑
solventen sich selbst und ihre Position im Unter-‐‑
nehmen realistisch einschätzen können und so im
Team und mit ihren Vorgesetzten konstruktiv zu-‐‑
sammenarbeiten und dabei ihren Platz und ihre
Rolle finden. Dies ist eng verknüpft mit drei zentra-‐‑
len Anforderungen, die am häufigsten in den Inter-‐‑
views genannt wurden: Problembewusstsein und
das Verstehen komplexer Prozesse gepaart mit dem
Faktor Zusammenarbeit/ Kommunikation. Zu ei-‐‑
nem ähnlichen Ergebnis kommen auch
Als zentrale Anforderung wird von einem Software Ingenieur ein ausgeprägtes Problembe-‐‑ wusstsein erwartet. Problembewusstsein meint, sich in einem komplexen Prozess zurechtzufinden und zu erkennen, wann welche Kompetenzen wie benötigt werden, und wann und wie sie zusam-‐‑ menhängen. Ein Interviewpartner beschreibt dies folgendermaßen: "ʺ... das ist auch so ein Thema, das wurde auch in meinem Studium behandelt, das kann man aber auch erst sozusagen verstehen und adaptieren, wenn man das Problembewusstsein hat, [...] weil man vielleicht schon das eine oder andere Problem wirklich erlebt hat, dass man sagt: o.k., ich habe jetzt eine gewisse Problemstellung und die muss ich irgendwie lösen und dann eben auch dieses Aha-‐‑Erlebnis gehabt hat [...]"ʺ
Ein anderer Interviewpartner formuliert die Si-‐‑ tuation so: "ʺDas Problem ist ja, man hört im Studi-‐‑ um viele Sachen, die einem erzählt werden und – da heißt es dann: o.k., das macht man so und das macht man so – aber man weiß im Grunde ge-‐‑ nommen ganz oft nicht, warum macht man das denn eigentlich so. Weil es gibt eigentlich zehn Möglichkeiten, etwas zu machen. Im Studium wer-‐‑ den vielleicht zwei Möglichkeiten beleuchtet [...] und dann hat man zwar gehört: Okay, das und das sollte man so machen, aber man weiß gar nicht, warum man das so machen muss und wenn jetzt jemand zu uns kommt, der sich eben über das Stu-‐‑ dium hinaus mit den Themen beschäftigt hat, dann ist es ganz oft auch der Fall, dass der eben – ja ver-‐‑ schiedene Möglichkeiten schon abgeklopft hat und dann auch – ja von sich aus verstehen kann, nach-‐‑ vollziehen kann warum manche Sachen notwendig sind."ʺ Auch ein dritter Befragter verlangt Ver-‐‑ ständnis dafür "ʺ...vor allem WARUM muss ich das verwenden, welchen Nutzen ziehe ich denn dar-‐‑ aus, wenn ich das mache."
Dabei geht es nicht ausschließlich um das Ver-‐‑ stehen und Einordnen von Fach-‐‑ und Faktenwis-‐‑ sen, sondern auch darum, die Tragweite und Zu-‐‑ sammenhänge komplexer Probleme bewusst wahr-‐‑ zunehmen. Ein Interviewpartner fasst diese Aspek-‐‑ te so zusammen: "ʺWenn man dann ins alltägliche Berufsleben hinein geschmissen wird, hat man eher das Problem, dass man von den ganzen… ja… Dingen, die da existierten, erst mal überwältigt ist."ʺ
Diese Zitate verdeutlichen, dass der Theorie-‐‑ Praxis-‐‑Transfer von Kompetenzen und Wissen eine zentrale Herausforderung darstellt, die offensicht-‐‑ lich für viele Absolventen nicht leicht zu meistern ist und auch die Unternehmen vor einige Probleme stellt. Umgekehrt ist es für die Hochschulausbil-‐‑ dung schwierig, den komplexen Praxisalltag in der Ausbildung abzubilden, so dass die zitierten Aha-‐‑ Erlebnisse für die Studierenden erfahrbar werden.
Eine weitere wichtige überfachliche Kompe-‐‑ tenz, die von fast allen Befragten genannt wurde, ist das Verstehen komplexer Prozesse. Für das Ein-‐‑ finden und angemessene Bewegen in diesen kom-‐‑ plexen Abläufen, die dem Software Engineering inhärent sind, ist es absolut notwendig, dass ein Software Ingenieur diese überblickt und versteht. Dies schließt auch "ʺeinen Weitblick über seinen eigenen Tellerrand hinaus"ʺ mit ein. Ein Befragter beschreibt dies so: "ʺAber das Prinzip muss er be-‐‑ greifen: wie spielt das alles zusammen."ʺ
Ein dritter, sehr wichtiger Komplex, auf den sich überfachliche Kompetenzen beziehen, ist der Bereich der Zusammenarbeit. Einer der Befragten bezeichnet das sehr treffend als "ʺTeamwork-‐‑ Alltag"ʺ. Ein anderer Befragter gibt hier einen Ein-‐‑ blick in den Arbeitsablauf: "ʺDieser kommunikative Austausch über Themen nicht nur im Daily Scrum mal ein paar Minuten, sondern eigentlich fachlich und konkret den ganzen Tag über, im Pairing, in immer wiederkehrenden Beratungssituationen. Wir haben auch die Teams grundsätzlich immer zu-‐‑ sammensitzen in Räumen oder an Tischinseln von Leuten, die im Team gemeinsam miteinander arbei-‐‑ ten. Dass also auch ein Austausch stattfindet, dass sie nicht nur sich von einem Zimmer ins andere eine E-‐‑Mail schreiben, sondern dass sie auch immer diesen mündlichen Kommunikationsweg und dass viele darüber sprechen -‐‑ das versuchen wir eigent-‐‑ lich in jeder Weise zu befördern."ʺ Insgesamt scheint der Faktor Zusammenarbeit zunehmend an Bedeu-‐‑ tung zu gewinnen, allerdings verändert sich die Arbeitsrealität in gleichem Maße. Ein Befragter fasst es zusammen: "ʺTeamfähigkeit ist allerdings immer besser ausgeprägt heute, weil eben immer mehr in der Ausbildung – Arbeiten im Team erle-‐‑ digt werden oder erledigt werden müssen. Das hat sich deutlich verbessert im Lauf der 25 oder 30 Jahre, die ich das jetzt betrachte. Am Anfang waren viele, viele, viele Einzelkämpfer da, das hat sich deutlich verbessert und das ist auch gut, die Ent-‐‑ wicklung ist gut."ʺ Auf der anderen Seite erkennen die Befragten noch immer Handlungsbedarf: "ʺIch sage mal so, die Leute haben scheinbar eine gewis-‐‑ se technische Kompetenz, aber wie man eine ver-‐‑ nünftige Präsentation macht, wie man einen ver-‐‑ nünftigen Text schreibt, wie man in einem Team umgeht, wie man Konflikte löst, das sind alles Themen, die hat der gewöhnliche Hochschulab-‐‑ gänger nicht gelernt."ʺ Ein weiterer sieht darin einen Ausweg für die Hochschulausbildung, "ʺ...dass man Projekte definiert, wo wirklich mal drei, vier, fünf Leute dabei sind. Wo man sich untereinander ab-‐‑ stimmen muss. Wo die Aufgaben auch so abge-‐‑ grenzt sind, dass man notgedrungen Schnittstellen zu anderen hat."ʺ Ein weiterer Befragter würde es auch gut finden, wenn den Studierenden auch Pro-‐‑ jektverantwortung für ein Studienprojekt überge-‐‑ ben würde. 10.
Insgesamt lässt sich festhalten, dass ein Software Ingenieur eine Vielzahl fachlicher und überfachli-‐‑ cher Kompetenzen benötigt. Nun stellt sich die Frage, wie man diese benötigten Kompetenzen in der Hochschulausbildung am besten fördern kann. Auf diesem Weg ist die Beschreibung der Soll-‐‑ Kompetenzen mittels eines Schemas, das diese zu verschiedenen Zeitpunkten vergleichbar macht, nur ein erster Schritt.
Die Analyse und Beschreibung der Soll-‐‑ Kompetenzen für Software Engineering muss noch ausgebaut werden. Dies ist für sowohl für Kernin-‐‑ formatik als auch für alle anderen beteiligten Berei-‐‑ che wie Mechatronik oder Studiengänge mit nicht primärem Informatikbezug notwendig. Um die Tragfähigkeit der erhobenen Kompetenzprofile weiter zu erhöhen, werden auch die Ergebnisse anderen beteiligten Verbundhochschulen berück-‐‑ sichtigt. Neben der Ausweitung der Datenbasis ist es zudem notwendig, weitere Blickwinkel neben der unternehmerischen Sicht einzubinden. Sinnvoll ist es, beispielsweise auch Absolventen, Studieren-‐‑ de oder Personalverantwortliche mit einzubezie-‐‑ hen. Auch kann es sinnvoll sein, die entstandenen Kompetenzprofile für die verschiedenen Bereiche wie Kerninformatik oder Mechatronik miteinander zu vergleichen.
Besonders für überfachliche Kompetenzen gilt es, ein Beschreibungsschema zu entwickeln, das nahezu die gleichen Anforderungen erfüllt wie das für fachliche Kompetenzen. Dieses Modell entsteht parallel zur Analyse der vorhandenen Interviewda-‐‑ ten mit Fokus auf überfachlichen Kompetenzen. Dabei sollen überfachliche Kompetenzen sowohl strukturiert als auch definiert werden. Es gilt, die Frage zu beantworten, was im Kontext von Soft-‐‑ ware Engineering etwa unter Team-‐‑ oder Kommu-‐‑ nikationsfähigkeit verstanden wird. Eine weitere interessante Fragestellung ist, ob überhaupt und ggf. welche Korrelationen zwischen fachlichen und überfachlichen Kompetenzen auftreten. Werden einzelne überfachliche Kompetenzen besonders häufig im Zusammenhang mit einer oder mehreren bestimmten fachlichen Kompetenzen genannt? Für beide Schemata und ihren Inhalt gilt derselbe itera-‐‑ tive Prozess, in dem die Daten auch während des gesamten Forschungsprojektes EVELIN immer wieder überprüft und weiterentwickelt werden. Gemäß Grounded Theory fließen ständig neue Erkenntnisse und Aspekte ein, so dass ein mög-‐‑ lichst umfassendes Bild zum Lehren und Lernen von Software Engineering entstehen kann.
Parallel dazu findet eine weitere didaktische und inhaltliche Analyse der aktuellen Lehr-‐‑Lern-‐‑ Konzepte für Software Engineering und der Ein-‐‑ flussvariablen auf die Lernprozesse statt. Die fach-‐‑ lichen Inhalte von Lehrveranstaltungen werden wiederum in die Weiterentwicklung von Soll-‐‑Kom-‐‑ petenzprofilen einfließen. Zudem ist bei der Ent-‐‑ wicklung didaktischer Konzepte eine detaillierte Berücksichtigung der zu vermittelnden Inhalte un-‐‑ umgänglich.
Sobald konkretere Soll-‐‑Kompetenzprofile vor-‐‑
liegen, ist die Sichtweise der Lehrenden stärker ein-‐‑
zubinden. Die Lehrenden nehmen im Lernprozess
der Studierenden eine Schlüsselposition ein und
prägen besonders auch durch ihre Vorstellungen
und "ʺDefinitionen gelungenen Lernens"ʺ
Weitere zu erhebende Daten sind die Erwar-‐‑ tungen, Motivationen und Vorkenntnisse der Stu-‐‑ dierenden. In diesem Kontext stellt sich unter ande-‐‑ rem die Frage, ob Studierende, die sich für ein be-‐‑ stimmtes Fach entscheiden, signifikante Eigen-‐‑ schaften aufweisen. Auch das sind Faktoren, auf die Lehr-‐‑Lern-‐‑Konzepte zugeschnitten werden müssen. Können sowohl bei den Lehrenden als auch bei den Studierenden gewisse Systematiken oder Muster erkannt werden, die bei der Entwick-‐‑ lung didaktischer Konzepte berücksichtigt werden müssen und zumindest für Software Engineering oder Teilbereiche davon signifikant auftreten?
So soll versucht werden, die Lücke zwischen den Soll-‐‑ und Ist-‐‑Kompetenzen der Studierenden Schritt für Schritt zu verringern und die Hoch-‐‑ schulausbildung im Software Engineering noch weiter zu verbessern.
Wir danken den Gutachtern für hilfreiche Anmer-‐‑ kungen zu einer früheren Version dieses Beitrags.
Das Projekt EVELIN wird gefördert durch das Bundesministerium für Bildung und Forschung unter der Fördernummer 01PL12022A.