Selbstorganisierte Softwareprojekte

Diese Seite erklärt die Funktionsweise einer besonderen Art von Lehrveranstaltung: Softwareprojekte, bei denen Studierende selber Thema und Organisationsform festlegen.


Grundidee

  • Studierende bilden eine Projektgruppe und suchen eine Projektidee
  • Studierende arbeiten ein Dokument aus, das die Idee beschreibt
  • Studierende finden für die Idee eine/n Professor/in, die/der bereit ist, die Durchführung lose zu begleiten und am Ende dafür Noten und Leistungspunkte zu vergeben. Dieser sorgt für die ggf. nachträgliche Anmeldung einer entsprechenden Lehrveranstaltung im Modulverwaltungssystem+KVV sowie eCampus und ordnet dafür in der Regel eine/n WiMi zu.
  • Studierende melden sich zu dieser Lehrveranstaltung an, führen das Projekt durch und liefern an Prof/Wimi genügend Informationen über die Ergebnisse und die Beiträge jedes Gruppenmitglieds, um eine Notenvergabe zu ermöglichen.
  • Ergebnisse werden abgenommen und Leistungspunkte vom Prof bescheinigt.

Zielgruppe, Einbindung in das Studium

Diese Veranstaltungsform steht allen Studierenden offen, die im Bachelor-Studiengang Informatik oder im Master-Studiengang Informatik studieren.

Sebstorganisierte Softwareprojekte werden auf das Studium ebenso angerechnet wie normale Softwareprojekte.

Jeder Professor des Instituts kann und soll eine oder mehrere (dann von einander ganz unabhängige) Projektgruppen nach diesem Modell mit seiner Arbeitsgruppe betreuen, wenn die Arbeitsgruppe nicht im gleichen Semester ein "reguläres" Softwareprojekt anbietet.

Anforderungen

Projektgruppe

Die Projektgruppe muss aus mindestens drei und höchstens zehn Studierenden bestehen; bevorzugt ca. fünf.

Es soll (aber muss nicht zwingend) mindestens ein/e Master-Studierende/r dabei sein. Alle Mitglieder müssen das Modul "Softwaretechnik" bereits absolviert haben.

Projektgruppen bilden sich selbständig und sind selber dafür verantwortlich, nur hinreichend motivierte und kompetente Mitglieder an Bord zu nehmen.

Mögliche Arten von Projektinhalten

  • Es darf sich nicht um ein simples Programmierprojekt handeln.
  • Es müssen entweder in reichlichem Umfang sonstige Methoden der Softwaretechnik zum Einsatz kommen (z.B. Anforderungserhebung bei fremden Anforderungslieferanten; nichttriviale Entwurfsschritte; explizite Entwurfsdokumentation; explizite Qualitätssicherung durch Durchsichten und/oder formalisierte oder automatisierte umfangreiche Tests; explizite Projektplanung und -verfolgung; Einführung bei Endanwendern o.ä.)
  • oder in erheblichem Umfang anspruchsvolle Techniken aus einzelnen Themengebieten der Informatik (z.B. KI, Algorithmen, Verteilung, Parallelität, Sicherheit usw.) eingesetzt werden.
  • Das Projekt soll nicht auf der grünen Wiese entstehen, sondern sich in eine vorhandene Entwicklung einfügen oder daran anlehnen.

Mögliche Formen der Durchführung

  • Das Projekt soll in direkter Zusammenarbeit mit einem externen Kunden durchgeführt werden. Nur in Ausnahmefällen darf die Projektgruppe selbst der Abnehmer sein. Geld muss der Kunde natürlich nicht unbedingt bezahlen.
  • Das Projekt soll in der Regel iterativ in mindestens drei Iterationen entwickelt werden, weil in Wasserfall-artigen Organisationsformen erfahrungsgemäß die Gefahr eines totalen Fehlschlags zu hoch ist.
  • Das Projekt muss ein konkretes Projektergebnis in Form von "Deliverables" haben. Dies sollte in der Regel auch lauffähige Software umfassen, kann aber ausnahmsweise auch etwas anderes sein.

Anbahnung

Zur Anbahnung, d.h. dem Finden eines Betreuers, schreibt die Projektgruppe (sinnvollerweise nach Vorab-Klärung eines grundsätzlichen Interesses) ein Dokument ("Exposé"), das folgende Informationen enthalten soll:

  1. Ausgangssituation im Projektumfeld, Projektziel (grob)
  2. Mitglieder des Projektteams; deren einschlägiges Vorwissen
  3. Ungefährer Inhalt der Ergebnisse jeder Iteration; Zeitplan dazu
  4. Welche softwaretechnischen Methoden sollen wann wofür wie intensiv eingesetzt werden?
  5. Welche anspruchsvollen Informatiktechniken sollen wofür eingesetzt werden?
  6. Welches Mitglied hat welche Rolle oder Zuständigkeit?
  7. Liste von Sprachen, Frameworks, Werkzeugen und Bausteinen, die voraussichtlich eingesetzt werden
  8. Wie und wie oft wird der Kunde eingebunden?
  9. Welche Hauptrisiken bestehen für den Erfolg? Wie wird ihre Eintrittswahrscheinlichkeit reduziert oder die Wirkungen des Eintretens beherrscht?
  10. Auf Basis welcher Informationen sollen die Noten vergeben werden? Wann und in welcher Form werden diese zugänglich gemacht? (Jede/r Teilnehmer/in muss eine individuelle Note bekommen. Gruppennoten sind nicht erlaubt.)

