Ein Informatikprojekt beginnt mit einer Problemstellung: einem Problem aus der Wirklichkeit, das sich mit einem Informatiksystem lösen lässt. Du klärst: Für wen ist das System? Was soll es können? Das Ergebnis sind Anforderungen, also Aussagen darüber, was das System leisten soll. Man unterscheidet:

• Muss-Anforderungen: Ohne sie erfüllt das System seinen Zweck nicht.
• Kann-Anforderungen: Sie sind nützlich und entfallen bei Zeitnot.
• Abgrenzung: Das gehört ausdrücklich nicht zum Projekt.

Gute Anforderungen sind überprüfbar. "Das System soll einfach sein" lässt sich nicht prüfen, "Eine Ausleihe wird mit höchstens drei Klicks erfasst" schon. Gespeichert wird nur, was der Zweck verlangt.

In der Planung zerlegst du das Projekt in Arbeitspakete, schätzt die Zeit, legst die Reihenfolge fest und verteilst die Arbeit. Zeitplan, Meilensteine, Puffer und Rollen kennst du aus dem Einstieg in das Informatikprojekt. Der Zeitplan folgt den Phasen: Anforderungen klären, Modellieren, Implementieren, Testen, Dokumentieren. Sie laufen nicht streng hintereinander: Ein Test kann zeigen, dass das Modell geändert werden muss. Plane solche Rückschritte ein.

Ein Risiko ist etwas, das den Plan gefährden kann, zum Beispiel ein Ausfall im Team oder eine unklare Anforderung. Notiere zu jedem Risiko, was du dagegen tust.

Beim Modellieren entwirfst du die Lösung auf dem Papier, bevor du sie baust.

• Bei einem Datenbankprojekt besteht das Modell aus einem ER-Modell und den Tabellen mit Primär- und Fremdschlüsseln. Beziehungen werden festgelegt, doppelte Daten (Redundanz) vermieden.
• Bei einem Softwareprojekt besteht es aus einem Klassendiagramm mit Attributen und Methoden oder aus Flussdiagrammen der wichtigsten Unterprogramme, dazu kommt eine Skizze der Benutzeroberfläche.

Das Modell ist die gemeinsame Sprache des Teams. Es wird besprochen, bevor jemand implementiert, denn ein Fehler im Modell kostet später viel Arbeit.

Bei der Implementierung setzt du das Modell um: Du legst Tabellen an und füllst sie oder schreibst Programmteile in Python. Das hilft dabei:

• Arbeite in kleinen Schritten und probiere jeden Schritt sofort aus.
• Schreibe lesbaren Quelltext: aussagekräftige Namen, Kommentare, kleine Unterprogramme mit Parametern und Rückgabewert.
• Wenn ein Teammitglied deine Funktion nutzt, legt ihr vorher Name, Eingaben und Ergebnis fest (Spezifikation).
• Gemeinsame Dateien bekommen Datum oder Versionsnummer, damit sich Stände nicht überschreiben.

Beim Test prüfst du, ob das System die Anforderungen erfüllt. Ein Testfall ist eine Eingabe mit dem erwarteten Ergebnis. Du legst ihn fest, bevor du das System ausprobierst, sonst passt du die Erwartung unbewusst an das Ergebnis an. Man testet:

• Normalfälle: typische, gültige Eingaben.
• Grenzfälle: Eingaben genau an einer Grenze, zum Beispiel der größte erlaubte Wert.
• Fehlerfälle: ungültige Eingaben wie ein leeres Feld oder eine unbekannte Buch-ID. Bei einer Datenbank prüfst du Abfragen mit Daten, deren Ergebnis du kennst.

Die Ergebnisse stehen im Testprotokoll: Testfall, erwartetes und tatsächliches Ergebnis, bestanden oder nicht. Nach jeder Korrektur wiederholst du alle Tests, denn eine Änderung kann an anderer Stelle etwas zerstören. Zum Schluss prüft ein Abnahmetest, ob die Anforderungen der ersten Phase erfüllt sind. Tests können Fehler finden, aber nie beweisen, dass keine mehr da sind.

Die Dokumentation hält fest, was entstanden ist und wie, damit andere es verstehen, benutzen und weiterentwickeln können:

• Nutzerdokumentation: Anleitung für alle, die das System bedienen: Start, Funktionen, Beispiele.
• Entwicklerdokumentation: für alle, die es ändern: Problemstellung und Anforderungen, Modell, Aufbau des Quelltextes, Testprotokoll, bekannte Mängel.
• Projektbericht: Zeitplan mit geplanten und tatsächlichen Zeiten, Arbeitsteilung, Probleme und Entscheidungen, Quellen und Lizenzen fremder Bibliotheken oder Bilder, Rückblick: Was lief gut, was würdet ihr anders machen?

Dokumentiere laufend. Was du heute entscheidest, hast du in zwei Wochen vergessen.