Nach unserer eigenen Lehrerfahrung ebenso wie der von zahlreichen Kolleginnen und Kollegen fällt es vielen Studierenden in MINT-Fächern schwer, höhere Kompetenzebenen gemäß der überarbeiteten Lernzieltaxonomie von Bloom (Anderson u. a., 2001) zu erreichen. Als Grundlage für die Konzeption von Lehr/Lernmethoden, die für die Entwicklung dieser höheren Kompetenzebenen förderlich sind, definieren wir detaillierte Lernziele für die entsprechenden fachlichen Kompetenzen. Diese ergänzen wir um Lernzieldefinitionen für diejenigen Schlüsselkompetenzen, die eine essenzielle Voraussetzung dafür sind, dass diese fachlichen Kompetenzen auf der gewünschten Stufe überhaupt entwickelt werden können.
Heutzutage müssen gute Softwerker mit
anspruchsvollen Jobs in der Lage sein, in einem komplexen Umfeld
und unterschiedlichsten Kontexten sicher zu agieren.
Dafür müssen Sie sowohl über eine Fülle von
nichtfachlichen Kompetenzen verfügen als auch fachlich
hochqualifiziert sein
Um diesen fachlichen Anforderungen gerecht zu
werden, müssen die Studierenden hochwertige
kognitive Fähigkeiten entwickeln, die weit darüber
hinaus gehen, einfach nur irgendwelches Wissen
auswendig zu lernen und in der Prüfung
wiederzugeben
Grundlage für die Konzeption solcher Lehrmethoden ist die detaillierte Definition von entsprechenden Lernzielen, die genau beschreiben, was denn eigentlich eine bestimmte Fähigkeit auf einer bestimmten Kompetenzebene ausmacht. Diese muss insbesondere die fachlichen Fähigkeiten definieren, die die Studierenden entwickeln sollen.
Beim Definieren der angestrebten fachlichen Kompetenzen und aus den Erfahrungen unseres Lehralltages wurde deutlich, dass zwischen den fachlichen und den nicht-fachlichen Kompetenzen gewisse Abhängigkeiten bestehen. Insbesondere beobachten wir, dass ausgewählte Schlüsselkompetenzen wie z. B. das abstrakte Denken oder die Fähigkeit zur Selbstreflexion mit einem gewissen Reifegrad in den Studierenden ausgebildet sein müssen, bevor sie hochwertige fachliche Kompetenzen überhaupt entwickeln können.
Nicht alle Studierenden bringen jedoch diese erforderlichen Schlüsselkompetenzen in ausreichendem Maße mit, sondern müssen diese erst im Laufe ihres Studiums entwickeln. Daher ist es notwendig und sinnvoll, für ausgewählte Schlüsselkompetenzen ebenfalls Lernziele auf den verschiedenen Kompetenzebenen zu definieren, um greifbar zu machen, welche Fähigkeiten hier konkret erwartet werden bzw. zu entwickeln sind.
Um unsere Studierenden angemessen auf ihr späteres Arbeitsleben vorzubereiten, streben wir an, ihre fachlichen Kompetenzen bis hin zu den hochwertigen kognitiven Ebenen zu entwickeln. Dazu definieren wir für die Pflichtveranstaltungen „Softwareentwicklung 1 und 2“ aus dem ersten und zweiten Fachsemester der Studiengänge Bachelor Informatik und Bachelor Wirtschaftsinformatik fachliche Lernziele auf unterschiedlich anspruchsvollen Kompetenzebenen.
Des Weiteren definieren wir Lernziele für ausgewählte Schlüsselkompetenzen, die für die Entwicklung der höherwertigen fachlichen Lernziele essenziell erforderlich sind. Diese Lernziele sind die Grundlage für die Konzeption von Lehrmethoden und Interventionen, die den Auf- und Ausbau dieser zentralen Schlüsselkompetenzen in den Studierenden gezielt fördern.
Orientiert an
Als Schlüsselkompetenzen bezeichnen
Ein bekannter Ansatz zur Beschreibung von Lernzielen im kognitiven Bereich ist die Lernzieltaxonomie von Bloom (Bloom u. a., 1956), die Kompetenzen auf verschiedenen Fähigkeitsebenen definiert. Dieser Ansatz wurde später insbesondere hinsichtlich der höheren Kompetenzebenen von (Anderson u. a., 2001) überarbeitet.
Im Folgenden orientieren wir uns an dieser überarbeiteten Version, mit den Kompetenzstufen 1: Erinnern, 2: Verstehen, 3: Anwenden, 4: Analysieren, 5: Evaluieren und 6: Kreieren.
Die nachfolgenden Tabellen definieren Lernziele für die fachlichen Inhalte, die im Fokus der Lehrveranstaltungen „Softwareentwicklung 1“ bzw. „Softwareentwicklung 2“ stehen, die an der Fakultät für Informatik und Mathematik der Hochschule München durchgeführt werden. In den einzelnen Spalten werden bewusst nicht die Verben aus den Spaltenüberschriften (den Kompetenzebenen nach der überarbeiteten Lernzieltaxonomie von Bloom) verwendet. Stattdessen werden Verben gewählt, die ein von außen beobachtbares Ergebnis nach sich ziehen. Dadurch wird die Testbarkeit der Lernziele gewährleistet.
Da die Kompetenzen auf den verschiedenen Ebenen für viele der fachlichen Inhalte vom Prinzip her ähnlich gelagert sind, definieren Tabellen 1 und 2 (oben) die Lernziele generisch im Sinne einer Schablone, in deren Formulierung bei Bedarf konkrete programmiersprachliche Konstrukte bzw. Artefakte einzusetzen sind.
Ergänzend werden in Tabellen 1 und 2 (mitte) Lernziele für Qualitätskriterien für Software definiert, da diese Qualitätskriterien als Maßstab für die generischen Lernziele für Softwareentwicklung benötigt werden. Für den Bereich der Qualitätskriterien liegen die Lernziele der Level 5 (Evaluieren) und 6 (Kreieren) dabei nicht mehr im Fokus der Lehrveranstaltungen „Softwareentwicklung 1 und 2“.
Die Lernzieldefinitionen in Tabellen 1 und 2 (unten) sowie 3 und 4 (oben) zeigen exemplarisch für die fachlichen Inhalte Kontrollstrukturen und Algorithmen, wie die generische Definition der Lernziele für Softwareentwicklung schematisch auf programmiersprachliche Konstrukte übertragen wird. Nach dem gleichen Schema verlaufen die Lernzieldefinitionen für alle anderen programmiersprachlichen Konstrukte, die in der Lehrveranstaltung behandelt werden, insbesondere für die folgenden inhaltlichen Themenbereiche: Klassen, Datentypen, Variablen, primitive Datentypen, Sichtbarkeit, Pakete, Zeichenketten, Arrays, Rekursion, Listen, Vererbung, Exception Handling, Generische Datentypen und Collections. Da diese Lernzieldefinitionen hochgradig redundant mit der generischen Definition verlaufen, bieten sie keinen nennenswerten Mehrwert gegenüber der generischen Definition. Entsprechend wird hier auf eine weitere Ausarbeitung für andere programmiersprachliche Konstrukte verzichtet.
Einige der fachlichen Inhalte, die in der Lehrveranstaltung „Softwareentwicklung“ behandelt werden, sind jedoch prinzipiell anders gelagert als die programmiersprachlichen Konstrukte. Entsprechend erfordern deren zugehörige Kompetenzen daher eine komplett eigenständige Lernzieldefinition, die sich nicht schematisch aus der generischen Lernzieldefinition ableiten lässt.
Die Programmentwicklung ist eine ausgeprägt konstruktive Tätigkeit, bei der ein (hoffentlich) lauffähiges System erstellt und somit etwas geschaffen wird. Im Gegensatz dazu ist Testen vom Prinzip her eine destruktive Tätigkeit (auch wenn das Ziel des Testens ist, dass das geschaffene System am Ende stabil und damit qualitativ besser wird). Beim Testen geht es darum, wunde Punkte zu identifizieren und diese sichtbar zu machen. Dieses prinzipiell andere Ziel erfordert andere Ansätze und damit auch andere Kompetenzen als der zu entwickelnde Anteil der Softwareentwicklung (siehe Tabellen 3 und 4 (Mitte)). Die Lernziele auf Level 6 (Kreieren) liegen dabei nicht mehr im Fokus der Lehrveranstaltungen „Softwareentwicklung 1 und 2“.
Debugging wiederum, also die systematische Fehlersuche, ist eine methodenintensive Fachlkompetenz (siehe Tabellen 3 und 4 (unten)). Auch hier wird im Gegensatz zur eigentlichen Programmierung kein Produkt gebaut, das zwar virtuell, aber trotzdem irgendwie greifbar ist. Statt dessen geht es beim Debugging eher um die Anwendung von Werkzeugen und Strategien zum Finden und Beseitigen von Fehlern, die nach erfolgreichem Debugging hoffentlich nicht mehr da sind. Entsprechend sind auch hier potenziell messbare Ergebnisse der einzelnen Kompetenzstufen grundsätzlich anders geartet als bei den programmiersprachlichen Konstrukten, sodass eine spezifische Lernzieldefinition für den Themenbereich des Debuggings erforderlich ist. Auch in diesem fachlichen Bereich liegen die Lernziele auf Level 6 (Kreieren) nicht mehr im Fokus der Lehrveranstaltungen „Softwareentwicklung 1 und 2“.
In der Lehrpraxis ist zu beobachten, dass viele Studierende sich nicht nur beim Erlernen spezifischer fachlicher Inhalte schwer tun, sondern dass das prinTabelle 1: Definition generischer und konkreter fachlicher Lernziele für Softwareentwicklung (Teil 1) ... schreiben die konkrete ... begründen, welches Syntax eines programmier- programmiersprachliche Konsprachlichen Konstruktes kor- strukt in welchem Kontext zu rekt auf und halten dabei die verwenden ist, und warum.
Syntaxkonventionen ein. ... ermitteln zu einer gegebenen Implementierung und konkreten Eingabe- bzw.
Startwerten das konkrete Ergebnis. ... halten bei der Softwareentwicklung die vorgegebenen Qualitätskriterien ein. ... setzen eine textuell oder grafisch vorgegebene Algorithmusspezifikation in Quelltext einer festgelegten Programmiersprache um und verwenden dabei die passenden Kontrollstrukturen.
Der Quelltext erfüllt dabei grundlegende Qualitätsanforderungen (Lesbarkeit, Testbarkeit, Korrektheit). ... benennen grundlegen- ... erklären in eigenen de Qualitätskriterien für Worten die Bedeutung der Software, z.B. Lesbarkeit, einzelnen Qualitätskriterien.
Testbarkeit, Korrektheit und Effizienz. ... definieren die Bedeutung der Qualitätskriterien.
... begründen, warum Softwareentwicklung aus mehr Schritten besteht als nur der Implementierung. ... beschreiben, warum diese Qualitätskriterien wichtig sind und welche Folgen es hat, wenn sie nicht eingehalten werden. ... benennen verschiedene Ar- ... erklären in eigenen ten von Kontrollstrukturen. Worten die Bedeutung der
verschiedenen Kontrollstruk... definieren für jede Art turen. von Kontrollstruktur deren Bedeutung.
... beschreiben in eigenen Worten die Unterschiede zwischen for-, while- und do-while-Schleife. ... benennen in einem vorgegebenen Quelltext die dort verwendeten Kontrollstrukturen mit den korrekten Fachbegriffen.
... beschreiben in eigenen Worten die Unterschiede zwischen if-, if-else- und switch- ... werten zu einer gegebenen ... schreiben für jede Art von Fallunterscheidungen. Implementierung die KonKontrollstruktur deren kon- trollstrukturen korrekt aus, krete Syntax auf und halten ... begründen, welche Kon- indem sie zu konkreten dabei die Syntaxkonventio- trollstruktur in welchem Eingabe- bzw. Startwerten nen ein. Kontext zu verwenden ist, das konkrete Ergebnis ermitund warum. teln. ... geben zu einer vorgegebenen ... wägen systematisch ab, welches ... entwickeln für ein einfaches Implementierung an, was diese Konzept bzw. Konstrukt der Problem aus einer gegebenen prinzipiell macht, abstrahiert Programmiersprache am besten Anforderungsspezifikation heraus von konkreten Eingabe- bzw. geeignet ist, um eine bestimmte einen Entwurf, der sowohl die Startwerten. Anforderung umzusetzen. Gesamtstruktur der Lösung als auch die einzelnen Algorithmen ... ermitteln aus einer informell ... identifizieren Stärken und vorgibt. Der Entwurf erfüllt dabei gegebenen Problemformulierung Verbesserungspotenzial in einem grundlegende Qualitätsanfordedie Anforderungen und doku- gegebenen Artefakt (Anforde- rungen (Korrektheit, Effizienz der mentieren diese präzise in einer rungsspezifikation, Testfälle, Algorithmen, Testbarkeit). angemessenen Form (grafisch Entwurf, Algorithmusspezifikation, oder textuell). Quelltext) oder in der Problemfor- (Ein „einfaches Problem“ ist damulierung bzw. Anforderungsbe- bei eine Aufgabenstellung, die mit ... identifizieren in einer gege- schreibung des Kunden. maximal zehn Klassen objektorienbenen Anforderungsbeschreibung tiert zu lösen ist. Für komplexeStrukturen und Zusammenhänge re Probleme ist diese Kompetenz und dokumentieren diese präzise Lernziel der Veranstaltung „Softin einer angemessenen Form (gra- ware Engineering“.) fisch oder textuell).
... bewerten ihre eigene Lösung (d.h. ein von ihnen selbst erstelltes Artefakt) kritisch auf Stärken und Schwächen, die hinsichtlich grundlegender Qualitätsanforderungen bestehen (Lesbarkeit, Testbarkeit,
Korrektheit). ... untersuchen, inwieweit eine bestehende Software die vorgegebenen Qualitätsanforderungen erfüllt.
... bewerten kritisch, ob die beste- ... definieren selbst neue, eigene henden Qualitätskriterien für ein Qualitätskriterien für neuartige Angegebenes Anwendungsszenario wendungsszenarien.
angemessen und ausreichend sind. ... identifizieren Verstöße gegen die vorgegebenen Qualitätskriterien. ... geben zu einer vorgegebenen ... wägen systematisch ab, wel- ... entwickeln für ein einfaches Folge/Konstruktion aus Kon- che Kontrollstruktur am besten Problem aus einer gegebenen trollstrukturen an, was diese geeignet ist, um eine bestimmte Anforderungsspezifikation heraus prinzipiell macht, abstrahiert Anforderung umzusetzen. einen Algorithmus oder Quellvon konkreten Eingabe- bzw. text, der dazu die geeigneten Startwerten. ... identifizieren Stärken und Kontrollstrukturen verwendet.
Verbesserungspotenzial in einem Dieser erfüllt dabei grundlegende ... ermitteln aus einer gege- gegebenen Artefakt (Algorithmus- Qualitätsanforderungen (Korrektbenen Anforderungsbeschreibung, spezifikation, Quelltext). heit, Effizienz der Algorithmen, mit welchen Kontrollstrukturen Testbarkeit). die Anforderung prinzipiell erfüllt werden kann.
... bewerten ihre eigene Lösung (d.h. ein von ihnen selbst erstelltes Artefakt) kritisch auf Stärken und Schwächen, die hinsichtlich grundlegender Qualitätsanforderungen bestehen (Lesbarkeit, Testbarkeit,
Korrektheit).
Tabelle 3: Beispiele für konkrete fachliche Lernziele für Softwareentwicklung (Teil 1) ... definieren den Begriff ... begründen, warum auto- ... erstellen schematisch Unit-Testen. matisiertes Testen notwendig grundlegende Testfälle. und sinnvoll ist. ... beschreiben in eigenen Worten die Bedeutung und den qualitätssichernden Beitrag einer vollständigen Testabdeckung.
... setzen systematisch Werkzeuge ein, die den Grad der erreichten Testabdeckung ermitteln. ... nutzen ein Werkzeug wie z.B. JUnit, um Unit-Tests automatisiert auszuführen. ... benennen verschiedene assert-Methoden, die in JUnit-Tests verwendet werden können. ... benennen die verschiedenen Annotationen für Unit-Tests. ... schreiben die konkrete Syntax für Testklassen und Testmethoden auf und halten dabei die Syntaxkonventionen ein. ... benennen verschiedene Ansätze für das Debugging. ... benennen verschiedene Grundfunktionen eines Debugging-Werkzeuges. ... gleichen beim Verwenden des Debuggers das, was der Debugger anzeigt, ab mit der eigenen mentalen Erwartung, bis beides nicht mehr zueinander passt und zeigen so Soll-/Ist-Differenzen auf. ... definieren den Begriff ... erklären in eigenen Wor- ... verwenden den DebugDebugging. ten, warum die Verwendung ger schematisch, um das eines Debugging-Werkzeuges Programmverhalten zu sinnvoll ist visualisieren.
... geben zu einem vorgegebenen Algorithmus an, was dieser prinzipiell macht, abstrahiert von konkreten Eingabe- bzw. Startwerten. (Bsp.: Der Algorithmus ermittelt den größten gemeinsamen Teiler zweier natürlichen Zahlen.)
Tabelle 4: Beispiele für konkrete fachliche Lernziele für Softwareentwicklung (Teil 2) ... wägen systematisch ab, welches Konzept bzw. Konstrukt der Programmiersprache am besten geeignet ist, um eine bestimmte Anforderung in einem Algorithmus umzusetzen. ... identifizieren Stärken und Verbesserungspotenzial in einer gegebenen Algorithmusspezifikation. ... bewerten einen von ihnen selbst erstellen Algorithmus kritisch auf Stärken und Schwächen, die hinsichtlich grundlegender Qualitätsanforderungen bestehen (Lesbarkeit, Testbarkeit, Korrektheit).
... entwickeln für ein einfaches Problem aus einer gegebenen Anforderungsspezifikation heraus einen Algorithmus. Dieser erfüllt dabei grundlegende Qualitätsanforderungen (Korrektheit, Effizienz, Testbarkeit). ... untersuchen, welche Rand- und ... bewerten, ob die Menge und ... entwickeln eigene TeststraNormalfälle in einer gegebenen Art der formulierten Tests zur tegien für komplexe, neuartige Aufgabenstellung auftreten, fassen Qualitätssicherung ausreichend ist. Problemstellungen. diese zu geeigneten Äquivalenz- (Die werkzeuggemessene Testabklassen zusammen und definieren deckung ist nur ein Teil dieses Be- ... entwickeln eine neue Testinfradazu passende Testfälle als Reprä- wertungsprozesses.) struktur. sentanten. ... ziehen Rückschlüsse aus den im Debugger erkannten Differenzen aus Soll und Ist. Dabei suchen sie nach der Ursache der beobachteten Differenzen und ermitteln die Stelle, an der die Ursache vermutet wird und an der somit die Lösung ansetzen muss.
... bewerten, ob eine gegebene, ... entwickeln neuartige Strategien selbst angewendete oder beobach- zur Suche und Eingrenzung von tete Vorgehensweise zur Fehlersu- Softwarefehlern.
che zielführend und effizient ist. zipielle Erreichen einer bestimmten Kompetenzebene Probleme aufwirft, unabhängig vom konkreten fachlichen Inhalt. Dies führte zu der These, dass nicht ausschließlich fachliche Defizite dafür verantwortlich sind, dass Studierende eine gewünschte höhere Kompetenzebene für einen konkreten fachlichen Inhalt gar nicht oder nur eingeschränkt entwickeln können. Vielmehr müssen also bestimmte Schlüsselkompetenzen in den Studierenden bereits bis zu einem gewissen Grad entwickelt sein, damit insbesondere die höheren Ebenen der überarbeiteten Lernzieltaxonomie von Bloom überhaupt erreichbar sind.
Um diese These zu belegen haben wir eine Vielzahl
von Fehlern analysiert, die beim Erlernen des
Programmierens mit großer Häufigkeit auftreten, basierend
sowohl auf Fehlern aus der Literatur (wie z. B.
Beispielsweise setzt die Ebene 4 Analysieren
zwingend die Fähigkeit des analytischen Denkens voraus,
sowie (zumindest im informatischen Kontext)
abstraktes Denken. Ebene 5 Evaluieren erfordert unter
anderem kritisches Hinterfragen sowie ggf. die Fähigkeit
zur Selbstreflexion, und Ebene 6 Kreieren benötigt ein
gewisses Maß an Kreativität. Tabelle 5 fasst die
Ergebnisse zusammen, in Erweiterung von
Wenn wir mit unseren Studierenden insbesondere die höheren Kompetenzebenen nach der überarbeiteten Lernzieltaxonomie von Bloom erreichen wollen, müssen diese grundlegenden Schlüsselkompetenzen also zunächst in ausreichendem Umfang vorhanden sein, bzw. bei Bedarf entsprechend entwickelt werden.
Erst wenn hier die notwendigen Voraussetzungen geschaffen sind macht es Sinn, sich auf die entsprechenden fachlichen Inhalte zu fokussieren, weil diese sonst ohnehin nicht effektiv gelernt werden können.
Die Frage, inwieweit die Entwicklung der erforderlichen Schlüsselkompetenzen im Aufgabenbereich der Hochschullehre liegt, ist nicht einfach zu beantworten.
Eine umfassende Diskussion der möglichen Sichtweisen liegt nicht im Fokus dieser Arbeit.
Unabhängig vom konkreten fachlichen Inhalt sind also bestimmte Schlüsselkompetenzen erforderlich, um fachliche Kompetenzen auf einer gewünschten höheren Ebene gemäß der überarbeiteten Lernzieltaxonomie von Bloom überhaupt entwickeln zu können.
Um greifbar zu machen, was diese Schlüsselkompetenzen im informatik-nahen Lernkontext genau bedeuten und welches Maß an Fähigkeiten als erforderlich vorausgesetzt bzw. bei Bedarf zu entwickeln ist, definieren wir im Folgenden auch für einige Schlüsselkompetenzen Lernziele gemäß der überarbeiteten Lernzieltaxonomie von Bloom. Dabei fokussieren wir lediglich eine Auswahl an relevanten Schlüsselkompetenzen, mit jeweils einem Repräsentanten aus den Bereichen der Selbst-, Sozial- und Methodenkompetenzen.
Auch hier liegen jeweils die Lernziele auf Level 6 (Kreieren) der einzelnen ausgewählten Schlüsselkompetenzen nicht mehr im Fokus der Lehrveranstaltungen „Softwareentwicklung 1 und 2“.
„Einsicht ist der erste Schritt zur Besserung“, sagt ein deutsches Sprichwort. Dahinter steckt die Idee, dass ich ein Problem selbst nur dann beheben kann, wenn ich es erkannt habe und darüber nachdenken kann.
In diesem Sinne ist die Fähigkeit zur Selbstreflexion also zentraler Bestandteil eines effizienten Lernprozesses und damit eine Selbstkompetenz, die für den Studienerfolg, das spätere Arbeitsleben sowie allgemein auch für die persönliche Weiterentwicklung im privaten Leben von zentraler Bedeutung ist. Gleichzeitig zeigt unsere Lehrerfahrung aus den letzten Jahren, dass die Fähigkeit zur Selbstreflexion bei unseren Studierenden zu Beginn des Studiums wenig bis gar nicht ausgeprägt ist. Daher fokussieren wir diese Kompetenz in besonderem Maße als eine Schlüsselkompetenz im Sinne der Studierfähigkeit.
Tabellen 6 und 7 (oben) definieren für die Fähigkeit der Selbstreflexion Lernziele auf den verschiedenen Kompetenzebenen. Wünschenswert im Sinne der Studierfähigkeit wäre eine Kompetenzebene von mindestens Stufe 4 (Analysieren). Viele unserer Studierenden (insbesondere diejenigen, die sich fachlich schwer tun) verfügen jedoch lediglich über Stufe 1 (Erinnern) dieser Fähigkeit. D. h. ihnen ist zwar immerhin der Begriff vage bekannt. Ein Grundverständnis dafür, inwieweit Selbstreflexion den eigenen Lernprozess unterstützt, ist dagegen bei diesen Personen meist nicht vorhanden.
Gerade dann, wenn die Fähigkeit zur Selbstreflexion erst unzureichend entwickelt ist, ist Feedback von außen oft ein notwendiges Mittel, um Stärken und Schwächen bewusst zu machen und so eine Weiterentwicklung effektiv auf den Weg zu bringen. Diese „Weiterentwicklung von außen“ setzt jedoch voraus, dass der Empfänger mit dem erhaltenen Feedback angemessen umzugehen weiß. Entsprechend ist Kritikfähigkeit in der Rolle der Kritikempfangenden wichtiger Bestandteil der Studierfähigkeit.
In vielen Veranstaltungen arbeiten die Studierenden in Teams zusammen. Darüber hinaus streben viele
Tabelle 5: Schlüsselkompetenzen, die zum Erreichen einer fachlichen Kompetenzebene notwendig sind (Auswahl)
Kreativität Abstraktes Denken (Neuartige Gesetzmäßigkeiten finden) Analytisches Denken (Kritische Punkte identifizieren) Abstraktes Denken (Relevanz der kritischen Punkte werten) Kritisches Hinterfragen Selbstreflexion (Bei Evaluation eigener Ergebnisse) Pragmatismus (Kosten-Nutzen-Entscheidung fällen) Analytisches Denken (Bestandteile identifizieren,
Zusammenhänge erkennen) Abstraktes Denken (Sinn der Zusammenhänge werten) Abstraktes Denken (Passende Abstraktionsstrategie wählen) Analytisches Denken (Problem klassifizieren) Entscheidungsfähigkeit (Lösungsansatz wählen) Abstraktes Denken (Regelwerk erkennen und anwenden) Analytisches Denken (Zusammenhänge nachvollziehen) Ganzheitliches Denken (Mit Vorwissen verbinden) Durchhaltevermögen Fleiß Selbstreflexion (Eigenen Lerntyp kennen, eigene Fähigkeiten einschätzen) 6 5 4 3 2 1 0
„Mental Typo“ nach
D. E. Knuth
Tabelle 6: Definition von Lernzielen für Schlüsselkompetenzen (Teil 1) ... definieren den Begriff ... begründen die Strin- ... formulieren als FeedbackKritikfähigkeit. genz der Feedback-Regeln Geber ihre Kritik gemäß der für Feedback-Geber und Feedback-Regeln. ... benennen die beiden Feedback-Nehmer. (Das Identifizieren der KritikRollen, die eine Person im punkte, die hier kommuniKontext von Kritik einneh- ... beschreiben in eigenen ziert werden, kommt dabei men kann. Worten die Bedeutung von aus einem anderen Kompe
Kritik für die persönliche Wei- tenzbereich, beispielsweise ... benennen die zentralen Re- terentwicklung. aus der „Evaluieren“-Spalte geln für das Geben und Emp- einer fachlichen Kompetenz.) fangen von Feedback. ... halten als FeedbackNehmer beim Empfangen von Kritik die formalen Feedback-Regeln ein, hören also zu und rechtfertigen sich nicht. ... definieren die Begriffe ... erklären, dass es in der ... leiten aus einer gegebenen Abstrahieren und Konkreti- Informatik überwiegend um einfachen Abstraktion bzw. sieren. abstrakte Inhalte geht und einem gegebenen einfachen abstraktes Denken daher Regelwerk konkrete Dinge ... definieren die Kompetenz in diesem Bereich eine und Aussagen ab. des abstrakten Denkens. unerlässliche Fähigkeit ist. ... definieren den Begriff Ab- ... begründen, dass jegliches straktionsebene und die Zu- Verstehen eines Sachverhalsammenhänge zwischen kon- tes voraussetzt, dass das kreter Ebene, Typ-Ebene und grundlegende Regelwerk bzw.
Meta-Ebene. die grundlegenden Gesetz- ... ermitteln aus einer gegebemäßigkeiten verstanden wur- nen Menge von nichttrivialen den. Beispielen anhand eines (Bsp: Auch wenn ich weiß, vorgegebenen Leitfadens das dass 2+3=5 gilt kann ich zugrunde liegende Regel3+4=? trotzdem nur lösen, werk. wenn ich das grundlegende Regelwerk verstanden habe.) ... extrahieren aus einer gegebenen Menge von konkreten, einfachen Beispielen das zugrunde liegende, ebenfalls noch einfache Regelwerk. ... lesen aus einem vorgegebenen Metamodell Aussagen über die darunter liegende Typ-Ebene heraus. Tabelle 7: Definition von Lernzielen für Schlüsselkompetenzen (Teil 2) ... bewerten, ob ein gegebenes ... konzipieren eigenständig einen Konzept der Selbstreflexion für Leitfaden zur Selbstreflexion (ggf. das von ihnen angestrebte Ziel der gemeinsam mit einem zugehöriReflexionsarbeit hilfreich ist. gen Übungsszenario), der anderen
Personen als Anleitung für deren ... beobachten ihren eigenen Selbstreflexion über eine bestimmReflexionsprozess und bewerten, te Situation, Vorgehensweise oder inwieweit dieser stattfindet und ein selbst erstelltes Artefakt als zielführend für das angestrebte Leitfaden dient und dabei gezielt Reflexionsziel ist. auf diejenige Erkenntnis hinarbeitet, die als Ziel der Reflexionsarbeit gewünscht ist. ... bestimmen ein Ziel für die Selbstreflexion, also eine tiefer greifende Erkenntnis, die mittels Selbstreflexion gewonnen werden soll. ... erarbeiten die Ursachen der beobachteten Symptome. ... identifizieren Maßnahmen, die geeignet sind, um die Symptome zukünftig zu vermeiden (falls diese negativ waren) oder erneut zu provozieren (falls diese positiv waren); im Sinne von „Lessons Learned“. ... überlegen sich in der Rolle als Feedback-Geber, wie die Kritik formuliert werden muss, damit das Gegenüber sie annehmen kann. ... setzen sich in ihrer Rolle als Feedback-Nehmer inhaltlich mit Kritik und Verbesserungsvorschlägen auseinander und versuchen, diese nachzuvollziehen. ... identifizieren ein Ziel („Kri- ... reflektieren in ihrer Rolle als ... konzipieren eigenständig einen tikziel“, das sie mit dem Geben Feedback-Geber ergebnisoffen Leitfaden und ggf. ein Übungsszebzw. Empfangen von Feedback darüber, welche der von ihnen nario, das andere Personen als Anerreichen möchten. identifizierten Kritikpunkte im leitung für das Geben bzw. Empgegebenen Kontext zielführend fangen von Feedback nutzen könsind. nen, um deren Kritikfähigkeit zu
schulen. ... reflektieren in ihrer Rolle als Feedback-Nehmer ergebnisoffen darüber, welche der empfangenen Kritikpunkte und Verbesserungsvorschläge sie für sich als schlüssig und anwendbar erachten. ... finden einen stringenten Ansatz, ... bewerten, ob das Ergebnis einer um aus einer vorgegebenen Abstraktionsaufgabe (d.h. ein Menge von konkreten Beispielen abstraktes Modell bzw. Regelwerk) ein passendes Regelwerk zu eine für diese Aufgabe sinnvolle extrahieren und wählen dazu Abstraktion ist, inkl. der gewählten eine geeignete Abstraktions- bzw. Struktur der Abstraktionsebenen.
Lösungsstrategie aus. ... wenden zum Lösen einer Abstraktionsaufgabe eine Metastrategie an, um eine geeignete Abstraktions- bzw. Lösungsstrategie zu identifizieren.
... prüfen und bewerten, ob das (eigene oder fremde) Vorgehen bei der Abstraktion zielführend und effizient ist.
... entwickeln selbst einen Leitfaden für Abstraktion in einem bestimmten Kontext. ... erarbeiten selbst eine Aufgabe, die die Anwendung abstrakten Denkens erfordert. ... konzipieren zu einem neuem Kontext und einer neuen Art von Aufgabe eigenständig eine (neuartige) Abstraktionsstrategie. ... entwickeln selbst ein neuartiges Metamodell. im Berufsleben mittelfristig eine Führungstätigkeit an.
Folglich ist auch die Kritikfähigkeit in der Rolle der Kritikgebenden eine erforderliche Schlüsselkompetenz.
Da viele unserer Studierenden weder in der gebenden noch in der empfangenden Rolle in ausreichendem Maße über Kritikfähigkeit verfügen, fokussieren wir diesen Bereich im Sinne der Studierfähigkeit als zentrale Sozialkompetenz (siehe Tabellen 6 und 7 (Mitte)). Wünschenswert im Sinne der Studierfähigkeit wäre auch hier eine Kompetenzebene von mindestens Stufe 4 (Analysieren), besser noch Stufe 5 (Evaluieren).
Viele Studierende befinden sich hier jedoch auf Stufe 1 (Erinnern). Beispielsweise ist zu beobachten, dass viele Studierende auch auf angemessen formulierte Verbesserungshinweise mit langen „Ja aber“artigen Rechtfertigungen oder Ähnlichem reagieren.
Ein Grundverständnis dafür, dass Kritik eine wertvolle Unterstützung bei der eigenen Weiterentwicklung darstellen kann, ist in diesen Fällen offensichtlich nicht vorhanden. Feedback-Regeln, die insbesondere in der Rolle des Feedback-Gebers einzuhalten sind, sind vielen Studierenden ebenfalls nicht bekannt.
Viele fachliche Inhalte der Informatik befassen sich mit Konzepten, die nicht physisch greifbar sind und somit ein hohes Maß an abstraktem Denken erfordern. Des Weiteren erfordert jeglicher fachliche Kompetenzerwerb, der über rein auswendig gelerntes Wissen hinaus geht, ein Grundmaß an Abstraktion, da bereits für das Verstehen (Stufe 2) eines jeglichen fachlichen Sachverhaltes dessen grundlegende Gesetzmäßigkeiten erfasst werden müssen. Diese grundlegenden Gesetzmäßigkeiten sind selbst bereits eine Abstraktion konkreter Einzelbeobachtungen aus der realen Welt. Entsprechend ist das abstrakte Denken eine weitere Schlüsselkompetenz, die insbesondere für informatiknahe Studiengänge von entscheidender Bedeutung ist.
Tabellen 6 und 7 (unten) definieren für das abstrakte Denken Lernziele auf den verschiedenen Kompetenzebenen nach der überarbeiteten Lernzieltaxonomie von Bloom. Auch hier wäre eine Stufe 4 (Analysieren) oder sogar Stufe 5 (Evaluieren) bei den Studierenden wünschenswert. In der Realität kennen viele Studierende zwar relativ schnell die zentralen Grundbegriffe der Abstraktion und verstehen deren Bedeutung für den informatik-nahen Lernprozess. Spätestens bei Stufe 3 (Anwenden) sind jedoch massive Schwierigkeiten zu beobachten, beispielsweise beim Ableiten einer Regel, eines Modells oder einer Klassenstruktur aus konkreten Beispielen.
Angesichts dieser Defizite in den grundlegenden Schlüsselkompetenzen ist es also nicht verwunderlich, dass Studierende Schwierigkeiten haben, diejenigen fachlichen Kompetenzebenen zu erreichen, für die diese Schlüsselkompetenzen zentrale Voraussetzung sind.
Durch die detaillierte Definition der fachlichen Lernziele über die verschiedenen Kompetenzebenen hinweg haben wir aufgeschlüsselt, was eine softwaretechnische Fachkompetenz auf den einzelnen Ebenen der überarbeiteten Lernzieltaxonomie von Bloom jeweils ausmacht. Analog haben wir auch für die relevanten überfachlichen Schlüsselkompetenzen erarbeitet, welcher genauen Fähigkeit diese auf den jeweiligen Kompetenzebenen entsprechen. Dadurch wurden nicht nur die an die Studierenden gestellten fachlichen Anforderungen klarer herausgearbeitet, sondern auch verdeutlicht, welche Schlüsselfertigkeiten in welchem Umfang Voraussetzung für ein erfolgreiches informatik-nahes Studium sind.
Darauf basierend können wir nun gezielt Lehrkonzepte für Interventionen erarbeiten, die zum einen die relevanten Schlüsselkompetenzen bis auf die erforderlichen Ebenen hin aufbauen, und zum anderen auf dieser Grundlage die gewünschten fachlichen Kompetenzen in den Studierenden entwickeln. Dabei ist zu berücksichtigen, dass die Ausgangsbasis (d. h. die Eingangsqualifikation) der Studierenden an den Hochschulen erfahrungsgemäß sehr heterogen ist, sowohl fachlich als auch hinsichtlich der Schlüsselkompetenzen.
Wir bedanken uns bei Claudia Walter (DiZ Bayern) für den Tipp, bei der Definition von Lernzielen Verben zu verwenden, die ein von außen wahrnehmbares Verhalten beschreiben, weil erst dadurch die definierten Lernziele auch wirklich testbar werden. Des Weiteren danken wir Ingrid Cavalieri (Coach am DiZ Bayern) für die kritische Durchsicht unserer Lernzieldefinitionen.
Das Autorenteam wurde gefördert durch das BMBF Förderkennzeichen 01PL11025 (Projekt "Für die Zukunft gerüstet"), im Programm "Qualitätspakt Lehre".
[Anderson u. a. 2001] ANDERSON, Lorin W. ; KRATHWOHL, David R. ; AIRASIAN, Peter W. ; CRUIKSHANK, Kathleen A. ; MAYER, Richard E. ; PINTRICH, Paul R. ; RATHS, James ; WITTROCK, Merlin C.: A Taxonomy for Learning, Teaching, and Assessing. A Revision of Bloom’s Taxonomy of Educational Objectives. 1. New York : Longman, 2001 [Bloom u. a. 1956] BLOOM, B. S. ; ENGELHART, M. B. ; FURST, E. J. ; HILL, W. H. ; KRATHWOHL, D. R.: Taxonomy of educational objectives: The classification of educational goals. New York : David McKay Company, 1956