Kurs:Fachdidaktik Informatik/Projektarbeit/Softwareprojekte als spezifische Form des Projekts im Informatikunterricht

Aus Wikiversity

Ein Softwareprojekt ist die einmalige, zeitlich begrenzte Arbeit an der Lösung eines komplexen informatikbezogenen Problems (Humbert, 2005; LFPS). Die, in der freien Wirtschaft von professionellen Programmierern, erstellten Softwarelösungen sind in der Regel vielschichtig, kompliziert und zeitaufwendig. Da es im Informatikunterricht jedoch erfahrungsgemäß an Zeit mangelt, um komplexe, realitätsnahe Problemstellungen zu bearbeiten, werden diese häufig für den Schuleinsatz reduziert. Dabei entsteht jedoch die Gefahr, dass zentrale informationstechnische Vorgehensweisen ausgelassen werden. Hier empfiehlt es sich, auf die Projektmethode zurückzugreifen. Diese bietet die Möglichkeit den Schülerinnen und Schülern dennoch wesentliche Phasen und Betrachtungsweisen eines klassischen Softwareprojekts greifbar zu machen. (Hartmann, Näf & Reichert, 2006)

Begründung: Das Softwareprojekt im Informatikunterricht[Bearbeiten]

Bundesweit wird in allen Curricula auf ein projektorientiertes Lernen im Informatikunterricht verwiesen (Humbert 2005, Opel 2002). So wird beispielsweise laut Opel (2002) in den niedersächsischen Rahmenrichtlinien vorgeschlagen:

Um praxisorientierte Problemstellungen zu bearbeiten und den prinzipiellen Ablauf der Erstellung von Software-Lösungen kennen zu lernen, bietet es sich an, ein Projekt durchzuführen. Es ergeben sich dabei Möglichkeiten, gesellschaftliche Auswirkungen der Verarbeitung von Daten und von Informatikmethoden zu erfahren.“:

Schubert und Schwill (2004) vertreten die Ansicht, dass projektorientierte Vorgehensweisen in der Informatik, im Gegensatz zu manch anderen Fachbereichen, eine Wissenschaftsmethode darstellen. Kommt die Projektmethode im Informatikunterricht zum Einsatz, so wird nicht lediglich eine Unterrichtsmethode angewandt, sondern zugleich eine Wissenschaftsmethode gelehrt. Somit nimmt die Projektmethode im Informatikunterricht eine besondere Stellung ein.

Auch Hartmann, Näf und Reichert (2006) zufolge sollten informationstechnische Arbeitsweisen, wie Software Engineering, Projektmanagement und Modellierung im Projektunterricht zum Einsatz kommen. Dadurch entsteht die Möglichkeit, Schülerinnen und Schülern die Problematik von komplexen Systemen aufzuzeigen und die Vorteile objektorientierter Programmstrukturen deutlich zu machen. Probleme, wie sie in der Softwareentwicklung vorkommen, werden offen gelegt und bewältigt.

Das pädagogische und das informatische Verständnis eines Projekts können laut Schubert und Schwill (2004) allerdings nicht ohne Weiteres verbunden werden, da diese Diskrepanzen mit sich bringen. Projektarbeit in der Informationstechnik, wie sie in der kapitalistischen Wirtschaft vorkommt, ist dazu vorgesehen die Produktivität, und somit die Leistung, zu steigern. Projektarbeit in der Pädagogik hingegen hat das Ziel eines sozialen Lernens, was in starkem Wiederspruch zu kommerziellem Leistungsdruck steht.

Bezüglich der Übertragung eines leistungsorientierten Informatikprojektes auf ein im Unterricht stattfindendes pädagogisches Projekt ist Wolfgang Ambros folgender Meinung:

Es ist geradezu absurd, unter Berufung auf das pädagogische Projekt der Arbeitsschule [...] einen Berufszweig zu nehmen, zu dessen Wesen knallharte Konkurrenz, Kalkulation und Leistungsausbeutung gehört. Soziale und selbstbestimmende Lernkomponenten in der pädagogischen Schutzhütte und industrielle Effektivität in der Wettbewerbssituation sind unvereinbar wie Feuer und Wasser.“ (Bosler & Ziebarth, 1992)

