Seite 2: Ergebnisse

Inhaltsverzeichnis

Aus wissenschaftlicher Sicht waren die Forscher bei der Auswertung an allen Eigenschaften interessiert, die innerhalb einer Plattform X ziemlich homogen sind, über Plattformgrenzen hinweg jedoch verschieden – also an emergenten Eigenschaften der Plattform X.

Produktivität

Für die meisten Webentwickler ist die spannendste Frage die nach der Produktivität. Hierfür haben für jede Entwicklung zwei Gutachter jede der GUI-Anforderungen sorgfältig durch Tests geprüft und in fünf Stufen bewertet:

• 0:fehlt,
• 1:unvollständig,
• 2:funktioniert schlecht,
• 3:funktioniert, und
• 4:funktioniert und ist toll.

Die Bewertungen 1, 2, und 4 wurden nur selten vergeben. Meinungsverschiedenheiten wurden ausdiskutiert. Für die Webservice-Schnittstelle wurde die Prüfung mit einem Testklienten voll automatisiert. Für die Produktivität haben die Forscher alle Anforderungen gezählt, die bei einer Entwicklung mindestens als Stufe 2 bewertet waren. Das Ergebnis ist in Abbildung 1 zu sehen.

Erkenntnis 1: Ruby war die produktivste Plattform.

Das ist absichtlich in der Vergangenheitsform formuliert, damit man es hoffentlich nicht so leicht verallgemeinert, denn natürlich muss das mit anderen Teams, anderen Softwareanforderungen oder anderen Projektformaten nicht immer so aussehen.

Schon 2007 waren die großen Unterschiede zwischen den Java-Teams ähnlich aufgetreten. Die vermeintliche Katastrophe bei Team Perl O ist hingegen ein Ausrutscher: Die Perl-Teams kamen nicht komplett von einzelnen Firmen, sondern hatten sich im Netz zusammengefunden, und Team O bestand versehentlich nur aus Backend-Spezialisten. Prompt sind zwar unter der Haube viele Funktionen angelegt, fast nichts davon aber in der GUI auch zugreifbar; der Balken zeigt fast nur Webservice-Anforderungen. Interessant ist die Entwicklung bei PHP: Es hatte 2007 durch eine faszinierend gleichmäßige Produktivität der damals drei Teams bestochen, sogar noch mehr als hier bei Teams F, G und L zu sehen. Team PHP M durchbricht diesen Effekt gründlich. Diese und noch andere Beobachtungen interpretieren die Forscher als

Erkenntnis 2: Die Plattformen haben sich seit 2007 erheblich verändert.

Das bedeutet zum Beispiel, dass man Vorurteile, die noch aus der Bronzezeit der Webentwicklung stammen, dringend aufgeben sollte. Auf der Suche nach der Erklärung für die hohe Produktivität bei Team PHP M stößt man auf das Framework als wahrscheinliche Ursache: Einzig Team M hat Symfony 1 eingesetzt, und dieses Framework eifert dem für das CaP-Portal offenbar hoch produktiven Vorbild Ruby on Rails nach. Aus der Natur dieses Ausreißers PHP M ergibt sich also die

Erkenntnis 3: Man sollte Plattformen eigentlich nicht einfach nach der Programmiersprache unterteilen.

Als Konsequenz daraus arbeiten die Organisatoren für Plat_Forms 2012 derzeit an einer Klassifizierung nach Framework-Typ. Leider weiß bislang niemand, was das konkret heißen soll ...

Robustheit/Sicherheit

Als ein zweites wichtiges Kriterium interessiert bei Webanwendung deren Sicherheit. Leider ist eine White-Box-Sicherheitsprüfung (d. h. durch Analyse des Quellcodes) nicht so hinzubekommen, dass sie garantiert über alle Plattformen hinweg gleich gründlich ist. Ungleiche Gründlichkeit wäre jedoch unfair. Etwas schwächer gilt das gleiche Argument für Penetrationstests durch Experten, denn auch hierfür wird eine genaue Kenntnis der Funktionsweise der Plattform (z. B. API der Datenbankanbindung) eingesetzt.

Folglich hat man sich auf eine viel einfachere Teillösung zurückgezogen: Es wurden lediglich strikt standardisierte Robustheitsprüfungen auf der GUI durchgeführt und die beobachteten Symptome berichtet. Das Ergebnis ist in Abbildung 2 gezeigt.

Keine Plattform kommt ganz ohne Makel davon, aber insgesamt ist die Robustheit klar besser gegenüber den Resultaten des gleichen Tests 2007. An Plattformunterschieden lesen die Forscher aus dem Bild die:

Erkenntnis 4: Hohe Robustheit scheint bei Java mühseliger zu sein als auf den Skriptsprachen-Plattformen.

Allerdings zeigt Team Java A (das mit einem kommerziellen Framework antrat), dass das kein grundsätzliches Problem ist.

Umfang des Codes

Ein drittes wichtiges Kriterium ist die Wartbarkeit und Fortentwickelbarkeit einer Anwendung. Leider ist hierfür eine plattformübergreifend faire Bewertung eher noch schwieriger als bei der Sicherheit. Deshalb sei auch hier auf ein einfaches Kriterium zurückgezogen, das sich fair analysieren lässt und zumindest einen Hinweis gibt, und zwar den Umfang des Quellcodes. Ein großer Code verursacht tendenziell mehr Verstehensaufwand während späterer Änderungen. (Überkompakten, unlesbaren Write-only-Code haben Teams nicht produziert.)

Da der Codeumfang mit der Menge implementierter Funktionen ansteigt, wurde er nicht direkt, sondern in Beziehung zur Zahl realisierter Anforderungen betrachtet. Gezählt haben die Forscher Zeilen, ohne Leer- und Kommentarzeilen, und das nur für Dateien, an die die Teams wirklich Hand anlegten; unverändert wiederverwendete oder generierte und dann nicht modifizierte Dateien zählen also nicht mit. Diese Klassifikation der Dateien erfordert wieder viel sorgfältige Fleißarbeit. Das Ergebnis zeigt die Abbildung 3.

Entscheidend ist hier die Lage relativ zur Trendlinie: 'Darüber' heißt, es gibt relativ viel Code, 'darunter' bedeutet relativ wenig Code.

Erkenntnis 5: Die Umsetzungen in Perl und Ruby haben eher wenig Codeumfang, die in Java eher viel.

Interessant ist auch die relativ geringe Steigung der Trendlinie: Rechnerisch sind Entwicklungen mit null Funktionen immer noch halb so groß wie solche mit 140 erfüllten Anforderungen. Das ergibt die

Erkenntnis 6: Noch immer erfordern Webanwendungen im Durchschnitt ziemlich viel Gerüstcode.