1. Informatische Ziele

Das Halbjahr 13/1 ist in Gänze dem Softwareprojekt vorbehalten. Im Projektsemester sollen die Methoden und Probleme des Software Engineering an Beispielen mit realitätsnaher Komplexität vertieft werden. Die Komplexität liegt in drei Ebenen:

• inhaltliche Analyse des Sachproblems,
• Konstruktion des Softwaresystems,
• Organisation der aus arbeitsökonomischen Gründen notwendigen Arbeitsteilung.
  

Die informatischen Ziele sind

• ein komplexes System mit wenigsten 5-6 Fachklassen (hier 13) analysieren und entwickeln
• Modellierung, OOA, OOD, OOP
• Saubere Architektur, kein "quick and dirty" - Programmieren
• Vorteile der Wiederverwendung von Klassen, die in früheren Kursen entwickelt wurden, nutzen
• Notwendigkeit der Einhaltung von Vereinbarungen (Schnittstellen), Sinn des Geheimnisprinzips usw. erfahren

Als Softwareprojekte kommen drei Möglichkeiten in Frage:

a) Neues Projektthema

Alle Phasen von der Analyse bis zum fertigen Produkt werden erstmalig durchlaufen.
Bei der Frage nach der Themenwahl gehen die Meinungen auseinander: wer als Lehrer sicher gehen will, gibt das Thema vor und hat die Lösung, sprich das gesamte Programmsystem, schon fertig programmiert in der Hinterhand. Das ist perfekte Risikovorsorge und sollte meiner Meinung nach nur beim aller ersten Projekt des Lehrers gemacht werden. Man handelt sich damit ein, dass die Schüler eventuell das Thema nicht annehmen, dass der Lehrer zu ängstlich ist, von seinen Vorstellungen abzugehen usw.

Der gute Erfolg eines Projektes hängt in nicht unterschätzender Weise von der Motivation und der Mitarbeit der Schüler ab.

Bei der Themenwahl besteht der bessere Weg meines Erachtens darin, Thema und auch sonstige Entscheidungen im Verlauf des Projekts durch Diskussion und Abstimmung herbeizuführen, wobei der Lehrer nur eine Stimme hat und häufig auch überstimmt werden kann. Ich habe mit meinen Kursen vereinbart, dass ich mir als verantwortlicher Projektleiter ein Vetorecht vorbehalten muss für den äußersten Fall, dass das Team die Tragweite eines Beschlusses mangels Erfahrung nicht übersehen kann. Ansonsten gilt, dass der Lehrer als Teammitglied wie alle anderen die Gruppe mit Argumenten überzeugen muss, wenn er Änderungswünsche einbringt, die vom Plenum angenommen oder abgelehnt werden können. Ganz klar muss es auch sein, dass eine Arbeitsgruppe, die auf einem besonderen eigenen Lösungsvorschlag besteht, auch für die Realisation verantwortlich ist und nicht das Problem auf den Lehrer abschieben kann.

b) Fortführung eines früheren Projektes

Hier kann es sich um den Ausbau oder die Vervollständigung eines bereits angefangenen oder auch fertigen Systems handeln.

c) Wartung eines fertigen Softwareproduktes

Dieser als auch der vorige Fall sind in der Praxis wohl die häufigsten, wenn man an die scheinbar endlose Folge von Versionen denkt, mit der der Markt überschüttet wird. Beide Projektformen finden bei Schülern wenig Gegenliebe, weil man ja nicht Eigenes vorzeigen kann. Obwohl die Phasen des Software Life Cycle auch hier abgearbeitet werden können, geht der schöpferische Akt deutlich unter. Außerdem weiß jeder Praktiker, dass es häufig einfacher ist, ein System neu zu konzipieren als sich in ein schlecht dokumentiertes und vielleicht chaotisch zusammengestricktes System einzudenken. Voraussetzung für diese Projekttypen sind das Vorliegen einer präzisen und hinreichenden Dokumentation und eine Softwarearchitektur nach dem Datenabstraktionsprinzip. Nur dann können Module sauber ausgewechselt, ergänzt und in das System eingehängt werden. Ein ablauforientierter Entwurf dürfte in der Regel nicht zu entwirren sein.