Jedoch nennt Wolfgang Ambros (1992) auch mehrere Argumente, die für die Behandlung und Anwendung von informationstechnischen Vorgehensweisen im Unterricht sprechen, wie beispielsweise, dass die Softwaretechnologie „auf unumkehrbare Weise das Funktionieren einer industrialisierten Gesellschaft“ prägt und die „Zukunftsperspektiven der heutigen Schülergeneration“ gestaltet. Das Aufzeigen der Bedeutung von Phasenschema, Dokumentation und Teamarbeit sind für ihn dabei zentral.

Es stellt sich demnach nicht die Frage, ob Softwareprojekte im Informatikunterricht durchgeführt werden sollten, sondern wie.

In der Softwareentwicklung[Bearbeiten]

In der Informatik erfolgt die Erstellung von Software-Lösungen in Etappen, was eine bessere Planung, Entwicklung und Kontrolle gewährleisten soll. Der Vorgang der Softwareerstellung wird hierzu strukturiert und in einzelne Phasen gegliedert. Die Gesamtheit an Phasen wird als Software Life Cycle, bzw. Softwarelebenszyklus bezeichnet (Apke & Dittmann, 2003; Brockhaus, 2007). Bezüglich des genauen Ablaufs werden aus diesem verschiedene Vorgehensmodelle abgeleitet, wobei einige Modelle Rücksprünge zulassen, so dass die einzelnen Phasen nicht streng aufeinander folgen müssen. Alle Vorgehensmodelle setzen sich aus den vier wesentlichen Prozessphasen Problemanalyse, Entwurf, Implementierung und Test/Installation zusammen (Apke & Dittmann, 2003; Brockhaus, 2007; Schubert & Schwill, 2004; Jähnichen, Koch & Schürmann, 1983).

Projektphasen in der Softwareentwicklung[Bearbeiten]

Am Anfang steht ein Problem, das softwaretechnisch gelöst werden soll.

Problemanalyse[Bearbeiten]

Abbildung 1: Phasen eines Software Life Cycle (vgl. Schubert & Schwill, 2004)
  • Tätigkeit: Im Laufe dieser ersten Phase werden eine Istanalyse, Sollkonzeptentwicklung, Durchführbarkeitsstudie und Projektplanung erstellt (Spolwig, 2006; Schubert & Schwill, 2004). Der Istzustand des Problems und der Zusammenhang, in dem es steht, werden hierzu zunächst genauestens analysiert. Danach wird festgehalten, welche Lösungsansätze das zukünftige Softwaresystem liefern soll (Jähnichen et al., 1983). Bezüglich der Durchführbarkeit wird überprüft, inwiefern eine Softwarelösung erreicht werden kann, die wirtschaftlich ist und den Kunden zufrieden stellt. Zuletzt wird das weitere Vorgehen im Groben geplant, sowie personelle und finanzielle Ressourcen verteilt (Schubert & Schwill, 2004).
  • Ergebnis: Das Ergebnis der Problemanalyse ist die, für den Benutzer verständlich formulierte, Anforderungsdefinition (Jähnichen et al., 1983; Schubert & Schwill, 2004). Diese Anforderungdefinition dient dem Kunden als Grundlage für seine Forderungen dem Softwarehersteller gegenüber. Dem Softwarelieferant ist diese Definition, der verbindlich zu liefernden Lösung, jedoch ebenfalls dienlich. Die Analyse der Anforderungen bildet eine erste Strukturierung der Beschaffenheit des Problems und des zu erstellenden Systems. Die einzelnen Module des Systems und deren Beziehungen werden somit erkennbar. (Schubert & Schwill, 2004; Schwill)

