Es gibt grundsätzlich zwei Arten, um Funktionalität wiederzuverwenden: Systematisch und Ad-Hoc. Systematische Wiederverwendung steht im Lehrbuch und umfasst die Erstellung von wiederverwendbaren Artefakten (Klassen, Komponenten, Services, usw.) die an einer Stelle im Code gepflegt, und von vielen Stellen genutzt werden. Ad-Hoc-Wiederverwendung steht nicht im Lehrbuch, kennt aber trotzdem jeder: Quelltext wird einfach überall dorthin kopiert, wo die Funktionalität benötigt wird.

In dieser Keynote möchte ich unterschiedliche Fälle von Ad-Hoc-Reuse aus verschiedenen Bereichen der Praxis vorstellen (u.a. eingebettete Software und betriebliche Informationssysteme). Ich werde jeweils auf die Ursachen eingehen und vorstellen wie die Organisation damit umgegangen ist: Von Fällen, in denen ad-hoc in systematische Wiederverwendung überführt wurde, bis zu Beispielen, in denen Ad-Hoc Wiederverwendung beibehalten, aber kontrolliert gewartet wird.

-- Since this post accompanies a talk in German, it is written in German, too.

Viele historisch gewachsene Systeme sammeln über die Jahre Code an, den niemand mehr braucht und der deshalb nutzlos ist. Ein Grund dafür ist beispielsweise, dass bereits implementierte Anforderungen obsolet werden und der Code, der diese Anforderungen implementiert, in der Codebasis verbleibt. Da meist unbekannt ist, welcher Code nutzlos ist, verursacht er oft Kosten ohne Wert zu stiften. In diesem Vortrag stellen wir drei statische und dynamische Analyseansätze vor, die wir in den letzten Jahren bei der Analyse von Kundensystemen und im Rahmen von Forschungsarbeiten entwickelt haben. Schließlich beschreiben wir konkrete Handlungsoptionen zum Umgang mit nutzlosem Code bei Migration und Wartung.

-- Since this post accompanies a talk in German, it is written in German, too.

Die typischen Beispiele für technische Schulden sind uns allen bekannt. Trotzdem werden diese in den meisten Projekten nicht ausreichend adressiert, da es nicht gelungen ist, die Entscheidungsträger von ihrer Relevanz zu überzeugen.

Ich sammele seit 15 Jahren in Forschung und Praxis Erfahrungen, wie sich technische Schulden effektiv interpretieren und kommunizieren lassen. In diesem Vortrag stelle ich anhand von Kundenprojekten die Analysen, Visualisierungen und Kostenmodelle vor, die hierfür am besten funktionieren.

-- Since this post accompanies a talk in German, it is written in German, too.

Auf dem Weg vom Prototyp zur Produktreife müssen wir unsere UX schrittweise verbessern, wenn wir dazulernen, welche Anforderungen an die UX unseren Nutzern besonders wichtig sind. In dieser Keynote möchte ich Erfahrungen aus unserem Weg zu besserer UX von Qualitätsanalysen sowie Erkenntnisse und die über den Haufen geworfenen Entwurfsentscheidungen vorstellen, aber auch unverhoffte neue Analysen und Einsatzszenarien, die sich dadurch ergeben haben.

Wir streben alle nach möglichst hoher Qualität unseres Codes, wissen aber gleichzeitig dass eine gewisse Zahl an Qualitätsproblemen immer anwesend ist. Statt auf absolute Perfektion zu zielen, ist es oft viel sinnvoller zu schauen, ob man mit seinen Problemen im erwartbaren Bereich, oder deutlich darüber oder darunter liegt. Daraus lässt sich z.B. Handlungsbedarf ableiten und die Notwendigkeit zur Modernisierung argumentieren.

Since this post accompanies a talk in German, it is written in German, too.

Quality Gates, wie sie in vielen Software-Entwicklungsprozessen definiert sind, funktionieren in der Praxis meist nicht wie gewünscht, da sie zu schwergewichtig sind und ihr Feedback viel zu spät kommt.

In diesem Vortrag zeige ich auf, wie jüngere Entwicklungen im Bereich Code-Collaboration-Platforms (GitHub, Bitbucket, GitLab und Co.) es erlauben, eine viel schlankere und wirksamere Form von Quality Gates zu etablieren.

-- Since this post accompanies a talk in German, it is written in German, too.

Durch Tests möchten wir Fehler finden, bevor diese in Produktion gelangen. Leider gelingt das nicht immer. Studien zeigen, dass die meisten Feldfehler dort auftreten, wo viel geändert, aber wenig getestet wurde. Seit 2012 setzen wir deshalb mit unseren Kunden Test-Gap-Analyse ein, wodurch solche ungetesteten Änderungen bereits während der Entwicklung vollautomatisch identifiziert werden, damit Entwickler und Tester frühzeitig und kontinuierlich reagieren können.

-- Since this post accompanies a talk in German, it is written in German, too. ---

Im Test möchten wir Fehler finden, bevor diese in Produktion gelangen. Trotzdem gelingt dies nicht immer zu 100 Prozent. Dr. Stefan Staudt (TRUMPF Werkzeugmaschinen) gibt einen Einblick in die Hintergründe zur Einführung der Test-Gap-Analyse bei TRUMPF und berichtet von Erfahrungen bei deren Einsatz insbesondere auch im Hinblick auf die Instrumentierung von C++-Anwendungen, um die Testausführung zu messen.

Grown software systems often contain code that is not necessary anymore. To study the feasibility and usefulness of our approach, we conducted a study involving 14 open-source and closed-source software systems.

-- Since this post accompanies a talk in German, it is written in German, too. ---

Machine Learning hat uns im privaten Bereich längst erreicht: Amazon schlägt mir Produkte vor, Netflix Filme. Oft treffen sie dabei sogar meinen Geschmack. Warum gibt es keine Software, die mir fundiert vorschlägt, was ich testen soll?

-- Since this post accompanies a talk in German, it is written in German, too. ---

Durch immer kürzere Release-Zyklen erfolgen Test und Entwicklung immer häufiger parallel. In der Praxis führt das sowohl zu Test-Lücken, wenn geänderter Code ungetestet ausgeliefert wird, als auch zu nutzlosen Tests von Bereichen, die sich nicht verändert haben und daher keine neuen Fehler enthalten können.

Im Vortrag stelle ich Change-Driven Testing vor, um Test und Entwicklung präziser aufeinander abzustimmen und diese Probleme zu vermeiden.

Speaker: Andreas Göb, Sven Amann

Title: Erfahrungen aus 8 Jahren Test-Gap-Analyse im Praxiseinsatz

Date: 2020-05-07

Coordinates

Speaker: Sven Amann

Conference: SE’20

When: Thursday, Februar 27, 2020, 14:30 - 15:00

Where: Testing 1, Seminarraum 8, Hotel Grauer Bär, Innsbruck

Sprecher: Elmar Jürgens

Konferenz: SE’20

Datum: Donnerstag, 27. Februar 2020, 09:00 - 10:00 Uhr

Ort: Seminarraum 6, Hotel Grauer Bär, Innsbruck

Sprecher: Tobias Röhm

Konferenz: OOP

Datum: Dienstag, 4. Februar 2020, 09:00 - 09:45 Uhr

Ort: ICM München

Sprecher: Elmar Jürgens und Uwe Proft

Konferenz: OOP

Datum: Dienstag, 4. Februar 2020, 16:15 - 17:15 Uhr

Ort: ICM München