Auf dieser Seite möchte ich den Ablauf der ersten beiden Runden des Bundeswettbewerbs Informatik schildern und erläutern, was meiner persönlichen Sicht nach eine gute Einsendung ausmacht und welche häufigen Fehler es zu vermeiden gilt. Zwar habe ich durch meine eigenen Teilnahmen beim BWINF, die Einsendungssammlung auf meiner Homepage und auch Teilnahmen an Erst- und Zweitrundenbewertungen schon einige Einsendungen gesehen und eine gewisse Erfahrung in Bezug auf häufige unnötige Fehler, doch letztendlich verbindliche Richtlinien für die Einsendungen und Bewertungen stellen natürlich ausschließlich die Gremien des Bundeswettbewerbs Informatik auf. Alles, was im untenstehenden Text über die mit den Aufgaben herausgegebenen allgemeinen Richtlinien, die FAQ und sonstige offizielle Veröffentlichungen des Bundeswettbewerbs Informatik hinausgeht, ist also lediglich meine höchst subjektive Ansicht von Qualität und nicht so wichtig wie die Einhaltung der vom BWINF selbst geforderten Punkte. Bei etwaigen Widersprüchen hat natürlich der BWINF Priorität und Entscheidungsgewalt.
Insbesondere dienen meine Tipps nur als Anhaltspunkte zur Vermeidung besonders häufiger Fehler und nicht etwa als Aussage darüber, welche Punkte wirklich am wichtigsten sind. Darum habe ich völlig selbstverständliche Dinge (die mir darum oftmals nicht einmal bewusst werden) weniger betont als unwichtigere andere, die aber eher missachtet werden. Damit meine Tipps nicht nur graue Theorie bleiben, möchte ich Dir auch dringend empfehlen, Dir zum Vergleich einmal ein paar alte Einsendungen von früheren Wettbewerben anzuschauen.
Für Verständnisfragen zu den Aufgaben und für die Diskussion der Aufgaben nach dem Einsendeschluss halte ich die Newsgroup fido.ger.bwinf für ziemlich hilfreich. Beim Posten in letzterer Newsgroup solltest Du Dir aber vor dem Absetzen Deines Postings genau überlegen, ob Dein Posting nicht etwa schon vor dem Einsendeschluss Lösungsteile verrät – dazu gehören auch versteckte Probleme in der Aufgabenstellung bzw. in einer geforderten Modellierung ("Hat der zu modellierende Fischteich eigentlich Grenzen?", "Haben die Fische eine Richtung?", "Was soll eigentlich passieren, wenn mein Roboter merkt, dass er eine Schleife gelaufen ist?")! Beachte, dass auch versteckte Prahlerei bezüglich dessen, was Dir schon alles aufgefallen ist, ganz besonders vor dem Einsendeschluss unangebracht ist und es Dir niemand danken wird, wenn Du dadurch die Chancengleichheit und Aufgabenstellung des Wettbewerbs beschädigst.
Wenn Dir der ganze Text zu lang ist, kannst Du auch nur die Zusammenfassung lesen. Für Fragen, Kritik und Anregungen bin ich offen, schreib mir dazu am besten eine Mail.
Die erste Runde umfasst üblicherweise fünf Aufgaben, die Anfang September auf der BWINF-Webseite erscheinen und an zahlreiche Schulen verschickt werden. Teilnahmeberechtigt sind Jugendliche, die zum Einsendeschluss (meist der 2. oder 3. Montag im November) noch keine 22 Jahre alt sind, keine Ausbildung abgeschlossen und kein Studium und keine Berufstätigkeit begonnen haben. Für die genaueren Teilnahmebedingungen schaust Du am besten im Aufgabenblatt nach. Pro Aufgabe kann man maximal 5 Punkte erreichen, für die Teilnahmeberechtigung an der zweiten Runde benötigt man mindestens 12 Punkte aus den besten drei Aufgaben. Mit 3,3,3,4,4 Punkten kommt man also gerade nicht weiter, mit nur drei bearbeiteten Aufgaben und jeweils 4 Punkten dagegen schon. Im Gegensatz zur zweiten Runde darf man die erste Runde auch als Gruppe bearbeiten.
Die Ergebnisse der ersten Runde werden üblicherweise kurz vor Weihnachten an die Teilnehmer verschickt, ggf. zusammen mit den Aufgaben der zweiten Runde. Die zweite Runde umfasst nur noch drei Aufgaben, die aber deutlich schwerer sind. Früher musste man diese Aufgaben alle bearbeiten, seit dem 22. BWINF jedoch nur noch zwei von drei. Das kann sich natürlich jederzeit wieder ändern - lies Dir darum auf jeden Fall die mit den Aufgaben verschickten allgemeinen Hinweise durch. Der Einsendeschluss der zweiten Runde ist meist im April.
Beiden Runden gemeinsam ist, dass die Programme in einer beliebigen höheren Programmiersprache verfasst werden dürfen, also so ziemlich in jeder Sprache außer Assembler, Brainfuck, Übergangstabelle einer Turingmaschine usw. Erlaubt sind insbesondere Pascal, Java, C, C++, Perl, Scheme, Objective Caml, Basic, C#, Ruby, Prolog und bei passender Aufgabenstellung (nur dann!) sogar Postscript. Die verschiedenen Aufgaben dürfen auch in verschiedenen Sprachen implementiert werden, manche Aufgaben sind sogar theoretisch und erfordern gar kein Programm (Informatik besteht schließlich nicht nur aus Programmierung!). Die Aufgaben spezifizieren die genaue Problemstellung meist bewusst nicht bis ins Detail, und ein wichtiger Teil der Aufgabe besteht darin, sich für diese nicht spezifizierten Teilfragen selbst eine vernünftige Lösung zu überlegen und diese Entscheidung in der Dokumentation zu begründen.
Das meiste hierzu wird schon in den "Allgemeinen Hinweisen" gesagt, die Du zusammen mit den Aufgaben erhalten hast. Bedenke stets, dass Deine Einsendung von Menschen und nicht von Computern bewertet wird und darum eine gute, klar gegliederte und nicht zu lange Dokumentation in präzisem und korrektem Deutsch sehr wichtig ist. Bedenke, dass ein großer Umfang (z.B. durch Erläutern von Trivialitäten oder durch Implementierung nicht geforderter Erweiterungen besonders in der ersten Runde) die Nachvollziehbarkeit und vollständige Lektüre Deiner Einsendung prinzipiell erschwert, die Einsendung also schlechter macht. Die Bewerter versuchen, jeder Einsendung gleich viel Zeit zu widmen, und normalerweise reicht dieses Zeitkontingent für eine sorgfältige Lektüre und Bewertung der Einsendung aus. Doch obwohl die Bewerter sich nicht hetzen lassen und sich jeder Einsendung ausgiebig widmen, kann es bei besonders großem Umfang, schlechter Gliederung oder anderweitig stark erschwerter Lektüre passieren, dass ein irgendwo versteckter essentieller Teil Deiner Einsendung zu Deinem Nachteil übersehen oder missverstanden wird.
Dass Dein Programm alle in der Aufgabenstellung geforderten Punkte lösen muss, ist wohl selbstverständlich. Da Deine Einsendung von Menschen bewertet wird, müssen Deine Quelltexte außerdem gut lesbar, also in einer geeigneten Schriftart (z.B. Courier New) und -größe gedruckt, übersichtlich und sauber programmiert sein, aussagekräftige Bezeichner und sinnvolle Kommentare verwenden. Kommentare sollten das, was im Programm geschieht, immer in anderen Worten wiedergeben.
i++; // i um eins erhöhen
wäre also redundant und somit schlechter als ganz ohne Kommentar,
i++; // zum nächsten Roboter übergehen
dagegen sinnvoll. Natürlich darfst Du keine Bibliotheken verwenden, die Dir über Dinge wie eine schicke Optik hinaus die Lösung des Problems erleichtern oder gar wesentliche Teile des Algorithmus implementieren. Außerdem sollte Dein Programm nur wenig (z.B. von IDEs wie Delphi oder Visual Studio) generierten Code enthalten - und die generierten Teile solltest Du zumindest mit eigenen sinnvollen Bezeichnern versehen.
Falls Du mit Delphi programmierst, solltest Du auf jeden Fall direkt nach dem Platzieren eines Elements einen aussagekräftigen Namen wählen. Einen Button mit der Beschriftung "Ok" könntest Du z.B. "btnOk" nennen, ein Konfigurations-Formular "frmConfig" und einen Button, mit dem die Simulation gestartet wird, "btnStartSimulation". Wenn in Deiner Dokumentation Sätze oder gar Überschriften wie "Kern des Algorithmus ist die Funktion TForm3.Button2Click" auftauchen, ist ziemlich sicher etwas schiefgelaufen (oder könntest Du mit so einem Satz etwas anfangen?).
Wie schon angemerkt zeichnet sich eine gute Einsendung im Wesentlichen dadurch aus, dass sie alle in der Aufgabenstellung geforderten Punkte auf geeignete Weise löst und eine Dokumentation beinhaltet, die kurz und präzise den Lösungsweg und dessen Implementation im Programm beschreibt und dessen Funktionsfähigkeit nachweist, unter anderem mit Hilfe geeigneter Ablaufprotokolle. Der Bewerter soll das Programm nicht ausführen müssen, die Dokumentation muss einen lückenlosen (aber nicht mit Trivialitäten aufgeblähten) Nachweis seiner Leistungsfähigkeit enthalten.
Eine Obergrenze für den Einsendungsumfang ist meiner Meinung nach: In der ersten Runde maximal 50 Seiten (davon exklusive der Ablaufprotokolle und Quelltexte pro Aufgabe 2-5 Seiten reine Dokumentation), in der zweiten Runde maximal 150 Seiten (davon pro Aufgabe 7 Seiten reine Dokumentation). Natürlich hängt die exakte Grenze aber davon ab, wie viele Aufgaben Du bearbeitest (in der ersten Runde), wie viele Erweiterungen Du implementierst (in der zweiten Runde) und welche Art von Aufgaben überhaupt gestellt wurde. Versuche aber nicht, den Umfang Deiner Einsendung in Seiten dadurch zu verringern, dass Du schlicht und einfach eine zu kleine (und schlecht lesbare) Schriftart verwendest! Am besten schaust Du Dir ein paar alte Einsendungen an, z.B. von ehemaligen Bundessiegern. Damit nicht aus Zeitmangel die Qualität Deiner Dokumentation leidet, solltest Du Dir früh genug Gedanken über sie machen und anfangen, sie zu schreiben.
Drucke auch Deine Quelltexte aus, und zwar in einer Schriftart mit fester Breite (z.B. Courier), in der ein "i" genauso viel Platz einnimmt wie ein "m", und in ausreichender Größe. Falls Dir das einfach möglich ist, drucke Schlüsselworte fett. Große nicht von Dir geschriebene Bibliotheken (z.B. für die Grafikausgabe) musst Du nicht abdrucken, da sie ja nicht von Dir geschrieben sind und bei der Lösung nur eine sehr untergeordnete Rolle spielen.
Achte auch darauf, dass der Quelltext komplett und mit geeigneten Zeilen- und Seitenumbrüchen gedruckt wird. Vermeide also überlange Zeilen wie
int numHandshakes = numPlayersA * numPlayersB; // Jeder Spieler aus Team
A schüttelt jedem Spieler aus Team B einmal die Hand.
die unpassend umgebrochen werden oder gar teilweise außerhalb des druckbaren Bereichs gelangen und unsichtbar bleiben. Vermeide auch durch manuell eingefügte Seitenumbrüche oder Leerzeilen, dass der Seitenumbruch unnötigerweise an ganz unpassende Stellen wie z.B. direkt hinter einen Funktions- oder Schleifenkopf fällt.
Bedenke, dass Deine Einsendung von Fachpublikum (z.B. ehemalige Bundessieger oder Informatikstudenten zumindest mit Vordiplom) bewertet wird. Du brauchst (und sollst!) also nicht erklären, wie man eine Maus bedient, was eine Tiefen- und Breitensuche oder ein binärer Baum ist oder was die O()-Notation bedeutet.
Zum Abschluss möchte ich das oben gesagte nochmal kurz zu den meiner Meinung nach 10 wichtigsten Punkten zusammenfassen:
Ich möchte betonen, dass das obige nur meine persönliche Meinung darstellt und nicht etwa eine offiziell abgesegnete Richtlinie für BWINF-Einsendungen ist. Die Befolgung meiner Tipps erfolgt ohne Gewähr und auf eigene Gefahr ;-)
Druckversion von http://tobias-thierer.de/bwinf_runde1-2.html; Stand: 2024-02-17 22:30:56 GMT+0100