Entwurf[Bearbeiten]

  • Tätigkeit: Nach Jähnichen, Koch und Schürmann (1983), ebenso wie nach Schubert und Schwill (2004) wird in dieser zweiten Phase nun die genaue Vorgehensweise in Bezug auf die programmiertechnische Umsetzung spezifiziert. Diesbezüglich wird eine Übersicht über die Zusammenhänge einzelner Komponenten im zu erstellenden Lösungssystem erarbeitet. Diese Komponenten werden als Module, der Vorgang der Unterteilung in vernetzte Komponenten als Modularisierung bezeichnet. Die Funktionen der einzelnen Module sollten weitestgehend nur von einem Modul genutzt werden und von diesem geheim gehalten bleiben. Bezüglich der Modulintegration ist gewünscht, dass die Schnittstellen zwischen den Modulen möglichst gering sind. Die Schnittstellen, die sich jedoch nicht vermeiden lassen, müssen zueinander passen.
  • Ergebnis: Das Ergebnis der Entwurfsphase ist die, für die Programmierer verfasste, Spezifikation (Spolwig, 2006). In dieser werden, gemäß Jähnichen, Koch und Schürmann (1983), die Zusammenhänge der Module festgehalten, sowie für alle Module die jeweilige Teilaufgabe, deren Auswirkungen und die Schnittstellen zu anderen Modulen. Die Spezifikation sollte sprachlich so verfasst sein, dass sie für jeden firmenintern Beteiligten noch relativ leicht verständlich ist und die Systementwickler ihre zukünftige, programmiertechnische Arbeit darauf aufbauen können. Programmcode ist jedoch noch kein Bestandteil der Spezifikation.

Implementierung[Bearbeiten]

  • Tätigkeit: In der Phase der Implementierung werden nun die, in den vorherigen Phasen bereits herausgearbeiteten einzelnen Module und die Programmarchitektur, von den Programmierern realisiert. Zunächst wird eine einheitliche Programmiersprache gewählt (Schubert & Schwill, 2004). Anschließend werden die Module erstellt, indem sie jeweils von Programmierer-Teams in Quelltext umgesetzt werden (Jähnichen et al., 1983; Wolf). Laut Jähnichen, Koch und Schürmann (1983), sowie nach Wolf werden in dieser Phase bereits Modultests durchgeführt, um schon vor der Modulintegration sicherzustellen, dass jedes Modul seine Aufgaben fehlerfrei erledigt.
  • Ergebnis: Das Ergebnis der Implementierungsphase ist der dokumentierte Programmcode der einzelnen Module, die jedoch am Ende dieser Phase in der Regel noch nicht zusammengefügt sind (Schubert & Schwill, 2004; Wolf).

Test und Installation[Bearbeiten]

  • Tätigkeit: In dieser Phase findet nun die Modulintegration statt. Die einzelnen Module werden nach und nach zusammengefügt, so dass das Programm stetig wächst, bis letztendlich das funktionsfähige, fertige Programm entstanden ist (Jähnichen et al., 1983; Wolf). Während dieser Zeit finden stets Integrationstests statt, in denen das Programm mittels bestimmter Testfälle auf Fehler überprüft wird (Jähnichen et al., 1983). Die betroffenen Programmteile werden dementsprechend modifiziert und verbessert. Schubert und Schwill (2004) zufolge wird, im Anschluss an die Überprüfung der generellen Lauffähigkeit des fertigen Programmes, dessen Leistung, bezüglich der Komplexität überprüft. Die Installation des auslieferungsfähigen Produktes beim Kunden bildet den Abschluss dieser Phase.
  • Ergebnis: Das Ergebnis der Test- und Installationsphase ist das modifizierte Programm gemäß den Anforderungen des Kunden. Häufig werden darauf folgend auch weiterhin noch Wartungsarbeiten durch den Systementwickler durchgeführt (Schubert & Schwill, 2004).

Teamstruktur in der Softwareentwicklung[Bearbeiten]

Für ein reibungsfreies und effizientes Arbeiten in der freien Wirtschaft ist die Organisation der personellen Ressourcen von zentraler Bedeutung. Bei Projekten im Bereich der Softwareentwicklung kommen dazu häufig die demokratische Teamstruktur, die hierarchische Teamstruktur oder das Chefprogrammiererteam zum Einsatz (Zimmermann, 2004). Insbesondere die hierarchische Organisationsform, die wenig Kommunikation erfordert, und das Chefprogrammiererteam, bei dem die Verantwortung und Entscheidungsbefugnis bei einer einzelnen Person liegt, sind jedoch für ein Projekt im pädagogischen Sinne nicht geeignet (Schubert & Schwill, 2004; Zimmermann, 2004).

