Plat_Forms 2011: Web-Entwicklungsplattformen im direkten Projektvergleich

Inhaltsverzeichnis

Immer noch wird die Diskussion darüber, was die beste technische Plattform für die Webentwicklung sei, kaum mit sauberer Datengrundlage geführt. Es gibt viel zu wenig Fälle, bei denen dieselbe Anwendung mehrmals mit unterschiedlichen Plattformen entwickelt wird – bestenfalls bekommt man isolierte Anekdoten geboten. Plat_Forms ist ein wissenschaftlicher Wettbewerb, der das ändern will. Erstmals durchgeführt wurde er 2007, dieser Artikel berichtet von den Ergebnissen von 2011, und im Oktober findet Plat_Forms 2012 statt.

An Plat_Forms 2011 nahmen pro Plattform (Java, Perl, PHP und Ruby) drei oder bevorzugt vier Teams von je drei professionellen Webentwicklern teil; nur hoch qualifizierte Teams wurden zugelassen. .NET, Python, Smalltalk und was auch immer man sonst vermissen mag fehlten nur deshalb, weil dafür nur ein, zwei beziehungsweise keine Bewerbungen eingegangen waren. Neben vier Java-, drei Perl-, vier PHP- und vier Ruby-Teams mit Teilnehmern aus vier Ländern haben die Ausrichter aus Neugierde ausnahmsweise und außer Konkurrenz ein einzelnes JavaScript-Team zugelassen, das sich achtbar schlug. Von serverseitigem Javascript wird zukünftig wohl noch mehr hören zu sein – der Artikel geht aber nicht darauf ein.

Alle Teams arbeiteten am selben Ort zur gleichen Zeit von 9 Uhr morgens bis am nächsten Tag 18 Uhr, mit acht Stunden Schlafpause, also 25 Stunden insgesamt; pro Team kamen also knapp zwei Personenwochen Arbeitsleistung zusammen. Alle Teams implementierten die gleiche, genau
spezifizierte Anwendung namens "Conferences and Participants" (CaP), ein kleines Community-Portal. Die Aufgabe bestand aus acht Use Cases:

1. Benutzer registriert sich: das Übliche.
2. Benutzer erzeugt eine Konferenz: mit Name, Zeitraum, Beschreibung, Kategorie und Ort inklusive GPS-Koordinaten.
3. Benutzer browst Konferenzen: Durchstöbern der Listen von Kategorien, Unterkategorien und Konferenzen.
4. Benutzer arbeitet mit Konferenzseite: Das zeigt die Daten einer einzelnen Konferenz samt einer Google-Maps-Karte an und erlaubt das Herunterladen als PDF und als iCalendar sowie das Abonnieren eines RSS-Feeds für Updates. Kontakte (siehe unten) und beliebige Personen (per E-Mail-Adresse) lassen sich einladen.
5. Benutzer sucht eine Konferenz: Hierfür gibt es sowohl ein Suchformular mit Stichwortsuche und fünf anderen Kriterien als auch ein Textfeld, in dem sich mit einer vorgegebenen Syntax gleichwertige Suchformeln eingeben lassen.
6. Mitglied (d. h. angemeldeter Benutzer) sucht nach Mitgliedern: Ein Suchdialog mit Stichwortsuche plus zwei weiteren Kriterien; an gefundene Mitglieder kann man Freundschaftsanfragen schicken (soziales Netz).
7. Mitglied arbeitet mit seiner Statusseite: persönliche Daten, gesendete und empfangene Freundschaftsanfragen, Freunde, Benachrichtigungen.
8. Mitglied administriert das Portal: Bearbeitung des Kategorienbaums, Einrichtung von Konferenzserien, Rechtevergabe und Anderes.

Die Abläufe sind durch 175 funktionale Anforderungen feinkörnig beschrieben; 143 betreffen das HTML-GUI, 32 die RESTful-Webservice-Schnittstelle, die ungefähr die gleichen Funktionen bereitstellt. Hinzu kommen 23 nichtfunktionale Anforderungen. Jede Anforderung ist als MUST, SHOULD oder MAY priorisiert. Die Teams erhielten neben dem Pflichtenheft einen kleinen Beispieldatenbestand im JSON-Format zum Erstbefüllen ihrer Datenbank.

Für zwei Personenwochen Aufwand ist das Pensum eigentlich viel zu groß, aber manche Teams sind trotzdem beinahe damit fertig geworden. Am Ende lieferte jedes Team einen lauffähigen Server (VMware), eine Quellcode-Distribution und sein Versionsarchiv ab, und die Veranstalter werteten das Material viele Monate lang an der Freien Universität Berlin wissenschaftlich aus (der Wettbewerb war im Januar 2011, aber die Auswertung läuft immer noch weiter).