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