Projektunterricht im schulischen Umfeld hat das Ziel Sozialkompetenzen wie Kommunikations-, Kooperations-, Konflikt- und Teamfähigkeit zu fördern. Würden die oben genannten Teamstrukturen zum Einsatz kommen, so wären laut Schubert und Schwill (2004) hierarchische Beziehungen zwischen den Schülerinnen und Schülern und Spezialistentum die Folge.

Anpassung an den Informatikunterricht[Bearbeiten]

Um Schülerinnen und Schülern die üblichen Verfahren bei der Softwareentwicklung näher zu bringen, erscheint es auf den ersten Blick recht naheliegend, hierfür einfach die pädagogische Unterrichtsmethode der Projektarbeit zu nutzen. Koerber (1992) zufolge, bietet dies viele Vorteile. So wird beispielsweise der Software Life Cycle als Vorgehensweise nicht lediglich gelehrt, sondern entspricht ebenso der Arbeitsmethode, wobei die Schülerinnen und Schüler selbst Erfahrungen über die Vorzügen der Vorgehensmodelle und der Modularisierung sammeln können.

Bei dem Durchführen eines Softwareprojekts im Unterricht sind jedoch nach Hartmann, Näf und Reichert (2006) auch die pädagogischen Ziele der Projektmethode zu berücksichtigen. Von zentraler Bedeutung sind hierbei nicht leistungsmaximierende und problemvermeidende Arbeitsabläufe, sondern Personalkompetenzen und Handlungskompetenzen der Schülerinnen und Schüler, die größtenteils durch das Bewältigen von Problemsituationen gestärkt werden. Die Auswahl des Projektthemas wird in einem Entscheidungsfindungsprozess von den Schülerinnen und Schülern selbst getroffen, da es keinen auftraggebenden Kunden gibt. Um die Sozialkompetenzen der Schülerinnen und Schüler zu fördern ist es wichtig hierarchische Teamstrukturen, wie sie in der Softwareentwicklung üblich sind, zu vermeiden und demokratische Teamstrukturen zu stärken. Entsprechend den pädagogischen Zielen müssen die Projektphasen in der Softwareentwicklung kritisch betrachtet und im Informatikunterricht gestaltet werden.

In den baden-württembergischen Bildungsstandards für Informatik heißt es:

Größere Projekte lassen sich am besten in Teamarbeit und nach präziser Planung bewältigen. Erst die genaue Vereinbarung von Schnittstellen ermöglicht verteiltes Arbeiten an einer gemeinsamen Aufgabe. Die im Informatikunterricht erworbenen Problemlösefähigkeiten sind in vielen anderen Lebensbereichen anwendbar. Informatikunterricht fördert die Bereitschaft und Fähigkeit, sich einer Aufgabe zu stellen, die längeres konzentriertes und selbstorganisiertes Arbeiten erfordert. Selbst entwickelte Lösungsansätze können unmittelbar am Rechner kontrolliert und überprüft werden.“ (MKJS, 2004)

Ziele des projektorientierten Informatikunterrichts[Bearbeiten]

Das Ziel eines Softwareprojekts im Informatikunterricht ist allgemein betrachtet nicht die Erstellung eines gewinnbringenden Produktes, sondern der Kompetenzzuwachs der Schülerinnen und Schüler. Koerber (1992) hat in dieser Hinsicht die Ziele des projektorientierten Informatikunterrichts zusammengefasst, die weit über den reinen Wissenserwerb hinausgehen. Diese Ziele hat er übersichtlich in vier Bereiche eingeteilt: allgemeine und soziale Ziele, Erlangen von Planungskompetenz, auf die DV-Anwendung bezogene Ziele und auf die Softwareerstellung bezogene Ziele.

Abbildung 2: Ziele des projektorientierten Informatikunterrichts

Kriterien für die Auswahl von Themen[Bearbeiten]

Am Anfang einer jeden Projektarbeit steht zunächst die Projektinitiative, wobei sich die Beteiligten auf ein Projektthema einigen müssen. Unumstritten ist, dass die Fragestellung, im Hinblick auf die zu entwickelnde Softwarelösung, von der Schülerseite aus weitestgehend selbst festzulegen ist. Was das Ausmaß betrifft, in dem sich die Lehrperson an dem Prozess der Themenfindung beteiligen sollte, gibt es jedoch unterschiedliche Meinungen.

