 |
Modellbildung als zentrales Handlungsfeld in der Ausbildung
von IT-Berufen
|
1. Einleitung
Die erst 1997 durch eine Neuordnung der dualen Berufsausbildung
eingeführten IT-Berufe haben sich schon nach kurzer Zeit zu
einer bedeutsamen beruflichen Perspektive für junge Menschen
entwickelt. So findet sich in den Rahmenlehrplänen kaum ein
Lernfeld, in dem nicht die Fähigkeit zum Aufstellen und Ausgestalten
von Modellen einen bedeutenden Teil der beruflichen Handlungskompetenz
ausmacht. Der Umgang mit Modellen und die darauf bezogene Fähigkeit
zur Modellbildung stellen damit während der Ausbildung eine
zentrale Zielkategorie dieser Berufe dar. Als Methode zur Vermittlung
der Kompetenzen wird gemeinhin der projektorientierte Unterricht
bevorzugt, da Projekte auch große Teile des beruflichen Kontextes
der IT-Fachkräfte umfassen.
Der vorliegende Beitrag beginnt mit einer kurzen Beschreibung des
Ist-Zustandes der dualen Ausbildung in den IT-Berufen. Hierin kommen
die Defizite im didaktisch-methodischen Bereich zum Ausdruck. Insbesondere
fällt auf, dass der Einsatz von projektorientiertem Unterricht
weit hinter den in den Rahmenlehrplänen vorgesehenen Vorstellungen
zurückbleibt. Mögliche Gründe dafür werden diskutiert.
Problematisch scheint vor allem, dass zwar offensichtlich ist, dass
Prozesse der Modellbildung im projektorientierten Unterricht die
überwiegende Tätigkeit der Auszubildenden sind, der Modellbildung
in der didaktischen Diskussion allerdings noch zu wenig Beachtung
geschenkt wird. Anhand des Beispiels einer Anwendungsentwicklung
wird die Bedeutung der Modellbildung verdeutlicht.
2. Situationsbeschreibung im Bereich der IT-Ausbildung
Auch wenn die sehr hohen Erwartungen, die noch vor wenigen Jahren
bezüglich des Potenzials zur Schaffung neuer Arbeitsplätze
an die Informations- und Kommunikationsbranche gerichtet waren,
nicht erfüllt werden konnten, ist dies kaum ein Grund, die
Bedeutung der zu dieser Branche gehörenden Berufsbilder heute
zu unterschätzen. So machte allein der Sektor Information und
Kommunikationstechnik (IKT) immerhin 6,4 % des Bruttoinlandsproduktes
aus (BUNDESMINISTERIUM FÜR WIRTSCHAFT UND ARBEIT 2003). Nach
einer Schätzung des Institutes für Arbeitsmarkt- und Berufsforschung
waren im Jahre 2001 in Deutschland immerhin 600.000 Menschen in
Berufen der IKT beschäftigt. Darunter fallen immerhin 300.000
Absolventen einer auf IKT bezogenen beruflichen Bildung (INSTITUT
FÜR ARBEITSMARKT- UND BERUFSFORSCHUNG 2002). Dazu kommt noch
eine nicht ganz so leicht zu ermittelnde Anzahl von Menschen, die
zwar eine den IKT zurechenbare Tätigkeit ausüben, nicht
jedoch in einem Unternehmen der IKT-Branche beschäftigt ist.
Grobe Schätzungen gehen von ebenso vielen Beschäftigen
aus wie bereits in der IKT-Branche beschäftigt sind (MEYER
2003a). Sicher ist zudem, dass gerade in diesen Bereichen noch ein
erhebliches Zuwachspotential enthalten ist, da zwar Branchen wie
Banken und Versicherungen bereits seit langem über eine vergleichsweise
elaborierte IT-Infrastruktur verfügen, dies jedoch auf viele
andere Branchen, z. B. im Bereich der Automation oder der öffentlichen
Verwaltung (Stichwort: e-government) keineswegs zutrifft.
Ein Großteil der Tätigkeiten, die der IKT zuzurechnen
sind, wird auch zukünftig ohne ein spezifisches Hochschul-
oder Fachhochschulstudium ausgeübt werden. Als eine Art Königsweg
für die jetzigen Berufsstarter gilt, einen der 1997 eingeführten
IT-Berufe zu wählen. So wird in der Zeitschrift c't, einer
einschlägigen Fachzeitschrift der IKT-Branche mit umfangreichem
Stellenanzeigenteil, die Ausbildung von IT-Berufen als vorteilhaft
für die Unternehmen der Branche bezeichnet, da Absolventen
mit ähnlichen Kompetenzen aufwarten können, wie Fachhochschulabsolventen
(MEYER 2003b). Nach dem Abschluss der Berufsausbildung sind die
Auszubildenden dann aber bereits mit den Geschäftsprozessen
des Ausbildungsbetriebes vertraut und können ohne kostenintensive
Einarbeitungsphase direkt in die Leistungsprozesse eingegliedert
werden, sofern dies nicht bereits während des zweiten und dritten
Ausbildungsjahres der Fall war.
Damit sind die neuen IT-Berufe natürlich auch gegenüber
den vollzeitschulisch ausgebildeten Informatikassistenten oder Wirtschaftsassistenten
mit der Fachrichtung Informatik klar im Vorteil.
Auch die Aufstiegschancen sind für Auszubildende dieser Berufe
durchaus als sehr gut anzusehen. So hat das Bundesministerium für
Bildung und Forschung erst kürzlich eine Richtlinie herausgegeben,
die Weiterbildungs- und Qualifizierungswege bis hin zu Äquivalenten
der sonst nur an Hochschulen zu erwerbenden Bachelor und Masterabschlüsse
aufzeigt (BUNDESMINISTERIUM FÜR BILDUNG UND FORSCHUNG 2002).
Diese Perspektiven der Auszubildenden decken sich jedoch keineswegs
mit den Zahlen bzgl. der Auflösung von Ausbildungsverträgen
zwischen ausbildenden Betrieben und ihren Auszubildenden. Bei den
Informatikkaufleute wurden im Jahr 2001 immerhin 10,2 % der Ausbildungsverträge
wieder aufgehoben, bei den IT-Systemelektronikern 12,7 %, bei Fachinformatiker
14,2 % und bei den IT-Systemkaufleuten gar 22% (BUNDESINSTITUT FÜR
BERUFSBILDUNG o.J.).
Über die tatsächlichen Gründe können bisher
nur Vermutungen angestellt werden. Dass aber neben einer mangelnden
Eignung des Ausbildungsbetriebes oder des bzw. der Auszubildenden
weitere Gründe vorliegen, legt die vom Bundesinstitut für
Berufsbildung in Auftrag gegebene und vom Berufsbildungsinstitut
Arbeit und Technik (BIAT) durchgeführte Studie zur Einführung
der neue IT-Berufe zumindest sehr nahe. Darin geben zwar noch etwa
drei Viertel der IT-Auszubildenden an, dass die technische Hard-
und Softwareausstattung ihrer Berufsschule als mindestens befriedigend
bezeichnet werden kann, die Vermittlung der Unterrichtsinhalte bekommt
hingegen ausgesprochen schlechte Noten. So halten lediglich 10 %
der Auszubildenden einen lehrerzentrierten Frontalunterricht für
sehr geeignet. Diese Unterrichtsmethode kommt aber bei 75% der befragten
Auszubildenden häufig zum Einsatz. Demgegenüber steht
ein für die Ausbildung von IT-Fachkräften naheliegender
und von den Rahmenlehrplänen der IT-Berufe festgeschriebener
projektorientierter Unterricht nur bei 18% der Auszubildenden häufig
auf dem Stundenplan. 47% der Auszubildenden geben an, bisher nur
selten in den Genuss eines projektorientierten Unterrichts gekommen
zu sein und etwa 35% hatten bisher noch keinen solchen Unterricht
erlebt. Knapp 40% der Auszubildenden bewerten diese Unterrichtsmethode
hingegen als sehr geeignet. (PETERSEN, WEHMEYER 2001, 135ff.). Damit
ist die schlechte Einschätzung der Unterrichtsqualität
an den Berufsschulen durch die Auszubildenden durchaus nachvollziehbar.
Und daraus resultiert natürlich auch eine Unzufriedenheit der
Auszubildenden hinsichtlich der Vorbereitung auf die Zwischen- und
Abschlussprüfung sowie eine damit vermutlich einhergehende
Versagensangst. So geben erschreckende 70% der Auszubildenden an,
dass die Übereinstimmung der Ausbildungs- und Prüfungsinhalte
in der Zwischenprüfung zu gering ist. Dieses Ergebnis kann
nach der BIAT-Studie nicht auf das zu hohe Anspruchsniveau der Zwischenprüfung
zurückgeführt werden. Ähnliche Ergebnisse zeigen
sich auch in der Beurteilung der Abschlussprüfung inklusive
der betrieblichen Projektarbeit. Da die Abschlussprüfung von
den Auszubildenden mehrheitlich als praxisgerecht bewertet wird,
lässt dieses Ergebnis wiederum nur einen Rückschluss auf
die Beurteilung der Qualität der betrieblichen und schulischen
Ausbildung durch die Auszubildenden zu (PETERSEN, WEHMEYER 2001,
149ff.).
Woran liegt es nun, dass Anspruch und Wirklichkeit bezogen auf die
wahrgenommene Unterrichtsqualität so weit auseinander liegen
soll im folgenden Abschnitt betrachtet werden.
3. Projektorientierter Unterricht - Anspruch und Wirklichkeit
in der Ausbildung von IT-Berufen
Gründe die dafür sprechen, projektorientierten Unterricht
gegenüber anderen Methoden zu bevorzugen gibt es viele. Zunächst
einmal findet sich schon in den Rahmenlehrplänen der ausdrückliche
Hinweis darauf, dass eine Vermittlung lernfeldübergreifend
erfolgen soll (KULTUSMINISTERKONFERENZ 1997, 6). Dieses Ziel kann
insbesondere durch projektorientierten Unterricht erreicht werden,
da Projekte alle möglichen Stoffgebiete "wie ein Magnet,
um sie zu sammeln" pflegen (DEWEY 1935, 97).
Daneben gibt es allerdings auch Gründe, die nicht lediglich
formaler Natur sind. Zunächst sind auch annähernd alle
beruflichen Tätigkeiten zumindest in der ersten Phase einer
Karriere in einem IT-Beruf in Projekten organisiert. So sagt PFISTERER,
Bildungs- und Personalreferent im Bundesverband Informationswirtschaft.
Telekommunikation und neue Medien e. V. (Bitkorn): "Mindestens
90 Prozent der Informatiker haben einen ganz praktischen Karriereweg:
Projekte managen, Produkte verkaufen, Personal führen"
(zit. nach MEYER 2003a, 169).
Aber noch ein weiteres nicht unerhebliches Argument muss hier angeführt
werden. Die praxisbezogene Projektarbeit, die jeder Auszubildende
für seine Abschlussprüfung anzufertigen hat, geht immerhin
zu 50% in die Gesamtnote der Abschlussprüfung ein.
Daneben stehen für den projektorientierten Unterricht natürlich
auch all die Vorzüge, die insgesamt dem handlungsorientierten
Unterricht beigemessen werden. (vgl. z. B. AEBLI 1980; AEBLI 1981;
GUDJONS 1997).
Dass vor diesem Hintergrund nicht schon jetzt der gesamte Unterricht
an der Berufsschule in Form von Projekten unterrichtet wird, hängt
mit organisatorischen wie didaktischen Überlegungen zusammen.
Die Gründe dafür sollen hier kurz dargestellt werden.
In den Rahmenrichtlinien für die IT-Berufe findet sich trotz
des klaren Hinweises auf einen lernfeldübergreifenden Unterricht
eine Systematik wieder, die unterrichtsorganisatorisch dazu führt,
dass einzelne Lernfelder zum Teil auch einzeln und von verschiedenen
Lehrkräften unterrichtet werden können. Das führt
dann aber unvermeidlich zu einer zeitlichen Parallelität der
Vermittlung von Unterrichtsinhalten, die in Projekten unabhängig
vom herangezogenen Vorgehensmodell eine zeitliche Abfolge bilden
müssten. Ein lernfeldübergreifendes Projekt, wie es typischerweise
die berufliche Praxis der IT-Berufe kennzeichnet, kann somit schon
durch organisatorische Barrieren bzw. einer Fehlinterpretation des
Lernfeldgedankens unmöglich werden.
Dem konsequent projektorientierten Unterricht steht aber auch die
didaktische Fehlüberzeugung gegenüber, nach der es Unterrichtsinhalte
gibt, die eben nicht projekt- und/oder handlungsorientiert unterrichtet
werden können. Dagegen spricht aber wiederum die Intention
der Rahmenlehrpläne. Darin ist das Ziel einer konsequenten
Ausrichtung des Unterrichts an beruflichen Handlungssituationen
explizit vorgegeben (KULTUSMINISTERKONFERENZ 1997, 4ff.). Diese
Vorgabe schließt die Möglichkeit der Existenz von Unterrichtsinhalten,
die sich beruflichen Handlungen entziehen, damit aus.
Gegen projektorientierten Unterricht könnte man auch anführen,
dass häufig nicht genügend Unterrichtszeit zur Verfügung
steht, alle verbindlichen Unterrichtsinhalte handlungsorientiert
zu vermitteln. Auch wenn Deweys Aussage, dass "ein Gramm Erfahrung
[…] besser sei, als eine Tonne Theorie" (zit. nach GUDJONS
1997, 73) außer acht lässt, dass es in unserer Gesellschaft
ohne jedwede theoretische Grundlage kaum mehr möglich ist,
Erfahrungen zu sammeln, ist der Aufbau von theoretischem Wissen
ohne konkrete Erfahrungen und mithin isoliert vom Anwendungskontext
ebenfalls weitestgehend nutzlos (siehe dazu Abschnitt 4).
Letztendlich spielt auch die Zeit für die Unterrichtsvorbereitung
eine nicht unbedeutende Rolle. Dagegen kann man allerdings anführen,
dass eine Vielzahl von zum Teil sehr guten Materialien für
projektorientierten Unterricht bereits bei Verlagen und vor allem
im Internet zu finden sind und es mittlerweile auch Websites gibt,
die sich dem Austausch von Lehrmaterialien widmen.
Die zuvor genannten Probleme sind also lösbar. Dass nicht mehr
projektorientierter Unterricht an den Berufsschulen durchgeführt
wird, hängt möglicherweise eher mit spezifischen Besonderheiten
von IT-Projekten zusammen. IT-Projekte eröffnen sehr viele
Wege, ein gegebenes Projektziel zu erreichen. Das Projektziel selbst
ist aber hinsichtlich seines Zielerreichungsgrades sehr gut messbar
und bestraft jeden kleinsten Fehler, der während der Modellierungsphase
des Projektes begangen wurde. Und gerade diesem Aspekt der Modellierungsprozesse
selbst wurde in der didaktischen Diskussion der beruflichen Informatik
bisher kaum Aufmerksamkeit geschenkt. Welche Modellierungen sind
es aber, die für ein typisches IT-Projekt auch im Berufsschulunterricht
erforderlich sind und wie werden diese eingeführt? Dieser Frage
soll sich im nun folgenden Abschnitt von den Qualifikations- und
Bildungsziele eines IT-Berufes ausgehend, angenähert werden.
4. Bedeutung der Modellbildung für die IT-Berufe
Für die Betrachtung soll das Beispiel eines IT-Berufes aufgegriffen
werden. Die Argumentation kann aber auf alle weiteren IT-Berufe
problemlos über tragen werden. Die Qualifikations- und Bildungsziele
eines Fachinformatikers bzw. einer Fachinformatikerin mit der Fachrichtung
Anwendungsentwicklung finden sich in der rechten Spalte der Tabelle
1. In der linken Spalte werden diese den Beschreibungstechniken,
Notationen und Sprachen gegenübergestellt, die zur Erreichung
der Ziele in der IT typischerweise zum Einsatz kommen.
Tabelle 1: Gegenüberstellung der Qualifikations- und Bildungsziele
und der zu deren Erreichung zum Einsatz kommenden Werkzeuge
Die Vermittlung der Fähigkeit Modelle aufzustellen, wird schon
im allgemeinbildenden Informatikunterricht als eigentliche Hauptaufgabe
bezeichnet (HUBWIESER 1999; HUBWIESER 2000; SCHULTE 2001). Dies
gilt um so mehr für berufsbildenden Informatikunterricht, da
hier ein noch stärkeres Gewicht auf die Entwicklung konkreter
Produkte mit einem praktischen Nutzen hingearbeitet wird.
Wie sollte nun das Vorgehen aussehen, mit dem die entsprechenden
Lehr-Lern-Ziele erreicht werden. Dazu bietet sich m. E. ausschließlich
die Realisation eines Projektes an, wobei sich der Projektablauf
an einem informatischen Projektablauf orientiert (siehe Abb. 1).
Ablauf zur Realisation eines Projektes im Informatikunterricht
(SCHWILL 1998, 21)
In einem solchen Projektablauf zur Entwicklung oder Verbesserung
eines IT-Systems, sind die einzelnen Handlungen, die die IT-Auszubildenden
auszuführen haben, zum allergrößten Teil Handlungen,
die sich auf eine Modellbildung beziehen. Anhand der einzelnen Schritt
des IT-Projektes soll nun darauf eingegangen werden, welche Modellbildungen
bzw. Rückgriffe auf diese darin enthalten sind.
1. Problemkollektion und Problem
Projekte zielen immer darauf ab, ein tatsächliches oder zumindest
realistisches Problem zu lösen. Dieses sollte zumindest zwei
der von Gudjons geäußerten Merkmale von Projekten erfüllen,
nämlich zum einen die fachlichen Aspekte, die es zu vermitteln
gilt, abdecken und zum anderen sich an den Interessen der Beteiligten
orientieren (GUDJONS 1997, 74f.). Ob das Problem nun vorgegeben
ist oder durch die Beteiligten selbst definiert wird, ist dabei
nur aus einer motivationalen Perspektive heraus von Bedeutung.
2. Anforderungsdefinition
Nach der Definition eines Problems oder einer Entscheidung für
ein solches, muss eine Problemanalyse durchgeführt werden.
Diese besteht, wie in der IT üblich, aus einer Beschreibung
des Ist-Zustandes an dem erkannt werden kann, wo die tatsächlichen
Probleme liegen. Daraus kann dann ein Soll-Zustand abgeleitet
werden. Dieser beschreibt, was nach der Bearbeitung und Lösung
des Problems erreicht werden soll. Nun ist es ein typisches Merkmal
für IT-Projekte, dass solche Zustände in Form von Geschäftsprozesse
modelliert werden (DEITERS 1997). Eine Anforderungsdefinition
für ein IT-Projekt ist damit letztendlich die Differenz zwischen
dem Ist- und dem Sollzustand und wird somit ebenfalls modellhaft
abgebildet (SCHEFE 1999, 132f.).
3. Spezifikation
In der Entwurfsphase erfolgen nun detailliertere Spezifikationen
zu den einzelnen Elementen, deren Ausgestaltung zur Lösung
des Problems beitragen. Unabhängig davon, welches Vorgehen
dabei gewählt wird und welche Techniken dabei zu Einsatz
kommen sollen, handelt es sich dabei immer im die Modellierung
von Komponenten eines IT-Systems. Geht man z. B. funktionsorientiert
vor, so werden zunächst Abläufe ggf. bis hin zu einzelnen
Algorithmen modelliert und in einer geeigneten zumeist graphischen
Sprache dargestellt. Darauf aufbauend können die Datenstrukturen
modelliert werden, die für den funktionalen Ablauf erforderlich
sind. Für ein objektorientertes Vorgehen ist es hingegen
erforderlich, Klassen zu bilden, in denen Methoden und Daten zusammengezogen
sind. Nicht umsonst spricht man aber bei dem Ergebnis dieser Tätigkeit
von einem Objektmodell. Diese Beispiele könnten beliebig
fortgesetzt werden. Ergebnis dieser Phase ist eine Spezifikation
des zu entwickelnden IT-Systems.
4. Programm
Der Übergang zu der Implementierung des Programms ist nun
fließend, da je nach herangezogener Modellierung die Implementation
bereits ein Bestandteil des Modellierungsvorganges ist. So ist
bei einem objektorientierten Vorgehen durch die Beschreibung der
Klassen bereits der größte Teil der Implementation
getan (QUIBELDEY-CIRKEL 1999, 47; SCHULTE 2001, 10) und lediglich
das Codieren ist noch erforderlich. Ergebnis ist ein nun ein dokumentiertes
IT-System, wobei die Dokumentation selbst zumeist aus den zuvor
erstellen Modellen zuzüglich einiger verbaler Erläuterungen
besteht.
5. Modifikation
Nun können Iterationsschritte erforderlich sein, da durch
eine Funktions- und Leistungsüberprüfung sowohl Änderungen
am Code, als auch, und das ist wahrscheinlicher, an den zuvor
erstellten Modellen erforderlich sind.
6. Eine Bewertung der Projektergebnisse schließt die Projektarbeit
ab.
Nun bleibt die Frage nach dem Verhältnis von Theorie und
Praxis. Eine sehr allgemeine gehaltene Aussage, die sich auf den
Unterricht mit Projekten bezieht, findet sich bei Kath. Er schreibt,
dass Theorie aus der Praxis heraus gewonnen wird, da eben nicht
von fertigen Ergebnissen ausgegangen werden kann, sondern sich
diese erst aus dem praktischen Handeln heraus ergeben (KATH ,
135). Trotzdem ist es erforderlich, dass die praktischen Erfahrungen
und gewonnenen Erkenntnisse systematisiert und in den gegebenen
Wissensstand einer Kultur eingeordnet werden (GUDJONS 1997, 83).
Dies kann nach grundsätzlich zu drei verschiedenen Zeitpunkten
erfolgen.
Der früheste Zeitpunkt für die Einführung der Fachsystematik
ist, diese vor der Realisation des Projektes zu behandeln. Die Schüler
können dann im Projektverlauf auf ein fachsystematisches Fundament
aufbauen. Die Motivation der Auszubildenden wird dabei allerdings
außer Acht gelassen. Es handelt sich in deren Wahrnehmung
wiederum um den so schlecht bewerteten lehrerzentrierten Unterricht.
Auch wird den Auszubildenden dabei die Möglichkeit genommen,
ihr Vorwissen einzubringen und darüber Verbindungen zu neuen
Unterrichtsinhalten aufzubauen.
Der zweite mögliche Zeitpunkt ist während des Projektunterrichts,
in den gezielte Instruktionsphasen integriert werden. So können
gezielt Wissensdefizite ausgeglichen werden. Zudem hat die Theorie
damit einen direkten Bezug zur (Projekt-)Wirklichkeit bzw. kann
für die Schüler einen Beitrag zur Lösung des Projektproblems
darstellen. Allerdings wird durch diese ‚Einmischung' ebenfalls
der Drang der Schüler gestört, das Problem mit eigenen
Mitteln zu lösen (GUDJONS 1997, 85)
Zu guter Letzt kann einen Systematisierung und theoretische Fundierung
auch nach der Durchführung des Projektes erfolgen. Zumindest
für den IT-Unterricht verbietet sich allerdings ein solches
Vorgehen zumeist, da eben die fachlichen Inhalte die Werkzeuge zur
Lösung der Problemstellung bereithalten und kaum davon ausgegangen
werden kann, dass ein Schüler aus sich heraus diese Werkzeuge
erneut erfindet.
5. Ausblick
Es konnte anhand von typischen Lernhandlungen von IT-Auszubildenden
gezeigt werden, dass das Aufstellen von und das Arbeiten mit Modellen
in allen Bereichen der IT-Ausbildung eine bedeutsame, wenn nicht
die bedeutsamste Rolle spielt. Damit stellt sich natürlich
die Frage, warum in der didaktischen Diskussion nicht bedeutend
ausführlicher auf Aspekte des Aufstellens und des Umgangs mit
Modellen eingegangen wird. Vielleicht ist dies der Fall, weil erst
bei der Realisation von Projektes deutlich wird, dass ohne das Bilden
von Modellen kaum ein Projektziel erreicht werden kann.
Für den Unterricht von IT-Auszubildenden ist daher zu wünschen,
dass bedeutend häufiger als es derzeit der Fall ist, nicht
lediglich isolierte Fachinhalte unterrichtet werden, sondern durch
projektorientierten Unterricht regelmäßig in Handlungskontexte
eingebunden werden. Dabei ist der typische Handlungskontext der
IT-Berufe die Projektarbeit.
Literatur:
AEBLI, H. (1980). Kognitive Aspekte der Handlungstheorie. Stuttgart:
Klett-Cotta.
AEBLI, H. (1981). Denkprozesse. Stuttgart: Klett-Cotta.
BECK, K. (1999). Embracing change with Extreme Programming. Computer,
32 (10), 70-77.
BOEHM, B. (1988). A Spiral Model of Software Development and Enhancement.
Computer (5), 61-72.
BUNDESINSTITUT FÜR BERUFSBILDUNG (o.J.). Aus- und Weiterbildungsstatistik.
Online im WWW: http://www.bibb.de/de/781.htm
(rev. 15.9.2003).
BUNDESMINISTERIUM FÜR BILDUNG UND FORSCHUNG (BMBF) (2002).
IT-Weiterbildung mitSystem, Neue Perspektiven für Fachkräfte
und Unternehmen. Online im WWW: http://www.bmbf.de/pub/it-weiterbildung_mit_system.pdf
(rev. 15.9.2003).
BUNDESMINISTERIUM FÜR WIRTSCHAFT UND ARBEIT (2003). Branchenfocus
- Informationswirtschaft. Online im WWW: http://www.bmwi.de/Navigation/Wirtschaft/Branchenfocus/informationswirtschaft.html
(rev. 15.9.2003).
DEITERS, W. (1997). Prozeßmodelle als Grundlage für
ein systematisches Management von Geschäftsprozessen. Informatik
Forschung und Entwicklung (12), 52-60.
DEWEY, J. (1935). Der Ausweg aus dem pädagogischen Wirrwarr.
In J. DEWEYW. H. KILPATRICK (Hrsg.), Der Projekt-Plan. Grundlegung
und Praxis. (S. 85-101). Weimar.
GILB, T. (1988). Principles of Software Engineering Management.
Wokingham, UK: Addison-Wesley.
GUDJONS, H. (1997). Handlungsorientiert lehren und lernen. Schüleraktivität
- Selbständigkeit - Projektarbeit. Bad Heilbrunn/Obb.: Klinkhardt.
HUBWIESER, P. (1999). Modellieren in der Schulinformatik. Log In,
19 (1), 24-29.
HUBWIESER, P. (2000). Didaktik der Informatik. Grundlagen, Konzepte,
Beispiele. Berlin: Springer.
INSTITUT FÜR ARBEITSMARKT- UND BERUFSFORSCHUNG (2002). IT-Arbeitsmarkt,
Chancen am Ende des Booms. IAB Kurzbericht, Aktuelle Analysen aus
dem Institut für Arbeitsmarkt- und Berufsforschung der Bundesanstalt
für Arbeit(19), 1.
JACOBSEN, I. (1994). Object-Oriented Software Engineering. Wokingham,
UK: Addison-Wesley.
KATH, F. M. (2002): Das "Arbeiten mit Projekten" lädt
zum Arbeiten in "Lernfeldern" ein. In R. DREHER/G. SPÖTTL
(Hrsg.), Arbeiten mit Projekten - Ein Ansatz für mehr Selbständigkeit
beim Lernen. Bremen: Donat, 130-139.
KULTUSMINISTERKONFERENZ (1997). Rahmenlehrplan für den Ausbildungsberuf
Fachinformatiker/Fachinformatikerin (Beschluß der Kultusministerkonferenz
vom 25. April 1997). Online im WWW: http://berufliche.bildung.hessen.de/p-rahmenplaene-kmk/fachinformatiker.pdf
.
MEYER, A. (2003a). IT-Karriere? - Ja, aber richtig! c't (5), 168-169.
MEYER, A. (2003b). Mitten hinein - Betriebliche und schulische
IT-Ausbildung. c't (5), 170-172.
PETERSEN, W. A./WEHMEYER, C. (2001). Die neuen IT-Berufe auf dem
Prüfstand. Vorabdruck. Online im WWW: http://www.biat.uni-flensburg.de/bibb-it/Teilprojekt-1/Teilprojekt-1-Ergebnisse-Zusammenfassung/Absch
(rev. 15.9.2003).
QUIBELDEY-CIRKEL, K. (1999). Entwurfsmuster: Design Patterns in
der objektorientierten Softwaretechnik. Heidelberg u. a.: Springer-Verlag.
SCHEER, A. (1997). ARIS Toolset 3.2.. Saarbrücken: IDS Prof.
Scheer.
SCHEER, A. (1998). Architektur integrierter Informationssysteme.
Grundlagen der Unternehmensmodellierung. 3. Aufl. Berlin, Heidelberg,
New York: Springer.
SCHEFE, P. (1999). Softwaretechnik und Erkenntnistheorie. Informatik
Spektrum (22), 122-135.
SCHULTE, C. (2001). Vom Modellieren zum Gestalten - Objektorientierung
als Impuls für einen neuen Informatikunterricht?. informatica
didactica (3).
SCHWILL, A. (1998). Projektunterricht - Grundlagen und Beispiele.
Online im WWW: http://ddi.cs.uni-potsdam.de/HyFISCH/Arbeitsgruppen/PLIB/Projektarbeit-Modul4/VortragsfolienProjektun
(rev. 15.9.2003).
|
