Hinweise zur Dokumentation eurer Projekte

Ihr habt eine Gruppe und eine Projektidee gefunden? Dann legt die Seite an mit

• dem Projekttitel
• euren Namen
• einer kurzen Beschreibung der Projektidee
• einem Unterabschnitt für Quellen/Literatur, den ihr allmählich befüllen könnt
• einem Unterabschnitt für Projektplanung
• einem Link zu eurer Protokollseite (beachtet dabei die richtigen Präfixe, das wird auf der Seite fürs laufende Semester erklärt).
• einem noch leeren Abschnitt für die strukturierte Dokumentation

Wie plant man Projekte und wie führt man sie durch?

Auf diese Frage gibt es *professionelle* Antworten, die man in Kursen über Projektmanagement erfahren kann. Hier soll alles etwas einfacher gehalten werden, aber doch so, dass es funktioniert

• Legt einen Ort fest, wo ihr Programme, Daten, Dateien miteinander teilt, und haltet den Link in der Wiki fest. (Teilt mit Personen und nicht mit einem Linke
  • Die einfachste Lösung ist ein Ordner in dertubcloud, den ihr miteinander teilt. Beim Betreuen der Projekte hilft es uns, wenn ihr ihn auch mit uns (JP, Stefan Born) teilt. Für die tubcloud gibt es einen Client (Linux/Windows/Mac), der Ordner der Cloud mit denen auf eurem Rechner synchronisiert. Achtung: Legt am besten jede Woche einen Unterordner des geteilten Ordners an, in den ihr alle Inhalte der vorigen Woche kopiert. „poor man's version management'
  • Etwa aufwändiger (und professioneller) ist es, ein Repositorium ingitlab anzulegen, ebenfalls wieder miteinander (und mit uns) zu teilen.
• Versucht Teilaufgaben mit Teilzielen zu formulieren (nicht zu viele) mit einer Schätzung, wie lange es dauern könnte, diese zu erreichen. Diese Schätzungen werden normalerweise daneben liegen. Solche Pläne macht man, um sie immer zu revidieren. Überlegt außerdem, welche der Aufgaben ihr gleichzeitig erledigen könnt, welche aber die Erledigung anderer voraussetzen. Wenn ihr wollt, könnt ihr dazu ein Gantt-Diagramm erstellen.
• Einigt euch darüber, über welches Medium ihr in der Gruppe miteinander kommuniziert (Discord?).

Übrigens: Für einfache Gantt-artige Diagramme könnt ihr Wiki-Tabellen nehmen:

Verseht eure erste Planung mit einer enstprechenden Unterüberschrift. Wenn ihr dann umplant, macht neue Überschriften. So könnt ihr den alten Planungsprozess noch sehen. Ihr könnt natürlich auch die alten Planungen auf eine andere Seite verschieben und verlinken.

Was auch hierhin gehört:

• Absprachen über die Verteilung des Codes auf Module.
• Absprachen über Interfaces (Was sollen Funktionen/Klassen tun?)

Es ist gut, die Interfaces, die ihr definiert, hier zu haben und dann gegebenenfalls zu ändern. Ihr könnt das natürlich auch in Dokumenten in gitlab oder tubcloud machen, die ihr dann aber an dieser Stelle verlinkt.

Das Vorhandensein einer Planung geht zu 10% in die Note ein.

Bei jeder Laborarbeit, etwa dem physikalischen oder chemischen Praktikum, aber auch späterer wissenschaftlicher Arbeit, gehört das Führen eines Laborbuchs dazu. Wenn möglich, soll die ganze Arbeit daran nachvollziehbar sein. (Woran hat's gelegen, wenn das Labor explodiert ist?)

Für Mathesis gilt das auch ungefähr.

• Beginnt jede Woche am Anfang einen Protokollabschnitt oder eine Protokollseite
• Fügt im Laufe einer Sitzung alles mögliche da ein, Programme, gefundene Fehler, erzeugte Bilder oder Tonaufnahmen, auch Fotos handschriftlicher Aufzeichnungen.
• Alles, was da vorliegt, könnt ihr bei der strukturierten Dokumentation, die ihr gegen Ende eures Projekts schreibt verwenden. Zur Dokumentation gehört auch ein Teil, der den Verlauf beschreibt.

Das Vorhandensein der Protokolle geht zu 15% in die Note ein.