Nach Ansichten von Hartmann, Näf und Reichert (2006) sollten Projektthemen stets durch die Schülerinnen und Schüler und nicht durch die Lehrperson initiiert werden, da auf diesem Wege ein Optimum an Lebensweltbezug der Fragestellung und Motivation der Schülerinnen und Schüler erreicht werden. So ist es möglich, dass durch Enthusiasmus der Schülerinnen und Schüler eine treibende Kraft entsteht, die das Projekt von selbst vorantreibt.

Karl Frey (1983) ist, betreffend dem Grad der Beteiligung des Lehrers während der Projektinitiative, der Meinung, dass Themenvorschläge seitens der Lehrperson vertretbar seien, solange die Schülerinnen und Schüler noch wenig Erfahrung auf diesem Gebiet haben und sich schwer tun mögliche Themen für Softwareprojekte selbst zu finden. Sobald die Schülerinnen und Schüler einige Erfahrung im Bereich der Softwareerstellung gesammelt haben, wird es auch ohne Intervention der Lehrperson zu eigenen Fragestellungen seitens der Schülerinnen und Schüler kommen.

Der Auffassung, dass beide oben genannten Vorgehensweisen geeignet seien, um ein gutes Projektthema zu finden, sind Schubert und Schwill (2004). Nach ihnen sollte die Lehrperson, falls sie sich dazu entschließt die Themenvorschläge von den Schülerinnen und Schülern entwickeln zu lassen, dennoch den Prozess lenken und die Schülerinnen und Schüler dazu auffordern ihre Vorschläge ausführlich zu diskutieren. Hierbei ist es auch Aufgabe des Lehrers Projektvorschläge zu beurteilen und gegebenenfalls von ihnen abzuraten. Themenvorschläge seitens der Lehrperson hingegen bieten die Chance, ein Thema zu wählen, das sich bereits bewährt hat. Falls die Lehrperson bestimmte Projektthemen vorlegt, so sollten diese allerdings genaue Angaben bezüglich der zu erbringenden Schülerleistungen enthalten. Nach Koerber (1992) ist es insbesondere in den Kassenstufen 5-10 ratsam dieses Verfahren der Themeneinbringung zu wählen, wobei Vorschläge von Schülerinnen und Schülern dennoch stets begrüßt werden sollten.

Abbildung 3: Kriterien für die Auswahl von Projektthemen (vgl. Schubert & Schwill, 2004)

Schubert und Schwill (2004) haben einen Katalog an Auswahlkriterien zusammengestellt, die bei der Wahl eines Projektthemas zu prüfen sind. Ein Thema sollte demnach zu Beginn noch offen formuliert sein, so dass den Schülerinnen und Schülern Freiraum bleibt, den Rahmen der Anforderungsdefinition selbst festzulegen. Des Weiteren sollten während der Bearbeitung der möglichen Fragestellung die einzelnen Phasen des Software Life Cycle erkennbar werden. Das Thema sollte im späteren Verlauf reduzierbar, bzw. erweiterbar sein, falls dies zeitlich erforderlich wäre. Auch ist darauf zu achten, dass das Projektthema die, für die Aufteilung der Arbeit auf die einzelnen Schülergruppen, notwendige Modularisierbarkeit erfüllt, dass das Thema Realitätsbezug im Hinblick auf die Lebenswelt der Schülerinnen und Schüler hat, dass es technisch realisierbar sein wird und dass Vorarbeiten seitens der Schülerinnen und Schüler notwendig sein werden, jedoch nicht allzu viel Zeit einnehmen.

Betreffend der Vorarbeiten, hinsichtlich der Wahl eines Projektthemas, gibt Koerber (1992) an, dass die Themenvorschläge genau analysiert werden müssen, Informationen zu den Themen vor der ganzen Klasse zu präsentieren sind und erst danach gemeinsam ein Thema demokratisch zu wählen ist. Der gesamte Entscheidungsfindungsprozess sollte nach Koerber (1992) allerdings nicht mehr als 10% der Projektlaufzeit benötigen.

Teamstruktur im Informatikunterricht[Bearbeiten]

