Modellbildung als zentrales Handlungsfeld in der Ausbildung von IT-Berufen

download pdf-file (52kb), Druckversion

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).