Ich schreibe gerade an einen Artikel über das "Softwaretechnikpraktikum" an der Universität Paderborn und wollte eigentlich begründen warum ich die alte Aufgabenstellung ("Shuttle-Simulation") trotz all der Probleme besser finde als die neue Aufgabenstellung ("dSpace Systemdesk").
Dazu lese ich gerade auch den Artikel "Ein verbessertes Softwaretechnikpraktikum: Zwischen grüner Wiese und Legacy-Systemen" in dem Björn Axenath und Stefan Henkler ihre Neukonzeption beschreiben. Vielleicht muß ich mir das nochmal überlegen.
Geschockt war ich als ich laß (Hervorhebung von mir):
In den letzten Jahren wurde den Studenten der undokumentierte Code eines komplexen, verteilten Systems [die Shuttle-Simulation] gegeben. [...]Was? Bewusst?
Für einen Großteil der Studenten war dies die erste Begegnung mit einem großen Softwaresystem. Da es sich um ein Legacy-System handelte, war die Qualität bewußt niedrig gehalten.
Das ein System mit den Jahren verkümmert, kann ich ja noch irgendwie verstehen. Die bekannte Liste "realer" Architekturtypen von Brian Foote und Joseph Yoder (Big Ball of Mud) sind gleichzeitig Zeugniss und Warnung davor. Ich bin immer davon ausgegangen, dass dies eben unabsichtlich passiert ist, weil sich niemand um die Qualität gekümmert hat. Mein Eindruck war damals, dass es am Anfang durchaus als gutes System entwickelt wurde (z.B. konnte man die Überreste eines State-Pattern finden, wenn man genau hingeguckt hat) und die Qualität aber den späteren Entwicklern stumpf egal war.
Aber ein bewußt meises System zu entwickeln und frischen Studenten vorzusetzen, ist doch so ziemlich das Schlimmste was man machen kann: Das ist Anti-Code-Reading. Und wir wundern uns über die meise Softwarekonstruktionsfähigkeiten von Absolventen. Wo sollen sie es den gelernt haben, wenn selbst im berühmten Elfenbeinturm kein "Vorbild" vorgesetzt wird?
Automatically imported comment
ReplyDeleteAuthor: Lars
Date: Thursday 17. April 2008
Das erklärt irgendwie im nachinein einiges... Gibt es den Artikel irgendwo online? Interessiert mich prinzipiell nämlich schon...
Automatically imported comment
ReplyDeleteAuthor: dmeister
Date: Thursday 17. April 2008
Nein, online habe ich es nicht gefunden.
Die volle Zitierung ist "Björn Axenath and Stefan Henkler, 'Ein verbessertes Softwaretechnikpraktikum: zwischen grüner Wiese und Legacy-Systemen.', in Software Engineering im Unterricht der Hochschulen, SEUH 10, Stuttgart, Germany, 22. und 23. Februar 2007 (Andreas Zeller and Marcus Deininger, eds.), pp. 13--26, dpunkt, 2007.". Der Buch ist in der Bibo vorhanden.
Automatically imported comment
ReplyDeleteAuthor: Prakti
Date: Tuesday 12. August 2008
Wie erklärt man die schlechte Code-Qualität bei einem Legacy-System, das ebensolche schlechte Qualität aufweist, _ohne_ irgendwelche Fehler eingstehen zu müssen: Man sagt: "Die schlechte Qualität war so gewollt!!" Kein Eingestehen eigener Inkompetenz, kein Erklärungsnotstand und eventuell kann mans ja irgendwie begründen. Passt für mich alles ins Bild der Paderborner Softwaretechnik. Man muss da auch einfach mal die Prioritäten der dortigen Doktoranden klar ins Auge fassen: es geht nicht darum dem Software-Entwickler das leben leichter zu machen, es geht nicht um das schreiben von benutzbarer Software und es geht nicht darum das die Software-Qualität eines Software-Systems, welches (nur) für die Lehre eingesetzt wird besonders hoch ist. Es geht darum das man irgendwann eine Dissertation über ein Thema schreibt, worüber in der Art noch niemand geschrieben hat und das diese Dissertation bei den Prüfern den Eindruck erweckt, das ein signifikanter Beitrag in dem gewählten Forschungsbereich erbracht wurde. Alles andere ist da doch sekundär.
Automatically imported comment
ReplyDeleteAuthor: Björn
Date: Monday 08. December 2008
Ich bitte hiermit Prakti, doch zunächst das Modulhandbuch Informatik zu lesen, bevor er seine Theorien verbreitet. Es handelt sich beim Softwaretechnikpraktikum um eine Lehrveranstaltung und nicht um eine Produktentwicklung. Folglich ist das Ziel der Betreuer nicht, den Studenten das Schreiben von qualitätiv hochwertiger Software zu erleichtern, sondern es ihnen zu vermitteln. Zur Praxisnähe gehört (nicht nur) nach Auffassung des Lehrstuhls der Umgang mit Legacy-Systemen (Re-Enginering notwendig wegen u.a. Design-Erosion, fehlender Dokumentation). Da kein "echtes" Legacy-System aus der Industrie für die Lehre zur Verfügung stand, wurde eine relativ junge Software verwendet, die künstlich gealtert wurde. D.h., es wurden Kommentare entfernt und nur ein minimales Qualitätsmangement durchgeführt, also wurde die Qualität "bewusst niedrig gehalten". BTW: die verwendete Software stand nie in Verbindung mit einer Dissertation.
Übrigens ist das Praktikum auch deshalb 2006 auf EMF/GEF/Eclipseumgestaltet worden ("Eine Entwurfsumgebung für eingebettete Systeme" und nicht dSPACE SystemDesk), damit die Studenten in Kontakt mit "guter Software" kommen - doch Design- oder Architektur-Pattern (Dirk wrote: "State-Pattern") sind nicht explizit Thema des Praktikums sein, da diese Themen zu umfangreich sind und wir auch die Workload laut ECTS berücksichtigen wollen. Im Bereich "Konstruktives Qualitätsmanagement" werden aber stattdessen eine ganze Reihe anderer Vorgaben gemacht: von Coding-Guidelines bis zu einem geplanten und kontrollierten Entwicklungsprozess. Bemerke: Das Re-Engineering wurde 2006 auch erst in der dritten Iteration durch die Übernahme der Komponente eines anderen Teams behandelt; in der ersten Iteration war nur ein Reverse-Engineering des generierten, hochwertigen Codes nötig.
Ergo, Dirk: kein Anti-Code-Reading mehr für Studenten, die erst seit drei Semestern Informatik im Nicht-Elfenbeinturm Paderborn studieren.
Automatically imported comment
ReplyDeleteAuthor: dmeister
Date: Monday 08. December 2008
Hallo Björn, der Artikel und auch der Artikel zum Vergleich von der Shuttle-Simulation und der Entwurfsumgebung für eingebettete Systeme sind nicht gegen den Lehrstuhl oder dich persönlich gemeint gewesen.
Ich würde es nur ehrlich für viel sinnvoller halten den Studenten an qualitativ hochwertiger Softwarearbeiten zu lassen. Nur so lernen sie es, meiner Meinung nach. Der Begriff des "Code Reading" ja gefallen.
Automatically imported comment
ReplyDeleteAuthor: Björn
Date: Monday 08. December 2008
Die Frage ist wohl eher: Wann lernen sie, was guter Code ist? Jetzt wiederhole ich mich fast: weil einige das bis zum Beginn des vierten Semesters noch nicht gelernt haben, haben wir zu Beginn der Praktikums keinen schlechten Code mehr serviert. Oder meinst Du, dass an der Uni niemals schlechter Code gezeigt werden darf? Wie lange ist ein Student "frisch"? (Ach so: ich nehme das nicht persönlich, möchte aber schon, dass das didaktische Konzept richtig verstanden wird.)