Bei Softwareprojekten in der freien Wirtschaft sind, wie bereits oben erwähnt, leistungseffizientes Arbeiten und Spezialistentum erwünscht, wobei hierarchische Teamstrukturen die Regel sind. In Projekten mit pädagogischen Zielen hingegen, sind nach Schubert und Schwill (2004) jedoch demokratische Teamstrukturen und Generalistentum gefragt, so dass alle Schülerinnen und Schüler zu jeder Zeit über den aktuellen Stand des Projektes informiert sind und gemeinsam über die weitere Vorgehensweise diskutieren können, was den Sozialkompetenzen der Schülerinnen und Schüler zugute kommt. Somit sind im Unterricht, im Gegensatz zu in der Wirtschaft, gewisse Hindernisse und Konflikte sogar sehr willkommen.

Insbesondere, wenn die Schülerinnen und Schüler noch nicht allzu vertraut mit der Unterrichtsmethode der Projektarbeit sind, kann es Schubert und Schwill (2004) zufolge schnell passieren, dass während einer Diskussionsphase die begrenzte Zeit vergessen wird. Hier kann es ratsam sein zuerst einmal kleinere Gruppengrößen zu wählen.

Projektphasen im Informatikunterricht[Bearbeiten]

Um ein Softwareprojekt im Informatikunterricht durchzuführen, wird in sämtlicher Didaktikliteratur der Informatik dazu geraten, die Projektphasen des Software Life Cycle auf die typischen Phasen der pädagogischen Projektmethode zu übertragen und in Einklang zu bringen (Ambros, 1992; Jähnichen et al., 1983; Hartmann et al., 2006; Humbert, 2005; Koerber, 1992 ; Lehmann; 1992; Schubert & Schwill, 2004). Da sich diese beiden Projektarten jedoch, wie bereits erwähnt, in manchen Punkten erheblich wiedersprechen, muss das Projekt der Softwareindustrie einigen Modifikationen unterzogen werden, damit es in didaktischem Sinne im Informatikunterricht eingesetzt werden kann. Auch in diesem Punkt sind sich alle Autoren einig. Bezüglich des Ausmaßes an detaillierten Anregungen, wie die Umsetzung eines Softwareprojekts im Informatikunterricht aussehen könnte, zeigen sich in der Literatur jedoch Unterschiede. Eventuell mangelt es derzeit noch an beispielhaften Praxiserfahrungen, sowie an Bedarf seitens der Literatur konsumierenden Lehrpersonen, da es sich bei der Informatik um ein verhältnismäßig noch sehr junges Schulfach handelt und es nicht an allen Schulen in allen Bundesländern eigenständig unterrichtet wird.

Die Ansicht, dass sich die Behandlung der Projektphasen des Software Life Cycle in den Lehrplänen des Informatikunterrichts wiederfinden sollte, vertreten auch Jähnichen, Koch und Schürmann (1983). Sie haben im eigenen Unterricht bereits festgestellt, dass wenn ein Softwareprojekt im Informatikunterricht durchgeführt wird und darin nicht alle Phasen durchlaufen oder zumindest durch die Lehrperson beschrieben werden, die Schülerinnen und Schüler geringere Fortschritte verzeichnen.

Jähnichen, Koch und Schürmann (1983) sind jedoch auch der Meinung, dass ein Projekt nicht an Erfolg einbüßt, wenn aus diesem als Softwarelösung nur ein „Prototyp“ hervorgeht. Für die nach Fertigstellung des Produkts folgenden Schritte, wie beispielsweise der Integrationstest, würde es reichen deren Existenz und Zwecke im Plenum zu besprechen. Nach Überzeugung von Humbert (2005) können auch Projekte, die abgebrochen werden müssen oder aus denen kein funktionsfähiges Programm hervorgeht, zu einem Lernerfolg der Schülerinnen und Schüler führen.

Um die Projektarbeit der Softwareindustrie mit der pädagogischen Projektarbeit zu verbinden, haben Schubert und Schwill (2004) ein Modell entwickelt, in dem eine mögliche Handhabung im Unterricht vorgeschlagen wird:

  • Problemanalyse und Entwurf: Während den ersten beiden Projektphasen werden noch keine Projektteams gebildet. Die Anforderungsdefinition und die Spezifikation werden von der Klasse gemeinschaftlich erarbeitet. Während diesen Phasen ist darauf zu achten, dass eine demokratische Arbeitsweise herrscht und gemeinsam diskutiert wird, ehe man vereint eine weiterführende Entscheidung trifft.
  • Implementierung und Test: Nun erfolgt die Modularisierung. Ab diesem Zeitpunkt arbeiten die Schülerinnen und Schüler in kleinen Projektteams, wobei jedes Team für ein Modul Verantwortung trägt. Die Teambildung sollte hierbei so erfolgen, dass die Mitglieder der Cliquen, die sich innerhalb der Klasse einst verfestigt haben, verschiedenen Projektteams angehören, um den Zuwachs an Sozialkompetenzen während der Projektarbeit noch zu verstärken. Während der Implementierungsphase fertigt jedes Projektteam den Quellcode des von ihm zu erstellenden Moduls und dessen Dokumentation selbstständig an. Der aktuelle Arbeitsstand wird immer dann der gesamten Klasse präsentiert, wenn die zuvor festgelegten Fixpunkte (auch Meilensteine genannt) erreicht werden.
    Zusätzlich zu der Modulerstellung in Teamarbeit sollte jede Schülerin und jeder Schüler für eine bestimmte Arbeit zuständig sein, die der gesamten Gruppe dient. Benötigt wird hierbei ein Rechnerbeauftragter (hilft den einzelnen Teams mit technischen Problemen), ein Projektüberwacher (hat den Arbeitsstand der einzelnen Projektteams im Blick und plant dementsprechend die Fixpunkte), ein Schnittstellenbeauftragter (kümmert sich darum, dass die Schnittstellen der Module zusammenpassen und führt die Modulintegration durch), ein oder mehrere Tester (führen Modultests durch, konzipieren Testdaten, prüfen diese und halten deren Ergebnisse fest), ein Dokumenteur (trägt die Dokumentationen zur Gesamtdokumentation zusammen), ein genereller Kümmerer, ein Sitzungsleiter und ein Protokollführer.

Problematik der Leistungsmessung[Bearbeiten]

Zur Leistungsmessung bezüglich der von Schülerinnen und Schülern in einem Softwareprojekt geleisteten Arbeit und der daraus resultierenden Kenntnisse reicht es Schubert und Schwill (2004) zufolge nicht aus, lediglich eine Klausur zu schreiben. Wenn die Projektarbeit im regulären Unterricht zum Einsatz kommt und in diesem Noten vergeben werden müssen, sollte der Weg, auf dem die Kenntnisse gewonnen wurden, mit in die Leistungsbewertung einfließen.

Lehmann (1992) schlägt folgende Aspekte vor, die in die Bewertung eingehen können:

  • Bewertung in Arbeitsgruppen: Das Problem hierbei liegt darin, herauszufinden ob die Schülerinnen und Schüler innerhalb der Gruppe in gleicher Art und Weise gearbeitet haben oder ob Unterschiede zu verzeichnen sind. Wenn es Unterschiede in der Arbeitsweise gibt, dann gilt es den Umfang in die Note mit einzubeziehen.
  • Fertigkeiten im Umgang mit dem Gerät: Zum Beispiel ein sicherer Umgang mit dem Editor und dem Betriebssystem. Ein Indikator für die vorhandenen und erworbenen PC-Kenntnisse könnte die Präsenszeit am Computer sein.
  • Kommunikationsfähigkeit über die Gruppe hinaus: Zum Beispiel wäre dies, die Bereitschaft mit anderen Gruppen zusammenzuarbeiten, sich mit ihnen auszutauschen und ihnen zu helfen. Des Weiteren ist hierbei die Beteiligung an Diskussionen im Plenum zu bewerten.
  • Bewertung von Hausarbeiten: Hausaufgaben könnten zum Beispiel in Projektphasen verteilt werden, in denen die Klasse gemeinsam an einer Sache arbeitet. Eine Alternative während der Arbeit in den Projektteams wären Fragen, die das gesamte Projekt betreffen.
  • Reaktion auf Lehrerfragen und auf Lehrereingriffe: Die Lehrperson könnte versuchen in Einzelgesprächen mit den Schülerinnen und Schülern festzustellen, ob manche Schüler bezüglich der Vorgehensweise bei der Arbeit, detailliertere Angaben machen können, als andere, bzw. Arbeitsvorschläge des Lehrers besser zu verstehen scheinen.
  • Nachgewiesene Programmierkenntnisse: In die Benotung sollten die allgemeinen Programmierkenntnisse der Schülerinnen und Schüler einfließen, jedoch ebenso das Beachten der, durch die Lehrperson vorgegebenen, einheitlichen Programmstrukturierung.
  • Fähigkeit sich selbst Kenntnisse zu erarbeiten: D.h. sich, zum Beispiel durch Literatur- und Internetrecherche, selbst Informationen zu beschaffen.
  • Darstellung eigener Arbeitsergebnisse: Die eigenen Arbeitsergebnisse werden den anderen Gruppen präsentiert. Dabei erhalten die Schülerinnen und Schüler einen Überblick, an welcher Stelle sie sich gerade befinden und wo das einzelne Modul im Gesamtsystem einzuordnen wäre.
  • Dokumentation, schriftliche Darstellung von Arbeitsergebnissen und Protokolle: Auch sie sollten sich in der Gesamtnote wiederfinden.

