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 11) 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 Cycles 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 : Automatischer Personalplaner

Es wird ein neue Software entwickelt. Aus der Liste der spontanen Vorschläge wurde ein Personaleinsatzplaner gewählt. Dazu trug wesentlich bei, dass der Vater eines Schülers ein Fischgeschäft führt und dort ein echter Bedarf für eine solche Software vorhanden ist.

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 zur Hälfte in die AT-Semesternote eingeht. Der erreichte Endstand wurde mit 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 einen hoch motivierten Schüler mit weitgehenden Kenntnissen in C und Pascal sind die reinen Programmierfähigkeiten eher schwach. Die Kenntnisse in Modellierungsfragen sind durchweg gut. Die Mitarbeit war insgesamt gut und besser, vermutlich deshalb, weil hier zur Unterrichtszeit das übliche Lehrer-Schüler-Scenario 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.

4.1 Systemanalyse

Wie oben schon erwähnt brachte ein engagierter Schüler reale Planungsunterlagen mit, anhand derer die Analyse zügig erstellt werden konnte. Dabei zeigte sich, dass das dort bisher verwendete Planungsmaterial unzureichend war und einer verbesserten Darstellung bedurfte. Positiv wirkt sich auch aus, dass Schüler eines Wirtschaftgymnasiums Kenntnisse in Betriebswirtschaft  haben.

4.2 Entwurf

Es wurde in diesem Halbjahr OOA- und OOD-Phase erstmalig strikt getrennt und zunächst das reine OOA-Modell erstellt, was zu einer deutlichen Verbesserung des Verständnisses des Systems beigetragen hat. Erst danach wurden die notwendigen Erweiterungen des OOD hinzugefügt.

Deshalb und  aufgrund der vorhandenen guten Kenntnisse gestalteten sich OOA- und OOD-Phase ohne große Umwege. Hierzu trug auch der Einsatz eines neuen interaktiven Entwurfstools (GO) bei. Das OOD-Modell wurde bei den Methoden nicht ganz vollständig ausgearbeitet, um frühzeitiger in die Implementierung zu gehen.
Diese Verkürzung der Designphase hatte erwartungsgemäß teilweise negative Folgen, die sich in mehrfacher Änderung der Modulspezifikationen niederschlugen. Es ist abzuwägen, ob eine vollständige Spezifikation (postfertig für Bangalore) vorzuziehen ist, dann aber mehr Zeit erfordert.

4.3 Implementation

Wie immer bei einem guten OOD-Entwurf zeigten sich bei der Implementation keine besonderen Schwierigkeiten. Insofern bestätigte die Implementation die Qualität des Entwurfs. Das gesamte Projekt besteht überwiegend aus ineinander geschachtelten Listen. Ohne die Vererbungsmöglichkeiten und das Vorliegen von abstrakten statischen und dynamischen Listen aus eigener Bibliothek wäre es kaum zu realisieren.

Bis zum Semesterende wurde die Version 1 von den Schülern fertig gestellt. Hier zeigte sich wieder deutlich die mangelnde Programmierpraxis, auf die wegen der Zeitknappheit verzichtet werden muss.
Die Versionen 2-4 wurden anschließend von einem einzelnen Schüler in bravourösem Alleingang fertig gestellt.
Daneben wurde eine (geheime) Lehrerversion codiert, um unvorhergesehene Klippen zu entdecken und den Zeitaufwand abzuschätzen..

5.  Dokumentation online im Web

Bisher wurden Softwareprojekte in herkömmlicher Weise dokumentiert; d.h. alle erforderlichen Dokumente wurden mit einer Textverarbeitung oder Editor geschrieben, ausgedruckt und in einem allgemein zugänglichen Leitzordner abgelegt. In diesem Semester wurde erstmalig auf jede papierne Dokumentation verzichtet. Alle Texte und Grafiken wurden in HTML geschrieben und ins LAN/WWW gestellt. Protokolle und andere Dokumente wurden simultan erstellt und per Mailinglisten (und forwards auf Privatadressen) an die Teilnehmer versandt. Da die überwiegende Mehrheit privaten Internetzugang besitzt, konnte auch von zu Hause auf alle projektrelevanten Dokumente und Arbeitsmaterialien über das Web zugegriffen werden. Diese Form der Projektorganisation hat sich in jeder Hinsicht bewährt und wurde von allen geschätzt.

Da die Erstellung und Einbindung aller Webseiten einen sehr großen Arbeitsaufwand verursacht, hat die Aufgabe des Projektsekretärs der Lehrer übernommen.

6. Das Produkt

Das Ergebnis liegt in zwei Versionen vor, einer Schüler- und Lehrerversion.

7. Eingesetzte Werkzeuge und Ressourcen

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

Organisationsform: Chefprogrammierer-Team 

Modulbibliothek

Eine wesentliche Voraussetzung für ein gutes Gelingen eines Softwareprojektes ist das Vorhandensein einer wohlgeordneten Sammlung von Modulen, die als wiederverwendbare Bausteine in neuen Programmsystemen eingesetzt werden können. Sie ermöglichen erst, dass in der Schule Programme größerer Komplexität angegangen werden können und sichern dem Lehrer eine Grundlage für die Planung und die immer notwendige Abschätzung der Realisierbarkeit eines Projektes hinsichtlich Umfang, Zeitbedarf, Schwierigkeitsgrad und Fähigkeiten der Schülergruppe. Den beteiligten Schülern bieten sie ein Fundament, auf dem ein Projekt aufgesetzt werden kann, Entlastung beim Schreiben von Programmcode und damit vor allem die Möglichkeit, Zeit für die Analyse und das Design zu gewinnen und sich an Aufgabenstellungen zu wagen, die sonst nicht durchführbar wären.

Verwendete eigene Fachklassen: uAdresse, uPerson, uSListe, uDListe
PAT 99 - Dateiverwaltungsprogramm aus dem 1. Kurshalbjahr, das kannibalisiert wurde.