Dieses Dokument sollte so lang wie nötig, aber so kurz wie möglich sein. (Bitte keine Romane schreiben!)

Dieses Dokument ist die Grundlage für die Annahme des Projekts durch den Betreuer. Es bildet auch einen Maßstab für die spätere Notenvergabe.

Durchführung

  • Der Betreuer beantragt beim Institut die Genehmigung dieser außerplanmäßigen Lehrveranstaltung und sorgt für Einträge im Vorlesungsverzeichnis und Campus-Management-System.
  • Wenn das Projekt dann läuft, gilt für das Team: Starke Abweichungen vom geplanten Inhalt oder Ablauf umgehend mit dem Betreuer besprechen.
  • Auch bei kritischen Entscheidungen evtl. Rat einholen, um das Risiko zu senken.
  • Termine für Besprechungen, Präsentationen und Demos rechtzeitig schriftlich vereinbaren.
  • Nach Notenvergabe gilt für den Betreuer: Die leeren Datensätze im CampusManagement, in die die Noten eingetragen werden können, müssen manuell von der CM-Keyuserin angelegt werden.

Halb-selbstorganisierte Varianten

Es gibt auch ein paar Fälle, wo gewisse Gelegenheiten (und damit verbundene Vorgaben) bereits existieren und bekannt sind und die Selbstorganisation deshalb nur noch zum Teil erfolgen muss.

Jede Arbeitsgruppe des Instituts kann und soll hier eigene Ideen oder Projektquellen ergänzen:

Mitarbeit in einem Apache-OpenSource-Projekt

Die Apache Software Foundation hat ein Mentoringprogramm, in dem jeder Interessierte lernen können soll, wie man ein produktives Mitglied eines (Apache-)OpenSource-Projekts wird.

Der Mentor ist in diesem Fall ein Mitglied des jeweiligen Projekts und ist kein Betreuer oder Manager, sondern nur ein Hinweisgeber.

Falls Mentees daran (wie in Ihrem Fall) als Teil einer Hochschulausbildung teilnehmen, gibt es neben dem Mentor (im Apache-Projekt) einen Tutor (an der Hochschule), der die Funktion des Betreuers übernimmt und auch die Noten vergibt.

Eine passende Konstruktion, wie diese Rollen zusammenpassen, muss eine Projektgruppe dabei immer im Einzelfall finden. (Das ist nicht unbedingt ganz einfach, weil normalerweise die Mentees einzeln auftreten, nicht im Bündel zu mehreren.)

Ulrich Stärk hat sich bereit erklärt, eine solche Projektgruppe als Tutor zu betreuen. Da er Mitglied im Tapestry-Projekt ist, kann er zugleich auch die Rolle des Mentors übernehmen, falls die Projektgruppe im Tapestry-Projekt arbeiten möchte.

Wettbewerb ACM SCORE

Die ACM richtet jährlich einen studentischen Wettbewerb namens Student Contest on Software Engineering (SCORE) aus. Dieser richtet sich an Teams.

Eine Teilnahme an SCORE kann angerechnet werden, wenn dabei die obigen Bedingungen eingehalten werden. Bei der Suche nach einem Betreuer ist eine zum Projektinhalt passende Arbeitsgruppe des Instituts anzusteuern.

Wettbewerbserfolge der FU

InformatiCup der GI

Die Gesellschaft für Informatik führt jährlich den studentischen Wettbewerb InformatiCup durch. Dieser richtet sich oft auch an Teams.

Eine Teilnahme am InformatiCup kann angerechnet werden, wenn dabei die obigen Bedingungen eingehalten werden. Bei der Suche nach einem Betreuer ist eine zum Projektinhalt passende Arbeitsgruppe des Instituts anzusteuern.

Wettbewerbserfolge der FU

Laufendes Forschungsprojekt am Institut

Jedes Forschungsprojekt jeder Arbeitsgruppe am Institut kann im Prinzip auch Heimat eines selbstorganisierten Softwareprojekts werden.

Hier können Sie in der Regel sogar die Ideenformulierung schon mit Begleitung durch Mitglieder der Arbeitsgruppe durchführen; nur Ihr Projektteam sollte schon stehen und Interesse für das fragliche Forschungsprojekt vorhanden sein.

Ansonsten läuft die Anbahnung aber wie oben beschrieben ab. Verzichten Sie insbesondere keinesfalls auf die Anfertigung des Expose-Dokuments, denn das würde Ihr Fehlschlagsrisiko stark erhöhen.

(Kommentare)

 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback