=Paper=
{{Paper
|id=None
|storemode=property
|title=Welche Kompetenzen benötigt ein Software Ingenieur?
|pdfUrl=https://ceur-ws.org/Vol-956/S4_Paper4.pdf
|volume=Vol-956
|dblpUrl=https://dblp.org/rec/conf/seuh/SedelmaierCL13
}}
==Welche Kompetenzen benötigt ein Software Ingenieur?==
https://ceur-ws.org/Vol-956/S4_Paper4.pdf
Welche Kompetenzen benötigt ein
Software Ingenieur?
Yvonne Sedelmaier, Sascha Claren, Dieter Landes, Hochschule für angewandte Wissen-
schaften Coburg
{sedelmaier, sascha.claren, landes}@hs-coburg.de
Zusammenfassung gewissen Verständnis für den künftigen Anwen-‐‑
dungskontext der zu entwickelnden Software aus-‐‑
Software ist Teil der modernen Welt und nahezu
gestattet sein, um funktionale und nichtfunktionale
überall zu finden. Daher gewinnt Software Engine-‐‑
Anforderungen möglichst umfassend erheben zu
ering zunehmend an Bedeutung. Um Software zu
können. Dies setzt ein gewisses Maß an Empathie
entwickeln oder weiterzuentwickeln, sind vielfälti-‐‑
und Weitblick voraus, sich in die künftige Anwen-‐‑
ge Kompetenzen und Kenntnisse nötig. Das stellt
dungssituation und den Anwender hineinzuver-‐‑
auch die Hochschulausbildung und damit verbun-‐‑
setzen. So birgt jede Rolle im Prozess des Software
den die didaktische Forschung im Software Engi-‐‑
Engineering ihre besonderen Herausforderungen.
neering vor große Herausforderungen.
Software Ingenieure müssen sich jedoch unab-‐‑
In diesem Beitrag wird zunächst das For-‐‑
hängig von ihrer Rolle in ein Entwicklungsteam
schungsinteresse beschrieben und begründet. Dann
eingliedern können und benötigen neben ihrem
wird der Kompetenzbegriff diskutiert und erläu-‐‑
fachlichen Wissen auch eine Vielzahl weiterer
tert. Nachfolgend werden die methodischen Schrit-‐‑
Kompetenzen. So müssen sie etwa in der Lage sein,
te beschrieben, mit denen das Kompetenzprofil
Herausforderungen und Probleme rechtzeitig zu
eines Software Ingenieurs erhoben wird. Dabei
erkennen und einzuschätzen, benötigen also ein
wird zunächst die Vorgehensweise beschrieben,
gewisses Problembewusstsein, um im richtigen
bevor erste Ergebnisse vorgestellt werden. Zuletzt
Moment angemessen agieren und reagieren zu
folgt ein Ausblick, wie die Hochschulausbildung
können. Software Ingenieure müssen ihr erworbe-‐‑
im Software Engineering noch besser auf Kompe-‐‑
nes Wissen ständig auf neue Situationen anpassen
tenzentwicklung ausgerichtet werden kann.
und erlernte Methoden selbständig anwenden.
Dieser Artikel konkretisiert und strukturiert
1. Motivation den Kompetenzbegriff im Kontext von Software
Durch die stetig wachsende Komplexität von Soft-‐‑ Engineering und stellt ein Modell zur Beschreibung
ware steigen auch die Anforderungen an Informa-‐‑ von Kompetenzen vor. Er beleuchtet, wie es entwi-‐‑
tiker, die mit einer zunehmenden Anzahl von ckelt wurde und welche Anforderungen es erfüllen
komplexen Rollen, Schnittstellen und Aufgaben soll. Er zeigt auf Grundlage des vorgeschlagenen
konfrontiert werden. Beschreibungsmodells erste Ergebnisse zu Soll-‐‑
Software wird häufig in großen Teams mit ei-‐‑ Kompetenzen eines Software Ingenieurs.
ner Vielzahl fachlicher Rollen entwickelt. Das reicht
vom Anforderungsanalysten über den Software Ar-‐‑ 2. Forschungsinteresse
chitekten und den Programmierer bis hin zum
Ein Software Ingenieur benötigt neben einer Viel-‐‑
Software Tester. In jeder dieser Rollen sind zum
zahl an fachlichen auch überfachliche Kompeten-‐‑
Teil sehr unterschiedliche Kompetenzen notwen-‐‑
zen, damit er sein fachliches Wissen in komplexen
dig. Da Software normalerweise nicht für Informa-‐‑
Situationen überhaupt erfolgreich umsetzen kann.
tiker, sondern für "ʺfachfremde"ʺ Auftraggeber ent-‐‑
Da es in Lernprozessen keine direkten und klaren
wickelt wird, muss zum Beispiel derjenige, der
Ursache-‐‑Wirkungs-‐‑Zusammenhänge gibt, können
Anforderungen erhebt, über ein hohes Maß an in-‐‑
Kompetenzen lediglich trainiert und gefördert,
terdisziplinärer Kommunikationsfähigkeit verfü-‐‑
jedoch nicht direkt vermittelt werden. Das stellt die
gen. Ein Software Ingenieur im Bereich Anforde-‐‑
Hochschulausbildung im Software Engineering vor
rungsanalyse muss in der Lage sein, sich auf für
große Herausforderungen. Sie möchte sowohl fach-‐‑
ihn fremde Denkmuster und Denkstrukturen ein-‐‑
liche als auch überfachliche Kompetenzen im Soft-‐‑
zulassen, sie zu verstehen und auch zwischen
ware Engineering trainieren. Daher starteten sechs
ihnen und der Informatik zu vermitteln. Des Weite-‐‑
bayerische Hochschulen das Projekt EVELIN (Ex-‐‑
ren muss ein Anforderungsanalytiker mit einem
A. Spillner, H. Lichter (Hrsg.): SEUH 13 117
perimentelle VErbesserung des Lernens von Soft-‐‑ Somit beschreiben überfachliche Kompetenzen hier
ware EngINeering), um genau hier anzusetzen und diejenigen Kompetenzen, die gemeinhin nicht di-‐‑
das Lehren und Lernen von Software Engineering rekt als "ʺFachwissen"ʺ bezeichnet werden, sondern
in seiner gesamten Bandbreite besser verstehen zu vielmehr alle Fähigkeiten, die nötig sind, um
können und im Rahmen der Hochschullehre zielge-‐‑ Fachwissen situationsbezogen und zielgerichtet in
richtet Rahmenbedingungen zu schaffen, die das komplexen Situationen anwenden zu können.
Trainieren von Kompetenzen optimal ermöglichen. Die derzeitige Unterscheidung von lediglich
Bevor es aber möglich ist, sich darüber Gedan-‐‑ zwei Kompetenzarten ohne weitere Unterteilungen
ken zu machen, wie man am besten Kompetenzen liegt darin begründet, dass aktuell noch keine Aus-‐‑
trainieren kann, stellen sich folgende Fragen: sagen über feinere sinnvolle Differenzierungen
• Was meint überhaupt "ʺKompetenz"ʺ? getroffen werden können. Das Interesse liegt zu-‐‑
• Wozu dient eine Kompetenzbeschreibung? nächst auf einer klaren Strukturierung von For-‐‑
• Wie beschreibt man Kompetenzen sinnvoll? schungsdaten. Erst später ist möglicherweise eine
• Was genau kennzeichnet einen guten Software weitere Differenzierung sinnvoll und notwendig.
Ingenieur? Welche Kompetenzen soll ein Soft-‐‑
ware Ingenieur haben? 4. Wozu sollten Kompetenzen be-
schrieben werden?
3. Was ist "Kompetenz"?
Die erforderlichen fachlichen und überfachlichen
Der Kompetenzbegriff ist relativ unscharf. Es gibt Kompetenzen im Software Engineering sollen er-‐‑
zahlreiche Definitionen, was unter Kompetenzen hoben, analysiert und beschrieben werden, um
verstanden werden kann. darauf aufbauend Lehrziele, didaktische Methoden
Erpenbeck (2007) schlägt eine Einteilung in per-‐‑ und kompetenzorientierte Prüfungen (weiter) zu
sonale, aktivitäts-‐‑ und umsetzungsorientierte, fach-‐‑ entwickeln. Die erhobenen Kompetenzen werden
lich-‐‑methodische sowie sozial-‐‑kommunikative in einem Kompetenzprofil zusammengefasst und
Kompetenz vor. Die Definition nach Erpenbeck stellen so ein umfassendes Bild dar, was ein Soft-‐‑
ermöglicht jedoch keine eindeutige Zuordnung ware Ingenieur unmittelbar nach der Hochschul-‐‑
einzelner Kompetenzen zu einer dieser Arten. ausbildung kennen und können soll. Kompetenz-‐‑
Spricht man allgemein von einer Kompetenz, profile sollen sowohl für den Bereich der Kernin-‐‑
um z.B. eine bestimmte Problemstellung lösen zu formatik als auch für Software Engineering im Ne-‐‑
können, treten verschiedene Kompetenzarten in benfach wie etwa Mechatronik erfasst werden.
Kombination auf. Um etwa Anforderungen erfas-‐‑ Darauf aufbauend soll erforscht werden, welche
sen zu können, bedarf es sowohl fachlich-‐‑metho-‐‑ Einflussfaktoren die Kompetenzförderung im
discher (z.B. Anforderungen korrekt beschreiben) Software Engineering begünstigen, so dass in der
als auch sozial-‐‑kommunikativer Kompetenzen (z.B. Hochschulausbildung gezielt kompetenzfördernde
Kommunikationsfähigkeit, Teamfähigkeit). Auch Rahmenbedingungen geschaffen werden können.
Erpenbeck (2007, S. XII) kommt zu dem Schluss, Die Kompetenzbeschreibung ist somit eine we-‐‑
dass Kompetenzen mehr sind als reines Wissen sentliche Grundlage für die weitere empirisch-‐‑
oder Fertigkeiten: "ʺKompetenzen schließen Fertig-‐‑ experimentelle Didaktikforschung. Kompetenzbe-‐‑
keiten, Wissen und Qualifikationen ein, lassen sich schreibungen werden benötigt, um die Ziele der
aber nicht darauf reduzieren."ʺ akademischen Ausbildung klar beschreiben zu
Weinert (2001, S. 27f) gibt eine allgemeinere De-‐‑ können und eine Vergleichsmöglichkeit zu schaf-‐‑
finition: "ʺKompetenzen sind die bei Individuen fen, inwieweit diese Ziele dann tatsächlich erreicht
verfügbaren oder von ihnen erlernbaren kognitiven wurden. Dazu ist eine systematische, vergleichbare
Fähigkeiten und Fertigkeiten, bestimmte Probleme Beschreibung von Kompetenzen notwendig. Kom-‐‑
zu lösen, sowie die damit verbundenen motivatio-‐‑ petenzbeschreibungen bilden diese Vergleichs-‐‑
nalen (das Motiv betreffend), volitionalen (durch grundlage, um später in Experimenten zu evaluie-‐‑
den Willen bestimmt) und sozialen Bereitschaften ren, wie sich die Soll-‐‑ von den Ist-‐‑Kompetenzen
und Fähigkeiten, die Problemlösungen in variablen Studierender unterscheiden und ob die gezielte
Situationen erfolgreich und verantwortungsvoll Veränderung einzelner Einflussvariablen auf den
nutzen zu können."ʺ Angelehnt an Weinert unter-‐‑ Lernprozess die Kompetenzentwicklung begünstigt
scheiden wir im vorliegenden Artikel zwei Kompe-‐‑ hat. Die Beschreibung von Kompetenzprofilen stellt
tenzarten: in diesem Zusammenhang eine Datenbasis zu ver-‐‑
• Fachkompetenzen entsprechen den kognitiven schiedenen Zeitpunkten sowie verschiedener Ko-‐‑
Fähigkeiten und Fertigkeiten. horten und Studiengänge dar, die dann miteinan-‐‑
• Überfachliche Kompetenzen beinhalten die der abgeglichen werden können.
motivationalen, volitionalen und sozialen Be-‐‑ Fachliche und überfachliche Kompetenzen un-‐‑
reitschaften und Fähigkeiten. terscheiden sich in ihrer Art, Beschreibung, Förde-‐‑
118 A. Spillner, H. Lichter (Hrsg.): SEUH 13
rung und auch Messung stark und werden daher erklärende Hypothese, die versucht, von einer Fol-‐‑
zunächst separat betrachtet. Überfachliche Kompe-‐‑ ge auf Vorhergehendes zu schließen (Abduktion).
tenzen sind sehr schwer zu fassen, zudem kaum Dann wird ein Typisierungsschema für Hypothe-‐‑
eindeutig definierbar und messbar. sen entwickelt (Deduktion), das mit Forschungsda-‐‑
Fachliche Kompetenzen werden mit einem ge-‐‑ ten abgeglichen wird (Induktion) (Flick et al. 2000).
eigneten Beschreibungsschema erfasst, analysiert Grounded Theory besitzt unter anderem fol-‐‑
und beschrieben. Eine Grundlage dafür bildet gende wesentliche Merkmale:
SWEBOK (Abran et al. 2004), das die fachlichen • Eine Theorie wird aus Daten generiert, statt
Kompetenzen eines Software Ingenieurs mit vier "ʺnur"ʺ verifiziert. Der Fokus liegt auf der Entde-‐‑
Jahren Berufserfahrung beschreibt. Für überfachli-‐‑ ckung und Einbeziehung neuer Erkenntnisse,
che Kompetenzen im Software Engineering soll in nicht auf der Verifizierung, denn das würde
EVELIN ein Schema zur Beschreibung entwickelt neu auftauchende Perspektiven unterdrücken.
und mit konkreten Daten gefüllt werden. Das Er-‐‑ Folglich kann eine Theorie nie "ʺfertig"ʺ sein, da
gebnis entspräche dem SWEBOK auf fachlicher jederzeit neue Aspekte auftauchen können.
Seite. Die erforderlichen überfachlichen Soll-‐‑Kom-‐‑ • Ziel ist es, durch das Vergleichen von Gruppen
petenzen werden völlig offen und unvoreinge-‐‑ zum einen Kategorien zu bilden und zum an-‐‑
nommen ermittelt, um ein möglichst umfassendes deren bestehende Beziehungen zwischen die-‐‑
Bild zu bekommen. Es geht auch darum zu verste-‐‑ sen Kategorien an den Tag zu bringen. Nach
hen, was z.B. "ʺkommunikative Kompetenz"ʺ im Glaser et al. (1998, S. 48f.) "ʺ... muss unterstri-‐‑
Kontext von Software Engineering bedeutet. chen werden, dass die Hypothesen zunächst
Die systematische Erfassung der Soll-‐‑Kompe-‐‑ einen vorläufigen Status haben: Sie beschreiben
tenzen ist Voraussetzung dafür, Lernprozesse bes-‐‑ mutmaßliche, nicht getestete Zusammenhänge
ser analysieren und verstehen zu können. Zentrale zwischen den Kategorien und ihren Eigenschaf-‐‑
Fragen sind dann: Welche Faktoren wirken über-‐‑ ten -‐‑ was natürlich nicht heißt, dass man die
haupt auf das Lernen? Und wie können diese Ein-‐‑ Hypothesen nicht so gut wie möglich verifizie-‐‑
flussfaktoren systematisch erfasst werden, so dass ren sollte. [...] Hypothesen zu generieren heißt,
dann zielgerichtet diejenigen angepasst und verän-‐‑ sie im empirischen Material zu verankern -‐‑
dert werden können, die Lernprozesse unterstützen nicht, genug Material anzuhäufen, um einen
und so die Soll-‐‑Kompetenzen gezielt fördern? Hin-‐‑ Beweis führen zu können."ʺ
zu kommt die Schwierigkeit, dass Wechselwirkun-‐‑ • Grounded Theory fordert eine parallele Daten-‐‑
gen zwischen den Einflussfaktoren bestehen: die erhebung und -‐‑analyse, und zwar vom Beginn
Änderung einzelner Faktoren hat immer Auswir-‐‑ der Forschung an bis zur ihrem Ende.
kungen auf andere. Es gilt, diese Einflussfaktoren • Theoretisches Sampling meint, dass die Stich-‐‑
auf Lernprozesse im Software Engineering und ihre probe sich während des gesamten Forschungs-‐‑
Wechselwirkungen untereinander mittels Groun-‐‑ prozesses weiter entwickelt, so dass bis zum
ded Theory besser zu verstehen, zumal es speziell Ende keine endgültigen Aussagen über die er-‐‑
für den Bereich Software Engineering noch keine hobenen und einbezogenen Daten getroffen
etablierte Theorie gibt. werden können. Die entstehende Theorie steu-‐‑
ert, wann im Forschungsprozess welche Daten
5. Grounded Theory als For- wo erhoben werden.
schungsstrategie • Grundsätzlich gilt ein Mix qualitativer und
quantitativer Forschungsmethoden als zielfüh-‐‑
Den methodischen Rahmen für das gesamte Vor-‐‑ rend.
haben bildet die Forschungsstrategie Grounded
Daraus resultiert permanente Offenheit für neue
Theory (Glaser et al. 1998), die häufig verwendet
Aspekte, die jederzeit in den Forschungsprozess
wird, wenn eine auf Daten gestützte Theorie zu
aufgenommen werden.
einem Thema entwickelt werden soll. Sie zielt da-‐‑
rauf ab, Sachverhalte besser zu verstehen und wird
in diesem Forschungsprojekt angewandt, um Pro-‐‑ 6. Methodisches Vorgehen
zesse umfassend zu verstehen, die dem Lernen von Das Vorgehen der Grounded Theory korrespon-‐‑
Software Engineering zugrunde liegen. Dieses Ver-‐‑ diert gut mit dem Anspruch einer angewandten
ständnis ist Voraussetzung für die kompetenzför-‐‑ Forschung, da hier sowohl die Forschungsmetho-‐‑
dernde Gestaltung der Lernprozesse. dik als auch die Anwendungsorientierung von zu
Den Ausgangspunkt der Grounded Theory bil-‐‑ erhebenden Daten ausgehen und diese strukturie-‐‑
den nicht theoretische Vorannahmen. Vielmehr ren. Zudem soll kein vorgefertigtes Bild verifiziert
handelt es sich um einen zirkulären Analysepro-‐‑ werden, das es für das Lernen von Software Engi-‐‑
zess, der zugleich induktive und deduktive Vorge-‐‑ neering ohnehin noch nicht gibt. Ein solches Mo-‐‑
henselemente beinhaltet. Ausgangspunkt ist eine dell könnte nur auf theoretischer Basis entwickelt
A. Spillner, H. Lichter (Hrsg.): SEUH 13 119
werden, hätte dann aber wenig Bezug zur Anwen-‐‑ flussvariablen und den Messwerten der Soll-‐‑ und
dungsrealität. Ist-‐‑Kompetenzen zu verschiedenen Zeitpunkten
Software Engineering ist gekennzeichnet durch werden so Rückschlüsse auf mögliche lernfördern-‐‑
ein sehr komplexes Praxisfeld sowie eine Vielzahl de Einflussfaktoren gezogen, die dann gezielt mo-‐‑
zu trainierender Kompetenzen, die zudem von der difiziert werden.
jeweiligen Rolle abhängen, die ein Software Ingeni-‐‑ Somit gliedert sich das Vorgehen in zwei we-‐‑
eur einnimmt. Damit ist der Wissenstransfer von sentliche Schritte: Das Strukturieren und gezielte
der Theorie auf die praktische Anwendung im Verändern von Einflussvariablen auf den Lernpro-‐‑
Software Engineering eine besondere Herausforde-‐‑ zess und die Kompetenzanalysen zu verschiedenen
rung. Lernen von Software Engineering muss also Zeitpunkten.
auf den sehr komplexen Anwendungskontext aus-‐‑ Sedelmaier und Landes (2012) beschreiben das
gerichtet sein und wird von zahlreichen Faktoren Forschungsdesign genauer (vgl. Abb. 4).
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.
6.1 Überblick über das konkrete Vorgehen
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 Abb. 4: Überblick über das Forschungsdesign
überprüft. Konkret bedeutet dies, dass zunächst
sowohl die Soll-‐‑Kompetenzen als auch die Ist-‐‑Kom-‐‑ 6.2 Erfassen von Einflussvariablen
petenzen Studierender erhoben werden. Um die Einflussfaktoren auf Lehr-‐‑Lern-‐‑Prozesse
Dann werden gezielt Einflussvariablen auf den systematisch erfassen zu können, wurden diese
Lernprozess modifiziert und die studentischen Ist-‐‑ zunächst in Struktur-‐‑, Prozess-‐‑ und Ergebnisvariab-‐‑
Kompetenzen zu einem späteren Zeitpunkt erneut len (Donabedian 1980) unterteilt. Ergebnisvariablen
erhoben. Zuvor definierte Messkriterien zeigen, ob werden mittels der Kompetenzprofile beschrieben.
und in welchem Maß sich die Kompetenzen verän-‐‑ Strukturvariablen setzen sich aus den didaktischen
dert haben, und lassen Rückschlüsse auf die verän-‐‑ Aspekten zusammen, die strukturelle Rahmenbe-‐‑
derten Einflussvariablen zu. Diese Messkriterien dingungen auf den Lernprozess darstellen, wie z.B.
werden über konkrete, auf die Rahmenbedingun-‐‑ Motivationen, Einstellungen, didaktische Kenntnis-‐‑
gen angepasste Lehrziele aus den Soll-‐‑Kompeten-‐‑ se der Lehrenden, Räumlichkeiten. Prozessvariab-‐‑
zen abgeleitet. len beeinflussen den tatsächlichen Lernprozess, wie
Dieser Prozess wird mehrfach durchlaufen, um etwa Medien, Lehr-‐‑ und Lernmethoden.
ein besseres Verständnis über die Einflussfaktoren
auf das Lernen von Software Engineering zu erhal-‐‑ 6.3 Kompetenzanalyse
ten und um so den Lernprozess möglichst kompe-‐‑ Um Kompetenzen zu verschiedenen Zeitpunkten
tenzfördernd gestalten zu können. erfassen und dokumentieren und Vergleiche anstel-‐‑
Ausgehend von ersten Hypothesen und Daten len zu können, ist ein einheitliches Beschreibungs-‐‑
sollen gezielte Veränderungen und Modifikationen schema erforderlich.
an den Lehr-‐‑Lern-‐‑Prozessen vorgenommen und Während zu fachlichen Kompetenzen zahlrei-‐‑
dokumentiert werden, so dass Schritt für Schritt che Vorarbeiten zu finden sind, existieren für über-‐‑
bestehende Lehrveranstaltungen weiterentwickelt fachliche Kompetenzen nur sehr allgemeingültige
werden können. Dabei werden -‐‑ wie bereits be-‐‑ Einteilungen (vgl. Kap. 3). Daher werden fachliche
schrieben -‐‑ Messkriterien festgelegt, anhand derer und überfachliche Kompetenzen separat betrachtet,
Kompetenzentwicklung zu verschiedenen Zeit-‐‑ wodurch sich auch das Vorgehen unterscheidet.
punkten ablesbar und vergleichbar sein soll. Diese
Daten werden dann zu verschiedenen Zeitpunkten
erhoben. Aus dem Vergleich der veränderten Ein-‐‑
120 A. Spillner, H. Lichter (Hrsg.): SEUH 13
Vorgehen bei überfachlichen Kompetenzen jegliche überfachliche Aussagen codiert. Es ent-‐‑
SWEBOK strukturiert fachliche Inhalte des Soft-‐‑ standen 32 Codes, die unterschiedlich häufig auf-‐‑
ware Engineering und bietet somit einen Anhalts-‐‑ traten. Diese Codes deuten auf ein Schema zur
punkt, welche fachlichen Kompetenzen im Soft-‐‑ Beschreibung überfachlicher Kompetenzen hin,
ware Engineering relevant sein können. sind jedoch noch weiter zu clustern und zu struktu-‐‑
Allerdings vernachlässigt SWEBOK überfachli-‐‑ rieren. Gemäß Grounded Theory geschieht dies
che Kompetenzen völlig. Zudem ist keine mit parallel mit der Erhebung und Auswertung weite-‐‑
SWEBOK vergleichbare "ʺLandkarte"ʺ für überfachli-‐‑ rer Daten. In diesem iterativen Prozess entsteht
che Kompetenzen im Software Engineering be-‐‑ somit neben dem Beschreibungsschema für über-‐‑
kannt. Auch ist noch unklar, wie trennscharf sich fachliche Kompetenzen zeitgleich auch die inhaltli-‐‑
überfachliche Kompetenzen unterscheiden lassen. che Beschreibung überfachlicher Kompetenzen, die
Lässt sich eine Kompetenz eindeutig beispielsweise ein Software Ingenieur benötigt.
den motivationalen oder volitionalen Kompetenzen Vorgehen bei fachlichen Kompetenzen
zuordnen? Diese Frage ist erst nach Erhebung ers-‐‑ Aufgrund anderer Voraussetzungen und Vor-‐‑
ter konkreter überfachlicher Kompetenzen zu be-‐‑ kenntnisse wurde bei fachlichen Kompetenzen
antworten. zuerst top-‐‑down ein theoretisches Modell entwi-‐‑
Da im Bereich überfachlicher Kompetenzen für ckelt und in einem zweiten Schritt mit konkreten
Software Engineering also noch keinerlei Vorerhe-‐‑ Daten, also Kompetenzen, gefüllt und validiert.
bungen oder vorstrukturierende Daten vorhanden Das vorgeschlagene Modell zur Beschreibung fach-‐‑
sind, sind somit die zu erwartenden Inhalte unklar. licher Kompetenzen wurde so in einer Pilotstudie
Daher bietet sich ein iteratives Forschungsdesign auf seine Verwendbarkeit überprüft. Dazu wurden
an, das bottom-‐‑up mit völlig offenem Blick über-‐‑ mittels halbstrukturierter Interviews fachliche Soll-‐‑
fachliche Kompetenzen erfasst und dann erst struk-‐‑ Kompetenzen erhoben und klassifiziert, die Unter-‐‑
turiert. Es wurde ohne ein vorhandenes Schema nehmen von Absolventen im Bereich Kern-‐‑Infor-‐‑
zur Beschreibung der Kompetenzen begonnen. matik erwarten.
Dieses entsteht erst parallel mit der Datenerhe-‐‑ Als Grundlage für mögliche Inhalte und somit
bung. Die Entwicklung eines Beschreibungsmo-‐‑ für den Interviewleitfaden wurde u.a. SWEBOK
dells für überfachliche Kompetenzen ist einer ers-‐‑ herangezogen. Um auch angrenzende Themen-‐‑
ten Datensammlung nachgelagert. komplexe wie beispielsweise Programmiertechni-‐‑
Überfachliche Soll-‐‑Kompetenzen werden aus ken und Datenbanken einfließen zu lassen, wurden
Sicht unterschiedlicher Stakeholder und zunächst auch entsprechende fachliche Inhalte vorhandener
in einem ersten Schritt aus Sicht von Unternehmen Lehrveranstaltungen berücksichtigt.
für den Bereich Kerninformatik ermittelt. Dazu Es wurden Gespräche mit sieben Vertreten von
wurden Interviews, die zu den fachlichen Kompe-‐‑ Wirtschaftsunternehmen verschiedener Branchen
tenzen geführt wurden (siehe unten), nochmals im (vgl. Tabelle 1) im Bereich Software Engineering
Hinblick auf überfachliche Kompetenzen ausge-‐‑ geführt, aufgezeichnet, transkribiert und ausgewer-‐‑
wertet. Durch die Nähe zur Datenbasis der Inter-‐‑ tet. Befragt wurden einerseits Personen mit Ent-‐‑
views entsteht in diesem bottom-‐‑up-‐‑Prozess ein scheidungskompetenz bei der Auswahl neuer Mit-‐‑
Verständnis für die überfachlichen Kompetenzen arbeiter und Nähe zu den fachlichen Inhalten, also
und ihre Ausprägung. Dieses Vorgehen ermöglicht z.B. Geschäftsführer oder Gruppen-‐‑/Abteilungs-‐‑
einen unverstellten Blick auf die tatsächlichen Er-‐‑ leiter, andererseits Absolventen der eigenen Hoch-‐‑
fordernisse im Berufsleben und erzeugt schon wäh-‐‑ schule mit inzwischen mehrjähriger Berufserfah-‐‑
rend des Forschungsprozesses ein Gefühl dafür, rung.
was etwa mit "ʺTeamfähigkeit"ʺ gemeint ist. Sonst
häufig wenig aussagekräftige Worthülsen wie z.B.
Nr Branche Entschei-‐‑ ehem.
Teamfähigkeit erfahren durch dieses bottom-‐‑up-‐‑
der Absol-‐‑
Vorgehen eine Konkretisierung für den Bereich
vent(in)
Software Engineering. Dies ist auch der Grund,
warum es in einem ersten Schritt nicht sinnvoll ist, 1 Marketing, Software-‐‑ X
Stakeholder direkt danach zu fragen, welche über-‐‑ entwicklung kein
fachlichen Kompetenzen benötigt werden. Als Kerngeschäft
Antwort wäre primär eine Aufzählung dieser 2 Softwareentwicklung X X
Worthülsen zu erwarten, es bliebe jedoch offen, für Banken und Versi-‐‑
was genau im Kontext von Software Engineering cherungen
darunter zu verstehen ist.
Als erster Schritt zu einem Beschreibungssche-‐‑ 3 Bildbearbeitung (Me-‐‑ X
ma für überfachliche Kompetenzen wurden die dizin), Embedded,
vorhandenen Interviews zunächst im Hinblick auf Datenbanklösungen
A. Spillner, H. Lichter (Hrsg.): SEUH 13 121
4 Automobilzulieferer X und deren Vergleich ermöglichen. Da dieses Be-‐‑
(Embedded) schreibungsmodell ein Werkzeug für Planung,
Messung und Analyse sein soll, muss es möglichst
einfach, aber dennoch ausreichend ausdruckskräf-‐‑
5 Softwareentwicklung X
tig, verständlich und handhabbar sein.
und Betrieb einer
Wichtig ist auch die Kompatibilität mit anderen
Marketingplattform
Denkansätzen und Beschreibungsmodellen wie z.B.
6 Softwareentwicklung X der Taxonomie von Lernzielen im kognitiven Be-‐‑
und Betrieb einer reich nach Bloom (1972). Es sollte -‐‑ wenn nötig -‐‑ zu
Marketingplattform späteren Zeitpunkten noch erweiterbar sein.
7 Großkonzern, Abtei-‐‑ X Auch sollte eine Hierarchie aufeinander auf-‐‑
lung mit Schwerpunkt bauender Kompetenzen zwar abbildbar, jedoch
Softwareentwicklung nicht zwingend sein.
Klassifikationsschemata für Lernaufgaben und
Taxonomien für Software Engineering-‐‑Inhalte
Tabelle 1: Zusammensetzung der Stichprobe wurden mit diesen Anforderungen abgeglichen.
Zwar gewährleistet diese Auswahl noch keine re-‐‑
präsentative Stichprobe, aber immerhin eine relativ 7.3 Taxonomien für fachliche Kompetenzen
gute Abdeckung des fachlichen Spektrums und Die Taxonomie kognitiver Lernziele von Bloom
unterschiedliche Perspektiven. Folgt man der (1972) ist eines der bedeutendsten Klassifizierungs-‐‑
Grounded Theory, genügt dies, um erste Annah-‐‑ systeme in diesem Bereich. Bloom unterteilt Lern-‐‑
men und Hypothesen zu bilden, die dann den ziele in die Hauptklassen Wissen, Verstehen, An-‐‑
Ausgangspunkt für die weitere Forschung bilden, wendung, Analyse, Synthese und Bewertung. Diese
jedoch noch nicht den Anspruch haben, eine bereits sechs Klassen gliedern sich teilweise wiederum in
vorhandene These zu validieren. Unterklassen. Insgesamt ergeben sich daraus 24
Klassifikationsmöglichkeiten, was die Einordnung
7. Wie kann man Kompetenzen von Kompetenzen erheblich erschwert. Für EVE-‐‑
sinnvoll beschreiben? LIN soll jedoch ein Klassifikationsschema eine
schnelle und einfache Zuordnung ermöglichen.
Zunächst sind Kompetenzen mittels eines geeigne-‐‑ Trotz der komplexen Unterstruktur ist es schwie-‐‑
ten Modells zu analysieren und beschreiben. Dazu rig, Kompetenzen verschiedener Bereiche des
wurden existierende Klassifikationsschemata auf Software Engineering wie etwa Kerninformatik,
ihre Eignung im EVELIN-‐‑Kontext überprüft. Mechatronik oder Wirtschaftsinformatik mit die-‐‑
sem Modell zu unterscheiden. Die Untersuchungen
7.1 Generelle Anforderungen an ein Be-
zeigten u.a., dass die Klassifizierung auf der Ebene
schreibungsmodell
der Kompetenzen oftmals widersprüchlich ist. Ei-‐‑
Die Untersuchung vorhandener Schemata ergab ein nerseits ist dies auf die strikte kumulative Hierar-‐‑
klares Bild der Anforderungen an ein geeignetes chie der Klassen zurückzuführen, anderseits sind
Beschreibungsmodell im EVELIN-‐‑Kontext. Ein die Anordnung und Bedeutung der höheren Klas-‐‑
Kompetenzprofil für Software Engineering ist keine sen für diesen Einsatzzweck fraglich (Claren 2012).
rein inhaltliche Sammlung von Stichworten, denn Da dieses Modell zur Klassifizierung von Lehrzie-‐‑
aufgrund der Anwendung in verschiedenen Fach-‐‑ len entwickelt wurde, eignet es sich nur bedingt für
disziplinen soll es auch ausdrücken können, wie die Beschreibung von Kompetenzen, da diese auf
gut Studierende die jeweilige Kompetenz beherr-‐‑ einer abstrakteren Ebene angesiedelt sind.
schen. Auch darf ein Kompetenzprofil nicht auf Anderson und Krathwohl (2001) veröffentlich-‐‑
Lehrzielebene formuliert sein, denn hier muss auf-‐‑ ten eine überarbeitete Fassung der Taxonomie nach
grund der verschiedenen Schwerpunkte einzelner Bloom. Gegenüber der Ursprungstaxonomie wur-‐‑
Studiengänge und der Vorstellungen und Priorisie-‐‑ den zunächst die Klassen in aktive Verben umbe-‐‑
rungen der Lehrenden eine gewisse Flexibilität nannt und die beiden letzten vertauscht, da dies
vorhanden sein. Gleichzeitig muss ein Beschrei-‐‑ nach Meinung der Autoren der steigenden Kom-‐‑
bungssystem auch die Beschreibung, Strukturie-‐‑ plexität der kognitiven Prozesse besser entspricht.
rung und Einordnung von Lehrzielen unterstützen, Die wesentliche Änderung ist jedoch die Einfüh-‐‑
so dass es als "ʺKompass"ʺ für die Lehr-‐‑Lern-‐‑Planung rung einer zweiten Dimension, welche die Art des
anwendbar ist. Die Lehrziele leiten sich aus dem Wissens repräsentiert. Damit ergibt sich das in Ab-‐‑
entsprechenden Kompetenzmodell ab. bildung 1 gezeigte zweidimensionale Schema, das
Das Modell soll die Beschreibung von Soll-‐‑ und zwischen einer kognitiven und einer Wissensdi-‐‑
Ist-‐‑Kompetenzen zu verschiedenen Zeitpunkten mension unterscheidet.
122 A. Spillner, H. Lichter (Hrsg.): SEUH 13
(siehe Abbildung 2) vor, die auf der Taxonomie
von Anderson basiert.
Abb. 1: Lernzieltaxonomie nach Anderson und
Krathwohl (2001)
Eine weitere Änderung ist der Verzicht auf die
Abb. 2: Matrix-‐‑Taxonomie (Fuller et al. 2007)
kumulativen Eigenschaften der Klassen.
Bei der Anwendung dieser Taxonomie zeigen Die Dimension INTERPRETING umfasst alle Aus-‐‑
sich jedoch grundlegende Probleme. Lehrziele bzw. prägungen einer Kompetenz, die sich auf Interpre-‐‑
Kompetenzen müssen in diesem Schema immer tieren und Verstehen beziehen. Die PRODUCING-‐‑
sowohl einer Wissenskategorie als auch einer Kate-‐‑ Ebene dagegen repräsentiert die Fähigkeiten, die
gorie in der kognitiven Dimension zugeordnet nötig sind, um neue Produkte zu entwerfen und
werden. Dabei soll die Formulierung der Lehrziele entwickeln. Dadurch lassen sich die theoretischen
einen Hinweis für die Einordnung in das Schema (INTERPRETING) und praktischen (PRODUCING)
geben, was auch die eigentliche Intension des Mo-‐‑ Aspekte einer Kompetenz beschreiben.
dells erkennen lässt: Es soll in erster Linie ein Pla-‐‑ Zunächst wird ein Zielfeld für eine Kompetenz
nungs-‐‑ und Kontrollwerkzeug für den Unterricht festgelegt, das Studierende über verschiedene Pfa-‐‑
sein und geht davon aus, dass bereits formulierte de erreichen können. Dabei bewegt sich der Lern-‐‑
Lehrziele existieren (Anderson und Krathwohl prozess vom Startpunkt aus sequenziell entlang der
2001). Im Rahmen von EVELIN sollen Soll-‐‑Kompe-‐‑ Ebenen zum nächsthöheren Level. Im Lernprozess
tenzprofile für Software Engineering entstehen, aus kann kein Feld übersprungen werden und es ist
denen erst später Lehrziele abgeleitet werden. Ge-‐‑ immer nur eine Bewegung von links nach rechts
nerell erhöht die Aufteilung in ein zweidimensio-‐‑ bzw. von unten nach oben möglich. Im Normalfall
nales Schema die Komplexität, da sich für jede zu beginnt der Lernprozess dabei in REMEBER |
beschreibende Kompetenz 24 Klassifizierungsmög-‐‑ NONE (-‐‑).
lichkeiten ergeben. Zu diesem Schluss kommen Hier wird deutlich, dass eine andere Zielset-‐‑
auch Fuller et al. (2007). Aufgrund der Tatsache, zung als die unseres Projektes vorliegt. Bei Fuller et
dass höhere Klassen in diesem Modell die darun-‐‑ al. liegt der Fokus auf der Beschreibung, Beobach-‐‑
terliegenden Klassen nicht subsumieren, erlaubt tung und Planung von Lernpfaden einzelner Stu-‐‑
das Modell die Überlappung von Klassen. Ein dierender oder homogener Studierendengruppen.
Lehrziel kann also gleichzeitig in zwei benachbarte Während Fuller et al. Prozesse analysieren, beab-‐‑
Klassen eingeordnet werden. Dadurch fehlt es dem sichtigt EVELIN, zunächst "ʺZustände"ʺ zu beschrei-‐‑
Modell in beiden Dimensionen an der nötigen ben.
Trennschärfe, um eine möglichst eindeutige und
7.4 Das EVELIN-Modell zur Beschreibung
zielführende Klassifizierung durchzuführen (Cla-‐‑
von fachlichen Kompetenzen
ren 2012, Granzer et al. 2008).
Fuller et al. (2007) untersuchten verschiedene Keines der analysierten Modelle eignet sich unein-‐‑
Taxonomien zur Beschreibung von Kompetenzen geschränkt für eine Kompetenzbeschreibung im
im Bereich der Informatik, darunter auch die Taxo-‐‑ Rahmen von EVELIN. Für fachliche Kompetenzen
nomien nach Bloom sowie nach Anderson und wurde daher ein eigenes Modell entwickelt, das
Krathwohl. Ihre Erkenntnisse decken sich weitge-‐‑ bewusst wesentliche Elemente bestehender Taxo-‐‑
hend mit denen der Untersuchung im Rahmen von nomien aufgreift, um sie im Hinblick auf die bereits
EVELIN. Darunter fällt etwa die problematische genannten Anforderungen sinnvoll zu kombinieren
Einordnung in höhere Klassen, die Fragwürdigkeit und zu erweitern.
der hierarchischen Ordnung bei Bloom sowie die Das EVELIN-‐‑Modell (vgl. Abbildung 3) besteht
zu hohe Komplexität des zweidimensionalen Mo-‐‑ aus den Klassen Erinnern, Verstehen, Erklären,
dells von Anderson (Fuller et al. 2007). Die Auto-‐‑ Verwenden, Anwenden und (Weiter-‐‑)Entwickeln,
ren schlagen die sogenannte Matrix-‐‑Taxonomie die sich wie folgt charakterisieren lassen:
A. Spillner, H. Lichter (Hrsg.): SEUH 13 123
8. Welche fachlichen Kompetenzen
benötigt ein Software Ingenieur?
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
Abb. 3: EVELIN-‐‑Modell zur Beschreibung fachli-‐‑ eindeutigen Ausprägungen verdichtet werden,
sondern zeigen Tendenzen auf. Dazu trägt auch
cher Kompetenzen
bei, dass Unternehmen wegen unterschiedlicher
Erinnern Tätigkeitsschwerpunkte unterschiedliche Vorstel-‐‑
• sich an Informationen erinnern und sie wortge-‐‑ lungen von Software Engineering haben. Die Ent-‐‑
nau wiedergeben können wicklung von Software für Banken und Versiche-‐‑
Verstehen rungen hat etwa auch Auswirkungen auf die er-‐‑
• den Sinn / die Bedeutung von Informationen warteten Kompetenzen im Bereich Softwaretest.
verstehen Nachfolgend werden wesentliche Ergebnisse der
• definieren können Untersuchung dargestellt, eine detaillierte Diskus-‐‑
• implizites Wissen sion findet sich in Claren (2012).
• thematisch zugehörige, aber neue Informatio-‐‑ 8.1 Vorgehensmodelle
nen zuordnen können
Bei Vorgehensmodellen gibt es eine Tendenz hin zu
Erklären
umfangreichen theoretischen Kompetenzen. So
• Zusammenhänge, Abhängigkeiten und Ähn-‐‑
erwarten die Befragten sowohl bei agilen als auch
lichkeiten zwischen Informationen erkennen
bei plan-‐‑getriebenen Modellen eher Kompetenzen,
und in eigenen Worten erklären können
die sich mit "ʺErklären"ʺ klassifizieren lassen. Eine
• Ursache-‐‑Wirkungs-‐‑Zusammenhänge theore-‐‑
gute theoretische Basis ist hier wichtig, da die Vor-‐‑
tisch benennen können
gehensmodelle meist unternehmensspezifisch an-‐‑
• Informationen strukturieren können
gepasst sind und dafür bei Neueinsteigern eine
• Vor-‐‑ und Nachteile erkennen, bewerten und
Einarbeitung erforderlich ist. Lediglich bei testge-‐‑
theoretisch analysieren
triebener Entwicklung ist die Ausprägung "ʺAn-‐‑
• Verorten von Informationen in Systemen
wendung"ʺ stärker vertreten.
• sachliche Analyse
• begründen 8.2 Requirements Engineering
Verwenden Beim Thema Requirements Engineering erwarten
• Anwenden in definiertem / eingeschränktem die Befragten ein Verständnis dafür, welche Rollen
Kontext und / oder unter Anleitung Lasten-‐‑ bzw. Pflichtenhefte im Anforderungspro-‐‑
• Umsetzung in kleinen Schritten oder mittels zess einnehmen. Auch wenn die Mehrheit der Be-‐‑
einer Schablone fragten keine spezielle Technik zur Formulierung
• "ʺKochen nach Rezept"ʺ von Anforderungen nutzt, erwartet sie dennoch
• Verstehen muss keine Rolle spielen grundlegendes Verständnis dafür, wie sich gute
Anwenden von schlechten Anforderungen unterscheiden. Ab-‐‑
• selbständiges, eigenverantwortliches Anwen-‐‑ solventen sollten Techniken zur Anforderungser-‐‑
den auch in "ʺschwierigem"ʺ Umfeld und / oder hebung sicher und gezielt anwenden können.
Lösungswege situationsgerecht auswählen und
umsetzen können 8.3 Modellierung
• Verstehen spielt eine Rolle Im Gebiet der Modellierung werden deutlich an-‐‑
(Weiter-‐‑)Entwickeln wendungsorientierte Kompetenzen erwartet. Ab-‐‑
• Nutzen von vorhandenem Wissen zur Entwick-‐‑ solventen sollten sowohl im Bereich der System-‐‑
lung oder Weiterentwicklung von Lösungen modellierung (z.B. mit der UML) als auch der Da-‐‑
• Schaffen von neuen Erkenntnissen, Forschung tenmodellierung (z.B. ER-‐‑Modelle) ausgeprägte
praktische Erfahrungen im Studium sammeln. Im
Dabei sind Erinnern, Verstehen und Erklären auf Gegensatz dazu spielt das Thema Prozessmodellie-‐‑
theoretischer Ebene angesiedelt, während Verwen-‐‑ rung bei den Befragten eine eher untergeordnete
den, Anwenden und Entwicklung mit praktischer Rolle.
Umsetzung verbunden sind.
124 A. Spillner, H. Lichter (Hrsg.): SEUH 13
8.4 Datenbanken 9. Welche überfachlichen Kompe-
Auch im Themenkomplex Datenbanken dominie-‐‑ tenzen benötigt ein Software In-
ren praktisch ausgerichtete Kompetenzen. Vor al-‐‑ genieur?
lem bei Datenbankentwurf und Datenabfrage er-‐‑
warten die meisten Befragten Kompetenzen auf Wie bereits erläutert kann derzeit noch kein exaktes
dem Niveau "ʺAnwenden"ʺ. Auch bei der Daten-‐‑ Schema angegeben werden, das beschreibt, in wel-‐‑
bankprogrammierung, wie z. B. dem Erstellen von cher Ausprägung welche überfachlichen Kompe-‐‑
Triggern und Funktionen, gibt es eine leichte Ten-‐‑ tenzen für Software Engineering konkret erforder-‐‑
denz in diese Richtung, wobei es manchen Inter-‐‑ lich sind. Es lässt sich jedoch ein erster Eindruck
viewten hier auch genügt, wenn Absolventen "ʺver-‐‑ vermitteln, welche Kompetenzen konkret für den
stehen"ʺ. Bereich Software Engineering benötigt werden und
was darunter zu verstehen ist. Derzeit handelt es
8.5 Design und Implementierung sich um die Sichtweise von Software Ingenieuren
Hier lassen sich bei zwei Kompetenzen Aussagen und Führungskräften. Es geht im Folgenden nicht
über die erwarteten Ausprägungen treffen. Bei der darum, die genannten Kompetenzen quantitativ
Beherrschung objektorientierter Programmiertech-‐‑ aufzuzählen, sondern vielmehr zu verstehen, was
niken sind sich die Befragten überwiegend einig, zentrale Anforderungen an einen Software Ingeni-‐‑
dass sich ein Absolvent auf Anwendungsniveau eur sind und was damit gemeint ist.
befinden sollte. Bei Design-‐‑Patterns werden keine Dazu wurden in den Interviews insgesamt 306
praktischen Kompetenzen erwartet. Berufseinstei-‐‑ Stellen codiert, die Rückschlüsse auf überfachliche
ger sollten nach Meinung der Befragten begreifen, Kompetenzen zulassen. Insgesamt wurden 32
was hinter diesem Begriff steckt, und die Prinzipien Codes vergeben, wobei sich über 70 % der codier-‐‑
grundlegender Entwurfsmuster verstehen. ten Stellen auf die 12 am häufigsten genannten
Codes verteilen (vgl. Tabelle 2).
8.6 Softwaretest
Bei Kompetenzen im Bereich Softwaretest sind die Code Anzahl Anteil Doku-‐‑
Meinungen sehr unterschiedlich. Lediglich bei Codings an allen ku-‐‑
"ʺUnittest"ʺ und "ʺTestfallentwurf"ʺ können die Mehr-‐‑ in % mente
zahl der Antworten mit "ʺAnwenden"ʺ klassifiziert Problembewusstsein 36 11,43 6
werden. Außerdem wird erwartet, dass Studienab-‐‑
solventen die grundlegenden Eigenschaften, Unter-‐‑ Verstehen komplexer 30 9,52 6
schiede und Zusammenhänge verschiedener Test-‐‑ Prozesse
metriken verstanden haben. Zusammenarbeit 28 8,89 7
8.7 Konfigurationsmanagement Kommunikation mit 18 5,71 5
anderen (auch inter-‐‑
Die Erwartungen im Bereich Konfigurationsma-‐‑
disziplinär)
nagement lassen sich auf rein theoretische Kompe-‐‑
tenzen reduzieren. Bei den Themen Change Ma-‐‑ Lernbereitschaft (Ge-‐‑ 18 5,71 5
nagement, Build Management / Continuous In-‐‑ genteil: Selbstüber-‐‑
tegration sowie Versionskontrollmechanismen schätzung)
können alle Antworten den theoretischen Klassen Problemlösungsfähig-‐‑ 16 5,08 4
"ʺErinnern"ʺ, "ʺVerstehen"ʺ und "ʺErklären"ʺ zugeordnet keit/ Kreativität
werden. Die Erwartungen bei Build Management
Selbst etwas erarbei-‐‑ 16 5,08 6
sind am geringsten, da sich Absolventen nur an
ten können
grundlegende Aspekte "ʺerinnern"ʺ sollen. Bei Chan-‐‑
ge Management oder Versionskontrolle variieren Empathie 15 4,76 6
die Antworten stark, jedoch jeweils mit leichter Offenheit für Neues 14 4,44 4
Tendenz zu "ʺErklären"ʺ.
Einfügen in Organisa-‐‑ 13 4,13 5
8.8 Projektmanagement tionsstrukturen
Projektmanagement ist überwiegend durch über-‐‑ Praktische Anwen-‐‑ 12 3,81 3
fachliche Kompetenzen geprägt (z.B. Kommunika-‐‑ dung
tions-‐‑ und Teamfähigkeit). Fachliche Kompetenzen Abstraktions-‐‑ 10 3,17 4
spielen zunächst kaum eine Rolle, da es eher unüb-‐‑ vermögen
lich ist, dass ein Absolvent sofort ein Projekt leitet.
Tabelle 2: Übersicht über die 12 häufigsten Codings
für überfachliche Kompetenzen
A. Spillner, H. Lichter (Hrsg.): SEUH 13 125
Unternehmen erwarten also fachlich gut ausgebil-‐‑ dium hinaus mit den Themen beschäftigt hat, dann
dete Absolventen, die in der Lage sind, komplexe ist es ganz oft auch der Fall, dass der eben – ja ver-‐‑
Prozesse in Unternehmen zu verstehen. Mitarbeiter schiedene Möglichkeiten schon abgeklopft hat und
im Bereich Software Engineering sollen ihre eigene dann auch – ja von sich aus verstehen kann, nach-‐‑
Fachlichkeit realistisch einschätzen. Sie sollen zwar vollziehen kann warum manche Sachen notwendig
in der Lage sein, sich mit ihrem Wissen im Unter-‐‑ sind."ʺ Auch ein dritter Befragter verlangt Ver-‐‑
nehmen zu verorten, jedoch auch die Bereitschaft ständnis dafür "ʺ...vor allem WARUM muss ich das
mitbringen, sich in Aufbau-‐‑ bzw. Ablauforganisati-‐‑ verwenden, welchen Nutzen ziehe ich denn dar-‐‑
onen einzufügen. Gleichzeitig wird eine gewisse aus, wenn ich das mache."
Aktivität und Selbständigkeit vorausgesetzt. Man Dabei geht es nicht ausschließlich um das Ver-‐‑
erwartet, keine genauen Vorgaben machen zu müs-‐‑ stehen und Einordnen von Fach-‐‑ und Faktenwis-‐‑
sen, wie und wann etwas zu tun ist. Vielmehr soll sen, sondern auch darum, die Tragweite und Zu-‐‑
ein Software Ingenieur sich innerhalb eines Korri-‐‑ sammenhänge komplexer Probleme bewusst wahr-‐‑
dors aktiv und eigenverantwortlich bewegen und zunehmen. Ein Interviewpartner fasst diese Aspek-‐‑
seine Kompetenzen selbständig einbringen und te so zusammen: "ʺWenn man dann ins alltägliche
auch weiterentwickeln. Ebenso notwendig ist die Berufsleben hinein geschmissen wird, hat man eher
Bereitschaft, sich ständig auf Neues und Unvorher-‐‑ das Problem, dass man von den ganzen… ja…
gesehenes einzulassen. Es wird erwartet, dass Ab-‐‑ Dingen, die da existierten, erst mal überwältigt ist."ʺ
solventen sich selbst und ihre Position im Unter-‐‑ Diese Zitate verdeutlichen, dass der Theorie-‐‑
nehmen realistisch einschätzen können und so im Praxis-‐‑Transfer von Kompetenzen und Wissen eine
Team und mit ihren Vorgesetzten konstruktiv zu-‐‑ zentrale Herausforderung darstellt, die offensicht-‐‑
sammenarbeiten und dabei ihren Platz und ihre lich für viele Absolventen nicht leicht zu meistern
Rolle finden. Dies ist eng verknüpft mit drei zentra-‐‑ ist und auch die Unternehmen vor einige Probleme
len Anforderungen, die am häufigsten in den Inter-‐‑ stellt. Umgekehrt ist es für die Hochschulausbil-‐‑
views genannt wurden: Problembewusstsein und dung schwierig, den komplexen Praxisalltag in der
das Verstehen komplexer Prozesse gepaart mit dem Ausbildung abzubilden, so dass die zitierten Aha-‐‑
Faktor Zusammenarbeit/ Kommunikation. Zu ei-‐‑ Erlebnisse für die Studierenden erfahrbar werden.
nem ähnlichen Ergebnis kommen auch Böttcher et Eine weitere wichtige überfachliche Kompe-‐‑
al. (2011). tenz, die von fast allen Befragten genannt wurde,
Als zentrale Anforderung wird von einem ist das Verstehen komplexer Prozesse. Für das Ein-‐‑
Software Ingenieur ein ausgeprägtes Problembe-‐‑ finden und angemessene Bewegen in diesen kom-‐‑
wusstsein erwartet. Problembewusstsein meint, plexen Abläufen, die dem Software Engineering
sich in einem komplexen Prozess zurechtzufinden inhärent sind, ist es absolut notwendig, dass ein
und zu erkennen, wann welche Kompetenzen wie Software Ingenieur diese überblickt und versteht.
benötigt werden, und wann und wie sie zusam-‐‑ Dies schließt auch "ʺeinen Weitblick über seinen
menhängen. Ein Interviewpartner beschreibt dies eigenen Tellerrand hinaus"ʺ mit ein. Ein Befragter
folgendermaßen: "ʺ... das ist auch so ein Thema, das beschreibt dies so: "ʺAber das Prinzip muss er be-‐‑
wurde auch in meinem Studium behandelt, das greifen: wie spielt das alles zusammen."ʺ
kann man aber auch erst sozusagen verstehen und Ein dritter, sehr wichtiger Komplex, auf den
adaptieren, wenn man das Problembewusstsein sich überfachliche Kompetenzen beziehen, ist der
hat, [...] weil man vielleicht schon das eine oder Bereich der Zusammenarbeit. Einer der Befragten
andere Problem wirklich erlebt hat, dass man sagt: bezeichnet das sehr treffend als "ʺTeamwork-‐‑
o.k., ich habe jetzt eine gewisse Problemstellung Alltag"ʺ. Ein anderer Befragter gibt hier einen Ein-‐‑
und die muss ich irgendwie lösen und dann eben blick in den Arbeitsablauf: "ʺDieser kommunikative
auch dieses Aha-‐‑Erlebnis gehabt hat [...]"ʺ Austausch über Themen nicht nur im Daily Scrum
Ein anderer Interviewpartner formuliert die Si-‐‑ mal ein paar Minuten, sondern eigentlich fachlich
tuation so: "ʺDas Problem ist ja, man hört im Studi-‐‑ und konkret den ganzen Tag über, im Pairing, in
um viele Sachen, die einem erzählt werden und – immer wiederkehrenden Beratungssituationen. Wir
da heißt es dann: o.k., das macht man so und das haben auch die Teams grundsätzlich immer zu-‐‑
macht man so – aber man weiß im Grunde ge-‐‑ sammensitzen in Räumen oder an Tischinseln von
nommen ganz oft nicht, warum macht man das Leuten, die im Team gemeinsam miteinander arbei-‐‑
denn eigentlich so. Weil es gibt eigentlich zehn ten. Dass also auch ein Austausch stattfindet, dass
Möglichkeiten, etwas zu machen. Im Studium wer-‐‑ sie nicht nur sich von einem Zimmer ins andere
den vielleicht zwei Möglichkeiten beleuchtet [...] eine E-‐‑Mail schreiben, sondern dass sie auch immer
und dann hat man zwar gehört: Okay, das und das diesen mündlichen Kommunikationsweg und dass
sollte man so machen, aber man weiß gar nicht, viele darüber sprechen -‐‑ das versuchen wir eigent-‐‑
warum man das so machen muss und wenn jetzt lich in jeder Weise zu befördern."ʺ Insgesamt scheint
jemand zu uns kommt, der sich eben über das Stu-‐‑ der Faktor Zusammenarbeit zunehmend an Bedeu-‐‑
126 A. Spillner, H. Lichter (Hrsg.): SEUH 13
tung zu gewinnen, allerdings verändert sich die Besonders für überfachliche Kompetenzen gilt
Arbeitsrealität in gleichem Maße. Ein Befragter es, ein Beschreibungsschema zu entwickeln, das
fasst es zusammen: "ʺTeamfähigkeit ist allerdings nahezu die gleichen Anforderungen erfüllt wie das
immer besser ausgeprägt heute, weil eben immer für fachliche Kompetenzen. Dieses Modell entsteht
mehr in der Ausbildung – Arbeiten im Team erle-‐‑ parallel zur Analyse der vorhandenen Interviewda-‐‑
digt werden oder erledigt werden müssen. Das hat ten mit Fokus auf überfachlichen Kompetenzen.
sich deutlich verbessert im Lauf der 25 oder 30 Dabei sollen überfachliche Kompetenzen sowohl
Jahre, die ich das jetzt betrachte. Am Anfang waren strukturiert als auch definiert werden. Es gilt, die
viele, viele, viele Einzelkämpfer da, das hat sich Frage zu beantworten, was im Kontext von Soft-‐‑
deutlich verbessert und das ist auch gut, die Ent-‐‑ ware Engineering etwa unter Team-‐‑ oder Kommu-‐‑
wicklung ist gut."ʺ Auf der anderen Seite erkennen nikationsfähigkeit verstanden wird. Eine weitere
die Befragten noch immer Handlungsbedarf: "ʺIch interessante Fragestellung ist, ob überhaupt und
sage mal so, die Leute haben scheinbar eine gewis-‐‑ ggf. welche Korrelationen zwischen fachlichen und
se technische Kompetenz, aber wie man eine ver-‐‑ überfachlichen Kompetenzen auftreten. Werden
nünftige Präsentation macht, wie man einen ver-‐‑ einzelne überfachliche Kompetenzen besonders
nünftigen Text schreibt, wie man in einem Team häufig im Zusammenhang mit einer oder mehreren
umgeht, wie man Konflikte löst, das sind alles bestimmten fachlichen Kompetenzen genannt? Für
Themen, die hat der gewöhnliche Hochschulab-‐‑ beide Schemata und ihren Inhalt gilt derselbe itera-‐‑
gänger nicht gelernt."ʺ Ein weiterer sieht darin einen tive Prozess, in dem die Daten auch während des
Ausweg für die Hochschulausbildung, "ʺ...dass man gesamten Forschungsprojektes EVELIN immer
Projekte definiert, wo wirklich mal drei, vier, fünf wieder überprüft und weiterentwickelt werden.
Leute dabei sind. Wo man sich untereinander ab-‐‑ Gemäß Grounded Theory fließen ständig neue
stimmen muss. Wo die Aufgaben auch so abge-‐‑ Erkenntnisse und Aspekte ein, so dass ein mög-‐‑
grenzt sind, dass man notgedrungen Schnittstellen lichst umfassendes Bild zum Lehren und Lernen
zu anderen hat."ʺ Ein weiterer Befragter würde es von Software Engineering entstehen kann.
auch gut finden, wenn den Studierenden auch Pro-‐‑ Parallel dazu findet eine weitere didaktische
jektverantwortung für ein Studienprojekt überge-‐‑ und inhaltliche Analyse der aktuellen Lehr-‐‑Lern-‐‑
ben würde. Konzepte für Software Engineering und der Ein-‐‑
flussvariablen auf die Lernprozesse statt. Die fach-‐‑
10. Fazit und Ausblick lichen Inhalte von Lehrveranstaltungen werden
wiederum in die Weiterentwicklung von Soll-‐‑Kom-‐‑
Insgesamt lässt sich festhalten, dass ein Software
petenzprofilen einfließen. Zudem ist bei der Ent-‐‑
Ingenieur eine Vielzahl fachlicher und überfachli-‐‑
wicklung didaktischer Konzepte eine detaillierte
cher Kompetenzen benötigt. Nun stellt sich die
Berücksichtigung der zu vermittelnden Inhalte un-‐‑
Frage, wie man diese benötigten Kompetenzen in
umgänglich.
der Hochschulausbildung am besten fördern kann.
Sobald konkretere Soll-‐‑Kompetenzprofile vor-‐‑
Auf diesem Weg ist die Beschreibung der Soll-‐‑
liegen, ist die Sichtweise der Lehrenden stärker ein-‐‑
Kompetenzen mittels eines Schemas, das diese zu
zubinden. Die Lehrenden nehmen im Lernprozess
verschiedenen Zeitpunkten vergleichbar macht,
der Studierenden eine Schlüsselposition ein und
nur ein erster Schritt.
prägen besonders auch durch ihre Vorstellungen
Die Analyse und Beschreibung der Soll-‐‑
und "ʺDefinitionen gelungenen Lernens"ʺ (Bender
Kompetenzen für Software Engineering muss noch
2009) das Lehren und Lernen maßgeblich. Daher ist
ausgebaut werden. Dies ist für sowohl für Kernin-‐‑
es sinnvoll, diese Sichtweisen zunächst separat mit
formatik als auch für alle anderen beteiligten Berei-‐‑
der erforderlichen Sorgfalt zu berücksichtigen. So
che wie Mechatronik oder Studiengänge mit nicht
sollen nicht nur inhaltlich-‐‑fachliche Lehrinhalte mit
primärem Informatikbezug notwendig. Um die
in die Bildung von Soll-‐‑Kompetenzprofilen einflie-‐‑
Tragfähigkeit der erhobenen Kompetenzprofile
ßen, sondern auch Erwartungen, Motive, Werthal-‐‑
weiter zu erhöhen, werden auch die Ergebnisse
tungen, Menschenbild und personenbezogene
anderen beteiligten Verbundhochschulen berück-‐‑
Merkmale etc. Welche Vorstellungen, Ideale, Ziele
sichtigt. Neben der Ausweitung der Datenbasis ist
und Wertvorstellungen haben die Lehrenden? Da-‐‑
es zudem notwendig, weitere Blickwinkel neben
rauf aufbauend werden zusammen mit den Leh-‐‑
der unternehmerischen Sicht einzubinden. Sinnvoll
renden aus den Soll-‐‑Kompetenzprofilen konkrete
ist es, beispielsweise auch Absolventen, Studieren-‐‑
kompetenzorientierte Lehrziele abgeleitet und
de oder Personalverantwortliche mit einzubezie-‐‑
Messkriterien für deren Erreichung definiert. Auch
hen. Auch kann es sinnvoll sein, die entstandenen
dieses Vorgehen ist wiederum ausgerichtet auf die
Kompetenzprofile für die verschiedenen Bereiche jeweiligen Lehrenden und die Lehrveranstaltun-‐‑
wie Kerninformatik oder Mechatronik miteinander gen, denn Lehrziele können nicht allgemeingültig
zu vergleichen.
formuliert sein.
A. Spillner, H. Lichter (Hrsg.): SEUH 13 127
Weitere zu erhebende Daten sind die Erwar-‐‑ Erpenbeck, J., Hrsg. (2007): Handbuch Kompe-‐‑
tungen, Motivationen und Vorkenntnisse der Stu-‐‑ tenzmessung. Erkennen, verstehen und bewer-‐‑
dierenden. In diesem Kontext stellt sich unter ande-‐‑ ten von Kompetenzen in der betrieblichen, pä-‐‑
rem die Frage, ob Studierende, die sich für ein be-‐‑ dagogischen und psychologischen Praxis. 2.
stimmtes Fach entscheiden, signifikante Eigen-‐‑ Aufl. Stuttgart: Schäffer-‐‑Poeschel.
schaften aufweisen. Auch das sind Faktoren, auf Flick, U. / von Kardorff, E. / Steinke, I. (2000): Was
die Lehr-‐‑Lern-‐‑Konzepte zugeschnitten werden ist qualitative Forschung? Einleitung und
müssen. Können sowohl bei den Lehrenden als Überblick. In: Qualitative Forschung. Ein
auch bei den Studierenden gewisse Systematiken Handbuch. Reinbeck: Rowohlt, 13-‐‑29.
oder Muster erkannt werden, die bei der Entwick-‐‑
lung didaktischer Konzepte berücksichtigt werden Fuller, U. et al (2007): Developing a computer
müssen und zumindest für Software Engineering sicience-‐‑specific Learning Taxonomy.
oder Teilbereiche davon signifikant auftreten? Verfügbar unter
So soll versucht werden, die Lücke zwischen http://www.cs.kent.ac.uk/pubs/2007/2798/conte
den Soll-‐‑ und Ist-‐‑Kompetenzen der Studierenden nt.pdf, abgerufen am 24.09.2012.
Schritt für Schritt zu verringern und die Hoch-‐‑ Granzer, D. / Köller, O. (2008): Kompetenzmodelle
schulausbildung im Software Engineering noch und Aufgabenentwicklung für die standardi-‐‑
weiter zu verbessern. sierte Leistungsmessung im Fach Deutsch. In:
Bremerich-‐‑Vos, A. / Granzer, D. / Köller, O.,
Danksagung Hrsg. (2008): Lernstandsbestimmung im Fach
Deutsch. Gute Aufgaben für den Unterricht.
Wir danken den Gutachtern für hilfreiche Anmer-‐‑
Weinheim: Beltz, 10-‐‑49.
kungen zu einer früheren Version dieses Beitrags.
Das Projekt EVELIN wird gefördert durch das Glaser, B. / Strauß, A. (1998): Grounded theory -‐‑
Bundesministerium für Bildung und Forschung Strategien qualitativer Forschung. Bern: Hans
unter der Fördernummer 01PL12022A. Huber.
Sedelmaier, Y. / Landes, D. (2012): A research
Literatur agenda for identifying and developing required
competencies in software engineering. Proc Int.
Abran, A. / Moore, J.W., Hrsg. (2004): Guide to the
Conference on Interactive Collaborative Learn-‐‑
Software Engineering Book of Knowledge. Los
ing 2012.
Alamitos, CA: IEEE Computer Society Press.
Verfügbar unter: Weinert, F. (2001): Leistungsmessung in Schulen. 2.
http://www.computer.org/portal/web/swebok/ Auflage Weinheim: Beltz.
htmlformat
Anderson, L. / Krathwohl, D., Hrsg. (2001): A tax-‐‑
onomy for learning, teaching, and assessing. A
revision of Bloom'ʹs taxonomy of educational
objectives. New York: Longman.
Bender, W.: Wie kann Qualitätsentwicklung aus
dem Pädagogischen heraus entwickelt werden?
-‐‑ Pädagogische Reflexivität. In: Dehn, C., Hrsg.
(2009): Pädagogische Qualität. Hannover: Ex-‐‑
pressum-‐‑Verlag, 69-‐‑77.
Bloom, B. (1972): Taxonomie von Lernzielen im
kognitiven Bereich. Weinheim: Beltz.
Böttcher, A., Thurner, V., Müller, G. (2011): Kompe-‐‑
tenzorientierte Lehre im Software Engineering.
In: Ludewig, J., Böttcher, A., Hrsg. (2011):
SEUH 2011, 33-‐‑39.
Claren, S. (2012): Erhebung und Beschreibung von
Kompetenzen im Software Engineering. Mas-‐‑
terarbeit, Hochschule Coburg.
Donabedian, A. (1980): Explorations in Quality
Assessment and Monitoring: The definition of
quality and approaches to its assessment. Ann.
Arbor, MI: Health Administration Press, 1980.
128 A. Spillner, H. Lichter (Hrsg.): SEUH 13