Lehmann (1992) empfiehlt, bereits während der Projektinitiative, den Schülerinnen und Schülern mitzuteilten, wie sich die Projektnote zusammensetzen wird und welche Kriterien dabei erfüllt werden müssen. Während der Projektarbeit sollte den Schülerinnen und Schülern dann ab und an eine mündliche oder schriftliche Rückmeldung gegeben werden.

Beispiele und Links[Bearbeiten]

  • Projekt: Objektorientierte Programmierung eines einfachen Funktionsplotters in Java
    http://www.lehrer-online.de/projekt-funktionsplotter.php?sid=91671275551554228033846394639580
  • Projekt: Objektorientierte Modellbildung des Spiels PacMan
    http://www.lehrer-online.de/modellbildung-pacman.php?sid=91671275551554228033846394639580
  • Dokumentation eines Softwareprojekts: Programmierung eines Spiels mit dem Marienkäfer Kara
    http://www.karaproject.com/de/files/Dokumentation%20%281.0%29.pdf
    http://www.karaproject.com/de/
  • Karl Frey (1983) nennt folgende Beispiele aus zwei Grundkursen Informatik im 13. Jahrgang (für ein Projekt über 45 Stunden):
    • Spielstrategien
    • Stundenplanerstellung
    • Schulverwaltung / Oberstufenverwaltung
    • Softwareverbesserungen
    • Softwarepaket zur Stochastik
    • Editorentwicklung
    • Simulation von Ökosystemen
    • Multiple Choice Test
  • Rabus und Koerber (Koerber, 1978) haben einer 10. Klasse im Informatikunterricht folgene Projektthemen vorgeschlagen:
    • Probleme aus Wirtschaft und Verwaltung: Buchhaltung im schulinternen Getränkeladen, Buchhaltung und Statistik im schulinternen Eisladen, Simulation eines Versandhandels, Simulation eines Girodienstes
    • Probleme von Datenbanken und Informationssystemen: Erstellen eines Fach-Auskunftssystems, Erstellen einer Lehrerdatei zur Information für Schüler, Berechnung der Zensuren zum Mittelstufenabschluß mit Beratung
    • Probleme aus künstlerischen Bereichen: Kunst und Konstruktion mit Computern, Komponieren mit dem Computer, Dichten mit dem Computer
    • Probleme aus der Linguistik: Sprachübersetzung einfacher Art mit Computern, Erstellen von Kreuzworträtseln mit Computer
Entschieden haben sich die Schülerinnen und Schüler für das Projekt Kunst und Konstruktion mit Computern, das etwa ein Halbjahr umfasste. Als Projektziel wurde festgelegt mit dem Rechner allgemeine graphische Muster, Tapeten und Stoffmuster, sowie Stickmuster in unterschiedlichen Arten und Formen nach eigenen Vorgaben und zufallsgesteuert zu erzeugen.

Literatur[Bearbeiten]