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 :

Entwicklung eines Programms  zur Abwicklung von Bestellungen und Rechnungen in einem Restaurantbetrieb

Es wird ein neue Software entwickelt. Aus der Liste der spontanen Vorschläge wurde dieses gewählt. Dazu trug bei, dass einige Schüler Erfahrungen aus Jobs in Gaststätten hatten.

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. Die OOA- und OOD-Ergebnisse wurde mit besser als gut, die Codierung als schwächer, das Gesamtgruppenergebnis mit gut bewertet.

3. Die Kursteilnehmer

Schüler des Grundkurses Informatik, die eher ein distanziertes Interesse an Informatik und teilweise mehr am Nasdaq und Nemax haben, aber im allgemeinen gut mitarbeiten. Es sind keine "Programmierer" darunter. Die reinen Programmierfähigkeiten sind überwiegend 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, hatten Schüler Erfahrungen aus diesen Tätigkeiten, so dass  die Analyse zügig erstellt werden konnte. Positiv wirkt sich auch aus, dass Schüler eines Wirtschaftgymnasiums Kenntnisse in Rechungswesen haben.

4.2 Entwurf

Es wurden 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 gestaltete 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 einigen Änderungen der Modulspezifikationen niederschlug. Es ist abzuwägen, ob eine vollständige Spezifikation (postfertig für Bangalore) vorzuziehen ist, dann aber mehr Zeit erfordert.

4.3 Implementation

Das Projekt beschreibt einen Ausschnitt aus einem Warenwirtschaftssystem,  der mit Listen- und Dateiverwaltung (1. Kurshalbjahr) realisiert werden kann.  Wie immer bei einem guten OOD-Entwurf zeigten sich bei der Implementation keine besonderen Hürden. Insofern bestätigte die Implementation die Qualität des Entwurfs. Als etwas schwierig zeigte sich die Realisierung der Rechnung und der GUI-Klasse wegen der vielfältigen Assoziationen zu anderen Fachklassen.

Bis zum Semesterende wurde die Version 1 knapp fertig. Hier zeigte sich wieder deutlich die mangelnde Programmierpraxis, auf die wegen der Zeitknappheit verzichtet werden muss. Die Implementation wurde ausschließlich von den Schülern erstellt. 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 projektrelevanten Dokumente, 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.