Themenentscheidung : Rechner-Verwaltung

Es wird ein neue Software entwickelt. Aus der Liste der Vorschläge wurde ein PC-Verwaltungssystem gewählt. Dazu trug wesentlich bei, dass der Fachbereich wegen der ständig gewachsenen Rechnerausstattung (ca. 80 Stck.) und der damit verbundenen bunten (hinderlichen) Konfigurationen bei Ersatz und Reparaturen eine edv-gestützte Übersicht benötigt, was denn in den Rechnern an Komponenten steckt.

2. Pädagogische Ziele

• Teamarbeit
• Teamfähigkeit
• Führungsfähigkeit
• Konflikte aushalten können
• Selbstlernen
• Selbst organisieren

Das Softwareprojekt im Informatikunterricht bietet eine nahezu einmalige Gelegenheit, über einen langen Zeitraum an einem Thema zu arbeiten, traditionelle Unterrichtsformen "außer Betrieb" zu setzen und dafür Lern- und Arbeitsformen aufzunehmen, die sich aus der Aufgabenstellung ergeben und nicht über künstliche Lernarrangements oder angeordnete Projekttage als methodische Volten inszeniert werden müssen. Hier kann handlungsorientierter Unterricht par excellence stattfinden. Es lohnt sich für alle Beteiligten, gemeinsam durch das Spannungsfeld von Motivation und Frustration zu gehen, ohne exakt vorherbestimmen zu können, wo die Probleme und ihre Lösungen auftauchen werden. Obwohl am Ende immer ein fertiges Produkt stehen sollte, hat es bisher noch nie tiefe Enttäuschungen gegeben, wenn einmal das gemeinsame Ziel am Ende doch nicht ganz erreicht wurde, weil das Produkt aus Zeitgründen in der projektierten Version nicht fertig codiert wurde.

Um die Teamleistung herauszustellen, wurden mit den Schülern gemeinsam die Ziele abgesteckt und vereinbart, dass die Teamleistung überwiegend in die AT-Semesternote eingeht. Der erreichte Endstand wurde mit noch gut bewertet.

3. Die Kursteilnehmer

Schüler des Grundkurses Informatik, die mit einer Ausnahme eher ein distanziertes Interesse an Informatik haben, aber im allgemeinen gut mitarbeiten. Bis auf zwei Schüler sind die reinen Programmierfähigkeiten eher schwach. Die Kenntnisse in Modellierungsfragen sind durchweg befriedigend bis gut. Die Mitarbeit war insgesamt gut und besser, vermutlich deshalb, weil hier zur Unterrichtszeit das übliche Lehrer-Schüler-Szenario für ein halbes Jahr außer Kraft gesetzt war und die Atmosphäre durch eine völlig schul-untypische Arbeitssituation ersetzt ist.

4. Projektverlauf

Alle Phasen des Software Life Cycle wurden mit einem vertiefenden Referat eingeleitet oder begleitet, so dass immer ein Bezug zwischen Theorie und praktischer Umsetzung erzielt wurde.

Das Projekt wurde nach dem vorhandenen Arbeits- und Organisationsschema (s. Web-gestützte Software Projekte) durchlaufen, dass sich auch hier wieder bewährt hat und inzwischen von den Kollegen übernommen wurde.

Analyse und Entwurf gestalteten sich relativ schnell und einfach, da es sich hier nur um ein registrierendes System handelt, dass in der Grundkonzeption aus dem 1. Kurshalbjahr bekannt ist.

Wie immer bei einem guten OOD-Entwurf zeigten sich bei der Implementation der Version 1 keinerlei Schwierigkeiten. Insofern bestätigte die Implementation die Qualität des Entwurfs. Weitere Versionen mit komfortablen Suchfunktionen wurden wegen Zeitmangels nicht erreicht.

5. Das Produkt

Das Ergebnis liegt in einer Schülerversion vor und kann herunter geladen werden.

6. Eingesetzte Werkzeuge und Ressourcen

Office XP, Delphi 6, GO (Generating Objects) UML-Designer , UML
Windows 2000 Netz; Pentium Workstations, alle mit Internetzugang, Mailing-Listen  

Organisationsform: Chefprogrammierer-Team 

Eigene Modulbibliothek: uDListe